Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 761Question →

An enterprise organization hosts a critical web service using Compute Engine Managed Instance Groups (MIGs) and runs background batch processing jobs. During high-traffic events, the MIG experiences severe instance thrashing (rapid scaling up and down), while the batch processing jobs fail frequently due to being deployed on Spot VMs despite being non-fault-tolerant stateful workloads. Which two actions should you take to resolve these operational issues following Google Cloud best practices? (Select TWO choices.)

Select all that apply

Show answer & explanation

Answer: Configure an appropriate cool-down period in the MIG autoscaling policy to prevent additional scaling decisions while newly launched instances are still initializing.; Migrate the non-fault-tolerant stateful batch processing workloads from Spot VMs to standard Compute Engine VM instances.

Answer

The correct actions are to configure an appropriate cool-down period in the MIG autoscaling policy and to migrate non-fault-tolerant stateful batch workloads from Spot VMs to standard Compute Engine VM instances.
Configuring an appropriate cool-down period in the MIG autoscaling policy ensures that the autoscaler waits for newly launched VMs to finish initialization before taking additional scaling actions, preventing thrashing. Furthermore, migrating non-fault-tolerant stateful workloads to standard Compute Engine instances prevents job failures caused by unpredictable Spot VM preemption.

Step-by-Step Solution

1
Analyze the cause of MIG instance thrashing during traffic spikes.
Identified that newly created instances require initialization time before absorbing load. Without a cool-down period, autoscaling metrics trigger redundant scale-out events.
Cool-down periods instruct the autoscaler to ignore metrics from unready or newly added instances until they stabilize.
2
Evaluate the workload requirements for the batch processing jobs currently running on Spot VMs.
Determined that non-fault-tolerant stateful jobs are unsuited for Spot VMs due to unpredictable preemption.
Spot VMs are designed specifically for fault-tolerant, stateless, or checkpointable batch jobs.
3
Select Google Cloud recommended operational practices.
Configure a cool-down period in the MIG policy and move stateful batch workloads to standard Compute Engine VM instances.
Resolves both instability in web server scaling and data/job loss in background batch processing.

Key Concept

Compute Engine Resource Management and Autoscaling Best Practices
Question 762Question →

A data engineering team needs to provision a new Cloud Storage bucket named `analytics-raw-events` in the `us-central1` region to ingest event streams. Company security policy mandates enforcing Uniform Bucket-Level Access upon bucket creation to prevent fine-grained object access control lists (ACLs) from bypassing IAM access policies. Which command should the team execute using the modern `gcloud` CLI to meet these requirements?

Show answer & explanation

Answer: gcloud storage buckets create gs://analytics-raw-events --location=us-central1 --uniform-bucket-level-access

Answer

Execute `gcloud storage buckets create gs://analytics-raw-events --location=us-central1 --uniform-bucket-level-access` to create the bucket with Uniform Bucket-Level Access enabled.
The command `gcloud storage buckets create gs://analytics-raw-events --location=us-central1 --uniform-bucket-level-access` correctly provisions the bucket using modern gcloud storage syntax while applying regional location settings and enabling Uniform Bucket-Level Access in a single step.

Step-by-Step Solution

1
Identify the primary CLI tool recommended by Google Cloud for managing Cloud Storage.
Use `gcloud storage` CLI commands rather than legacy `gsutil` syntax.
Google Cloud recommends `gcloud storage` for superior performance and unified command structure.
2
Specify the required bucket configuration flags.
Set `--location=us-central1` for region targeting and `--uniform-bucket-level-access` for security enforcement.
Cloud Storage buckets require a location specification and support enforcing uniform IAM-based permissions at creation time.

Key Concept

Cloud Storage Bucket Deployment and Access Enforcement via gcloud CLI
Estimated Time:1m 30s
Question 763Question →

An enterprise telemetry service ingests real-time IoT diagnostic data into Google Cloud Storage. Analysts perform frequent, daily query operations on the ingested data during the first 30 days. After 30 days, the data is rarely accessed but must be retained for 3 years to comply with regulatory requirements. You need to plan a storage architecture that minimizes overall storage and access costs without incurring data retrieval penalties during the initial active analysis window. Which bucket configuration should you recommend?

Show answer & explanation

Answer: Create a Cloud Storage bucket with Standard storage class as the default, and configure an Object Lifecycle Management rule to transition objects to Coldline storage after 30 days.

Answer

Create a Cloud Storage bucket with Standard storage class as the default, and configure an Object Lifecycle Management rule to transition objects to Coldline storage after 30 days.
The option recommending Standard storage class by default combined with an Object Lifecycle Management rule to transition objects to Coldline storage after 30 days is correct. Standard storage has no retrieval charges for active daily analysis. Moving data to Coldline after 30 days optimizes long-term retention costs when query frequency drops.

Step-by-Step Solution

1
Analyze access pattern requirements during the initial 30-day period.
Data is accessed frequently daily, requiring a tier with zero retrieval charges (Standard storage class).
Using Nearline, Coldline, or Archive during active daily usage causes high retrieval fee penalties.
2
Analyze access pattern and retention requirements after 30 days.
Data is rarely accessed but must be retained for 3 years.
Coldline storage class provides low-cost storage for data accessed at most once per quarter and fits the multi-year retention requirement.
3
Determine the optimal automated lifecycle policy.
Configure Object Lifecycle Management to transition objects from Standard to Coldline when age reaches 30 days.
Automating transitions reduces operational overhead and minimizes total cost of ownership.

Key Concept

Cloud Storage Storage Class Selection and Object Lifecycle Management
Question 764Question →

A DevOps team is deploying a production Cloud SQL for PostgreSQL instance named `app-postgres-db` using the Google Cloud CLI. The deployment policies mandate three strict requirements: the instance must communicate exclusively over Private IP within the existing Virtual Private Cloud (VPC) network `internal-vpc`, public IP address allocation must be explicitly disabled, and all incoming client connections must enforce SSL/TLS encryption. Additionally, the instance must automatically increase storage space when available capacity drops below the safety threshold. Which `gcloud` command should the engineer run to provision the database instance according to these requirements?

Show answer & explanation

Answer: gcloud sql instances create app-postgres-db --database-version=POSTGRES_15 --tier=db-custom-2-7680 --network=internal-vpc --no-assign-ip --require-ssl --enable-autoresize

Answer

The command starting with 'gcloud sql instances create app-postgres-db' that specifies '--no-assign-ip', '--network=internal-vpc', '--require-ssl', and '--enable-autoresize' correctly provisions the instance according to all security and operational requirements.
The option including '--no-assign-ip', '--network=internal-vpc', '--require-ssl', and '--enable-autoresize' fulfills all compliance criteria. Specifying '--network' attaches the instance to the private network, while '--no-assign-ip' ensures no public IPv4 address is assigned. Furthermore, '--require-ssl' forces encrypted incoming client connections and '--enable-autoresize' automatically expands storage capacity as data grows.

Step-by-Step Solution

1
Identify the private IP connectivity requirement
Connecting to a VPC network requires the '--network' flag pointing to the designated VPC (internal-vpc).
Cloud SQL requires Private Service Access configuration in the VPC to instantiate private IP interfaces.
2
Identify the security requirement to disable public IP
By default, Cloud SQL assigns a public IP address even when attached to a VPC network unless '--no-assign-ip' is specified.
The '--no-assign-ip' flag suppresses the creation of an external IPv4 address on the Cloud SQL instance.
3
Verify SSL enforcement and storage scaling flags
Enforcing client SSL/TLS requires '--require-ssl', and automatic storage scaling requires '--enable-autoresize'.
These flags enforce protocol encryption and operational resilience against disk full errors.

Key Concept

Cloud SQL CLI Provisioning with Private IP, SSL Enforcement, and Auto-Resizing
Question 765Question →

A cloud engineer attempts to deploy an updated Kubernetes Deployment manifest to an existing GKE cluster named `inventory-cluster` in zone `us-central1-a` by running `kubectl apply -f deployment.yaml`. The command fails with an error stating `The connection to the server localhost:8080 was refused`, indicating that local command-line tools are not configured to communicate with the GKE control plane. Which command should the engineer execute to correctly fetch cluster credentials and configure the local `kubeconfig` context?

Show answer & explanation

Answer: gcloud container clusters get-credentials inventory-cluster --zone us-central1-a

Answer

The cloud engineer should execute `gcloud container clusters get-credentials inventory-cluster --zone us-central1-a` to populate the local kubeconfig context with the cluster endpoint and credentials.
Running `gcloud container clusters get-credentials` retrieves authentication credentials and cluster endpoint details from Google Kubernetes Engine and writes them to the local `kubeconfig` configuration file, allowing `kubectl` to successfully communicate with the control plane.

Step-by-Step Solution

1
Identify the root cause of the kubectl connection failure.
The error `localhost:8080 was refused` shows that `kubectl` lacks valid endpoint details and credentials for the target GKE cluster, defaulting to a non-existent local server.
Before `kubectl` can communicate with a GKE cluster control plane, credentials and context must be generated locally.
2
Determine the appropriate command to populate kubeconfig.
`gcloud container clusters get-credentials` fetches cluster certificates, API server endpoints, and authentication context.
This command writes the necessary cluster configuration directly into `~/.kube/config`, directing `kubectl` commands to the remote GKE cluster.

Key Concept

Fetching GKE cluster credentials to configure local kubectl context
Question 766Question →

A cloud engineer needs to limit the maximum number of container instances for an existing Cloud Run service named `inventory-api` to preventing overloading a backend database. Which `gcloud` command should the engineer execute?

Show answer & explanation

Answer: gcloud run services update inventory-api --max-instances=10

Answer

Execute `gcloud run services update inventory-api --max-instances=10` to adjust scaling settings on an existing Cloud Run service.
The correct command uses `gcloud run services update` along with the `--max-instances` flag to modify scaling limits on an existing Cloud Run service without affecting traffic splitting or target compute paradigms.

Step-by-Step Solution

1
Identify the resource type
The target is a Cloud Run service named `inventory-api`.
Cloud Run service management requires using `gcloud run services` commands.
2
Determine the required operation flag
The operation modifies autoscaling parameters by specifying `--max-instances=10`.
To update configuration parameters like instance limits on an existing Cloud Run service without re-deploying code, `gcloud run services update` is the standard command.

Key Concept

Managing Cloud Run scaling parameters via the gcloud CLI
Question 767Question →

A site reliability engineer needs to perform a manual blue-green node pool upgrade on a production Google Kubernetes Engine (GKE) Standard cluster to migrate workload Pods from node pool `pool-v1` to a newly provisioned node pool `pool-v2` with minimal application disruption. Sequence the required administrative steps in the correct operational order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence for a manual GKE blue-green node pool migration is: 1) Provision the target node pool `pool-v2`, 2) Cordon the nodes in `pool-v1`, 3) Drain the nodes in `pool-v1`, and 4) Delete the original node pool `pool-v1` after validating workload stability.
In a manual GKE blue-green node pool update, new capacity (`pool-v2`) must be created first. The old nodes (`pool-v1`) are then cordoned to block new Pod assignments, followed by draining the old nodes to safely relocate running workloads to `pool-v2`. Once all workloads are confirmed operational on `pool-v2`, `pool-v1` can be safely deleted.

Step-by-Step Solution

1
Create target node pool
Node pool `pool-v2` is created and nodes enter the Ready state.
Sufficient ready capacity must exist in the cluster before evicting workloads from existing nodes.
2
Cordon source nodes
Nodes in `pool-v1` are marked Unschedulable.
Ensures no new Pods are scheduled onto nodes targeted for decommissioning.
3
Drain source nodes
Pods on `pool-v1` nodes are safely evicted and rescheduled onto `pool-v2` nodes.
Gracefully migrates workload traffic to the newly created node pool in accordance with PodDisruptionBudgets.
4
Delete source node pool
Node pool `pool-v1` is deleted via gcloud CLI.
Decommissions legacy infrastructure to avoid duplicate node charges once migration is verified successful.

Key Concept

Manual Blue-Green GKE Node Pool Migration Workflow
Question 768Question →

A cloud engineer needs to deploy a containerized backend processing microservice to Google Cloud Run in the europe-west1 region using the gcloud CLI. The application image is stored in Artifact Registry. Security policies require that the service must prevent unauthenticated ingress traffic and run with a specific user-managed runtime service account named [email protected] to access downstream Google Cloud databases. Which gcloud command correctly deploys the service in accordance with these security requirements?

Show answer & explanation

Answer: gcloud run deploy processor-service --image=europe-west1-docker.pkg.dev/my-project/repo/processor:v1 --region=europe-west1 --no-allow-unauthenticated --service-account=processor-sa@my-project.iam.gserviceaccount.com

Answer

The correct command uses `gcloud run deploy` with `--region=europe-west1`, `--no-allow-unauthenticated`, and `--service-account=processor-sa@my-project.iam.gserviceaccount.com`.
The command correctly uses `gcloud run deploy` to provision a containerized Cloud Run service, sets the regional deployment scope to `europe-west1`, prevents public unauthenticated access using `--no-allow-unauthenticated`, and binds the dedicated identity using `--service-account`.

Step-by-Step Solution

1
Identify the target compute platform and tool
Since a pre-built container image from Artifact Registry is being deployed as a serverless containerized service, `gcloud run deploy` must be used rather than `gcloud functions deploy`.
Cloud Run natively executes container images, whereas Cloud Functions builds and executes event-driven code snippets or Gen 2 functions.
2
Configure operational scope and service identity flags
Specify `--region=europe-west1` for regional scope and `--service-account` to bind the custom runtime service account identity.
Cloud Run services are regional resources requiring a region target, and custom service accounts provide least-privilege identity for downstream resource access.
3
Enforce ingress access controls
Pass the `--no-allow-unauthenticated` flag to restrict access to authenticated IAM invokers only.
Passing `--allow-unauthenticated` exposes the HTTP endpoint publicly without IAM verification.

Key Concept

Deploying containerized serverless applications using gcloud run deploy with custom runtime service accounts and authentication flags.
Estimated Time:2m 0s
Question 769Question →

A system administrator is writing a deployment script using the Google Cloud CLI (`gcloud`) to launch non-critical stateless batch processing Virtual Machine instances on Compute Engine. The VM instances must execute a bash initialization script located on the local disk at `./scripts/init.sh` upon first boot and execute using a dedicated custom IAM service account named `[email protected]`. Which TWO `gcloud compute instances create` flags must be used to meet these requirements?

Select all that apply

Show answer & explanation

Answer: --service-account=batch-runner@my-project.iam.gserviceaccount.com; --metadata-from-file=startup-script=./scripts/init.sh

Answer

The deployment command must include `--service-account=batch-runner@my-project.iam.gserviceaccount.com` to attach the custom IAM service account identity and `--metadata-from-file=startup-script=./scripts/init.sh` to read and load the local shell script into the VM metadata startup key.
To provision a Compute Engine instance attached to a custom service account and execute a local initialization script on startup, `gcloud compute instances create` requires two specific flags: `--service-account` to define the IAM identity, and `--metadata-from-file` with the `startup-script` key to read the local script contents into the VM metadata.

Step-by-Step Solution

1
Identify the flag required to attach an IAM service account identity to a Compute Engine VM.
The `gcloud compute instances create` command uses `--service-account=[SA_EMAIL]` to bind a specific service account identity.
By default VMs receive the Compute Engine default service account unless explicit identity configuration is specified.
2
Identify the flag required to upload local file content as startup script metadata.
The `--metadata-from-file=startup-script=[FILE_PATH]` flag reads local files and attaches their contents to instance metadata.
Using literal `--metadata` only stores the file path string itself, whereas `--metadata-from-file` ingests the file contents.

Key Concept

Compute Engine gcloud CLI flags for identity binding and startup script configuration
Question 770Question →

A DevOps engineer is managing a Google Kubernetes Engine (GKE) Standard cluster named `analytics-cluster` located in region `us-central1`. The cluster contains a node pool named `worker-pool` that experiences variable compute demands throughout the day. The engineer needs to configure GKE to automatically adjust the number of worker VM instances in `worker-pool` based on unschedulable pending pods, while strictly maintaining a minimum of 3 nodes and a maximum of 12 nodes per zone. Which command should the engineer run to accomplish this goal?

Show answer & explanation

Answer: gcloud container node-pools update worker-pool --cluster=analytics-cluster --region=us-central1 --enable-autoscaling --min-nodes=3 --max-nodes=12

Answer

Execute `gcloud container node-pools update worker-pool --cluster=analytics-cluster --region=us-central1 --enable-autoscaling --min-nodes=3 --max-nodes=12`.
The command `gcloud container node-pools update worker-pool --cluster=analytics-cluster --region=us-central1 --enable-autoscaling --min-nodes=3 --max-nodes=12` correctly enables and configures the GKE Cluster Autoscaler for the specified node pool with the requested lower and upper node limits.

Step-by-Step Solution

1
Identify the scaling requirement level
Recognize that scaling the underlying GKE compute nodes based on pending pods requires Cluster Autoscaler at the node pool level, not Horizontal Pod Autoscaler at the workload level.
Node infrastructure management is handled by GKE Cluster Autoscaler.
2
Select the correct gcloud command tool and subcommand
Use `gcloud container node-pools update` targeting the target node pool (`worker-pool`) within the cluster (`analytics-cluster`).
Node pool properties in GKE are modified using `gcloud container node-pools update`.
3
Specify autoscaling configuration flags
Append `--enable-autoscaling`, `--min-nodes=3`, and `--max-nodes=12` along with the appropriate `--region` flag.
These flags configure the minimum and maximum boundary bounds per zone for GKE Cluster Autoscaler.

Key Concept

GKE Cluster Autoscaler Node Pool Management
Estimated Time:2m 0s
Question 771Question →

An administrator needs to configure automatic scaling for a Google Kubernetes Engine (GKE) Deployment so that the number of Pod replicas increases or decreases based on CPU utilization. Which command should the administrator execute to achieve this?

Show answer & explanation

Answer: kubectl autoscale deployment web-app --min=2 --max=10 --cpu-percent=80

Answer

The correct command is `kubectl autoscale deployment web-app --min=2 --max=10 --cpu-percent=80`.
Executing `kubectl autoscale deployment` creates a Horizontal Pod Autoscaler (HPA) resource in GKE that automatically increases or decreases the number of Pod replicas in response to CPU utilization metrics.

Step-by-Step Solution

1
Identify the resource tier that requires scaling.
The requirement specifies scaling Pod replicas inside a Deployment based on workload metric demand, not compute nodes.
Horizontal Pod Autoscaler (HPA) operates at the Kubernetes workload abstraction level.
2
Select the appropriate CLI tool and command syntax for HPA creation.
Using `kubectl autoscale deployment` creates an HPA object targeting the deployment with min/max replica boundaries and a target CPU percentage.
`kubectl autoscale` directly provisions the HPA controller resource in GKE.

Key Concept

Horizontal Pod Autoscaling (HPA) in Google Kubernetes Engine
Question 772Question →

Your enterprise web application is hosted across Compute Engine virtual machine instance groups located in two Google Cloud regions: us-central1 and europe-west3. The application requires SSL termination at Google's network edge, HTTP/2 support for client connections, and Layer 7 path-based URL map routing (such as forwarding requests for /static/* to a Cloud Storage bucket and /api/* to the Compute Engine backend service). Which Google Cloud load balancer should you deploy?

Show answer & explanation

Answer: Global External Application Load Balancer

Answer

Global External Application Load Balancer
The Global External Application Load Balancer is a proxy-based Layer 7 load balancer that handles HTTP, HTTPS, and HTTP/2 traffic. It terminates SSL at Google's global edge points of presence, uses URL maps for path-based routing to different backends (such as backend services or Cloud Storage buckets), and balances traffic globally across backend instance groups in multiple regions.

Step-by-Step Solution

1
Analyze client accessibility and geographical reach requirements.
The application must serve public internet traffic across multiple regions (us-central1 and europe-west3), requiring a global external frontend IP.
Regional load balancers cannot distribute traffic across multiple Google Cloud regions under one IP address.
2
Identify the required network protocol layer and routing features.
The requirement specifies Layer 7 capabilities: SSL termination at Google edge locations, HTTP/2, and URL map path-based routing (/static/* vs /api/*).
Layer 4 Network Load Balancers only inspect transport-level headers (IP/port) and cannot parse HTTP paths or handle Layer 7 SSL termination.
3
Match requirements to the correct Google Cloud Load Balancing product.
The Global External Application Load Balancer fulfills all requirements: global reach, multi-region backends, Layer 7 URL map routing, and edge SSL termination.
It is designed specifically for HTTP(S) workloads distributed globally.

Key Concept

Selecting Cloud Load Balancer types based on traffic scope (global vs regional), client access (external vs internal), and protocol layer (Layer 4 vs Layer 7).
Question 773Question →

An enterprise is establishing hybrid connectivity between an on-premises data center and a Google Cloud Virtual Private Cloud (VPC) network via Cloud Interconnect. Compute Engine virtual machines deployed in the VPC must resolve hostnames in the internal domain internal.company.com, which are managed by on-premises DNS servers. The architecture requires DNS queries for internal.company.com originating from VPC workloads to be routed to the on-premises DNS servers without exposing internal domain data to the public internet. Which Cloud DNS configuration should you plan to meet these requirements?

Show answer & explanation

Answer: Create a Cloud DNS private zone for internal.company.com configured for DNS forwarding, specifying the on-premises DNS server IP addresses as forwarding targets.

Answer

Create a Cloud DNS private zone for internal.company.com configured for DNS forwarding, specifying the on-premises DNS server IP addresses as forwarding targets.
Configuring a Cloud DNS private zone with DNS outbound forwarding allows Virtual Private Cloud (VPC) instances to forward domain lookup requests for internal.company.com directly to specified on-premises DNS server IP addresses over private network connections (such as Cloud Interconnect or Cloud VPN). This meets all requirements for private, secure, and seamless hybrid name resolution.

Step-by-Step Solution

1
Analyze the networking scope and protocol requirements
The requirement asks for private DNS resolution of an internal domain (internal.company.com) from GCP VPC VMs to on-premises DNS servers over Cloud Interconnect.
Traffic must remain private within the hybrid network and DNS resolution must be natively handled for VPC workloads.
2
Evaluate Google Cloud DNS capabilities for hybrid networks
Cloud DNS private zones support outbound DNS forwarding, allowing queries for specific domain suffixes to be sent to target IP addresses across Cloud Interconnect or VPN.
This bridges VPC DNS resolution with on-premises infrastructure securely without internet exposure.
3
Eliminate incompatible service options
Public DNS zones expose data publicly, Layer 7 HTTP(S) Load Balancers do not support DNS protocol, and Cloud CDN cannot be attached to Cloud DNS.
Selecting service types aligned with Layer 3/Layer 7 boundaries and service capabilities ensures proper architecture.

Key Concept

Cloud DNS Private Zone Forwarding for Hybrid Architecture
Question 774Question →

Your organization runs a web application on Compute Engine instances within a Managed Instance Group (MIG). You need to deploy an updated version of your software to all instances in the group while maintaining zero downtime. Which TWO actions should you perform?

Select all that apply

Show answer & explanation

Answer: Create a new instance template that specifies the updated application configuration.; Start a rolling update on the Managed Instance Group using the newly created instance template.

Answer

The two correct actions are creating a new instance template containing the updated configuration and initiating a rolling update on the Managed Instance Group with that new template.
Because Compute Engine instance templates are immutable, updating a Managed Instance Group requires creating a new instance template with the updated configuration, followed by a rolling update on the group to replace instances gradually without downtime.

Step-by-Step Solution

1
Create a new Compute Engine instance template specifying the updated software version or startup script.
A new instance template resource is defined in the project.
Instance templates are immutable; any configuration update requires generating a new template.
2
Execute a rolling update on the target Managed Instance Group referencing the newly created template.
The MIG automatically replaces instances in batches according to update policy parameters.
Rolling updates replace instances incrementally, avoiding service downtime.

Key Concept

Updating Managed Instance Groups via new instance templates and rolling updates
Question 775Question →

You are tasked with deploying a Global External Application Load Balancer in Google Cloud using the `gcloud` CLI to route HTTP traffic to an existing unmanaged instance group `web-ig-us` in `us-central1`. To ensure dependencies are created before their dependent resources, what is the correct sequential order of `gcloud` commands required to provision this infrastructure from the backend up to the global frontend forwarding rule?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of deployment commands from backend dependencies to frontend entry point is: 1) Create global HTTP health check, 2) Create global backend service with health check, 3) Add instance group backend to backend service, 4) Create URL map referencing default backend service, 5) Create target HTTP proxy referencing URL map, and 6) Create global forwarding rule pointing to target proxy.
Deploying a GCP Global External Application Load Balancer via the command-line interface requires a strict bottom-up dependency ordering. First, independent health checks must be provisioned (`gcloud compute health-checks create http`). Second, the global backend service must be created referencing the health check (`gcloud compute backend-services create`). Third, workload backends are added to the service (`gcloud compute backend-services add-backend`). Fourth, the URL map is created to route requests to the backend service (`gcloud compute url-maps create`). Fifth, the target proxy is created referencing the URL map (`gcloud compute target-http-proxies create`). Finally, the global forwarding rule is created pointing public traffic on port 80 to the target HTTP proxy (`gcloud compute forwarding-rules create`).

Step-by-Step Solution

1
Identify resource dependencies for Global External Application Load Balancers
Lower-level components (health checks, backend services) must exist before higher-level routing objects (URL maps, proxies, forwarding rules).
Google Cloud resource creation calls validate referenced resource URIs; creating dependent resources before their targets results in command failure.
2
Order backend foundation deployment
Health check is created first, followed by the backend service linked to that health check, followed by adding the instance group.
Backend services cannot be created without referencing a health check, and backends cannot be added until the backend service container exists.
3
Order frontend routing deployment
URL map points to backend service -> Target Proxy points to URL map -> Forwarding Rule points to Target Proxy.
Each traffic handling layer encapsulates the layer beneath it, culminating in the global forwarding rule receiving incoming requests.

Key Concept

Bottom-up CLI deployment ordering for GCP Global External Application Load Balancers
Question 776Question →

A media streaming company is architecting a Google Kubernetes Engine (GKE) cluster to host its customer billing microservices. Security policy strictly mandates that worker nodes must not have public IP addresses exposed to the internet. However, container pods running on these nodes must be able to initiate outbound connections to external third-party payment processing APIs and pull images from Google Container Registry/Artifact Registry. Which GKE cluster network design should the cloud engineer recommend?

Show answer & explanation

Answer: Provision a Private GKE Cluster with private node IP addresses, and configure Cloud NAT on the subnetwork to enable outbound internet access.

Answer

Provision a Private GKE Cluster with private node IP addresses, and configure Cloud NAT on the subnetwork to enable outbound internet access.
Configuring a Private GKE Cluster ensures that cluster nodes only receive internal private IP addresses, preventing direct inbound access from the internet. Enabling Cloud NAT on the VPC subnetwork enables workloads on those private nodes to safely initiate outbound connections to external services, such as payment APIs and container registries, without assigning public IPs to worker nodes.

Step-by-Step Solution

1
Analyze security requirements for worker node IP assignment.
Nodes must have private IP addresses only, which requires creating a Private GKE cluster.
Private GKE clusters prevent nodes from receiving public IP addresses, satisfying the security policy prohibiting direct inbound public internet exposure.
2
Determine the network egress mechanism for pods needing external internet access.
Cloud NAT must be enabled on the VPC subnetwork hosting the GKE cluster nodes.
Cloud NAT performs Network Address Translation, allowing private node instances and pods to reach external endpoints (like third-party payment APIs) without giving public IP addresses to the nodes.

Key Concept

Private GKE Cluster Architecture with Cloud NAT for Outbound Egress
Question 777Question →

A DevOps engineer is managing a Google Kubernetes Engine (GKE) Standard cluster named `prod-app-cluster` in zone `us-central1-a`. During a traffic increase, several new microservice pods remain in a `Pending` state because the existing node pool, `frontend-pool`, lacks sufficient CPU resources to schedule them. The engineer needs to ensure that the GKE cluster automatically adds Compute Engine nodes to `frontend-pool` when pods are unschedulable due to resource constraints, up to a maximum of 10 nodes. Which command should the engineer run to achieve this requirement?

Show answer & explanation

Answer: gcloud container clusters update prod-app-cluster --enable-autoscaling --min-nodes=1 --max-nodes=10 --node-pool=frontend-pool --zone=us-central1-a

Answer

Execute the `gcloud container clusters update prod-app-cluster --enable-autoscaling --min-nodes=1 --max-nodes=10 --node-pool=frontend-pool --zone=us-central1-a` command.
Enabling Cluster Autoscaler on a node pool via `gcloud container clusters update prod-app-cluster --enable-autoscaling --min-nodes=1 --max-nodes=10 --node-pool=frontend-pool --zone=us-central1-a` instructs GKE to automatically resize the underlying Compute Engine instance group when pods cannot be scheduled due to insufficient CPU or memory resources.

Step-by-Step Solution

1
Identify the root cause of the issue
Pods are stuck in `Pending` because the cluster nodes lack sufficient CPU resource requests to schedule the pods.
When nodes run out of capacity, Kubernetes cannot place pods until new node resources become available.
2
Select the appropriate scaling mechanism
Cluster Autoscaler must be enabled at the GKE cluster node pool level rather than Pod autoscaling (HPA).
Cluster Autoscaler increases or decreases the number of Compute Engine VM instances in a node pool based on unschedulable pods.
3
Formulate the correct gcloud CLI command
Use `gcloud container clusters update` specifying `--enable-autoscaling`, `--min-nodes`, `--max-nodes`, and targeting `--node-pool=frontend-pool`.
This updates the existing node pool configuration in the specified zone to dynamically scale nodes between 1 and 10.

Key Concept

Configuring GKE Cluster Autoscaler to dynamically scale Compute Engine node pools when pods are unschedulable.
Question 778Question →

A data analyst needs to execute SQL queries in BigQuery and read table contents within a specific dataset named `sales_data` inside the `corp-analytics-prod` project. Following Google Cloud best practices for least privilege, the analyst must not be able to modify any data or access other datasets within the project. Which IAM role assignment strategy should be implemented?

Show answer & explanation

Answer: Grant the BigQuery Job User role (roles/bigquery.jobUser) at the project level and the BigQuery Data Viewer role (roles/bigquery.dataViewer) at the dataset level.

Answer

Grant the BigQuery Job User role (roles/bigquery.jobUser) at the project level and the BigQuery Data Viewer role (roles/bigquery.dataViewer) at the dataset level.
To execute BigQuery queries, a user needs the project-level permission `bigquery.jobs.create`, provided by `roles/bigquery.jobUser`. To read data strictly within a specific dataset without accessing others in the project, `roles/bigquery.dataViewer` must be granted at the dataset level. This combination satisfies least-privilege requirements.

Step-by-Step Solution

1
Identify the required operational permission to execute BigQuery jobs.
Creating and running jobs requires project-level authorization, which is provided by the predefined role roles/bigquery.jobUser.
Job execution is a project-scoped action in Google Cloud BigQuery.
2
Identify the required data access permission scoped to the specific target resource.
Reading table data within the specific dataset requires roles/bigquery.dataViewer assigned directly on the target dataset resource.
Granting data permissions at the dataset level prevents access to other datasets in the project.
3
Combine the permissions following the principle of least privilege.
The user obtains minimum required capabilities without excess permissions or broad primitive roles.
This separation ensures compliance with GCP security recommendations.

Key Concept

Applying Least-Privilege IAM Roles for BigQuery Access Across Resource Hierarchy Levels
Question 779Question →

Your operations team manages a critical stateful log processing database on an Ubuntu Linux Compute Engine virtual machine instance. Due to rapid data growth, the mounted ext4 data disk reached capacity. An administrator resized the persistent disk from 200 GB to 500 GB using the Google Cloud Console; however, running `df -h` inside the instance shows that the file system is still limited to 200 GB. Which set of actions must you perform to make the newly allocated 300 GB available to the operating system with minimal service disruption?

Show answer & explanation

Answer: Connect to the instance using SSH, run `growpart` to expand the target disk partition, and execute `resize2fs` to extend the ext4 file system online.

Answer

Connect to the instance via SSH, use `growpart` to expand the partition table, and use `resize2fs` to resize the ext4 file system online.
When a Compute Engine persistent disk size is increased in GCP, the hypervisor provides larger block storage, but the operating system's partition table and file system remain at their original sizes. To utilize the space online, administrators must connect to the VM via SSH, run `growpart` to expand the partition containing the file system, and then run `resize2fs` (for ext4 file systems) to grow the file system live.

Step-by-Step Solution

1
Understand GCP Persistent Disk expansion mechanics
Recognize that increasing disk size in GCP Cloud Console or gcloud updates the virtual block device size at the hypervisor level, but does not alter the guest OS partition table or file system.
Storage expansion in GCP is a two-step process: hypervisor disk resizing followed by operating system partition and file system resizing.
2
Identify the required Linux guest OS commands
Use `growpart` (or `parted`) to extend the partition to fill the newly available space on the block device, and `resize2fs` (for ext4) or `xfs_growfs` (for XFS) to extend the file system.
These standard Linux utilities allow online extension of mounted file systems without requiring VM reboots or downtime.

Key Concept

Compute Engine Persistent Disk Resizing and File System Extension
Question 780Question →

You need to provision a secure Cloud SQL for PostgreSQL instance that communicates exclusively via Private IP within an existing custom Virtual Private Cloud (VPC) network named `prod-vpc`. Sequence the following deployment steps in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1. Reserve internal IP address range in prod-vpc -> 2. Establish Private Service Access connection -> 3. Deploy Cloud SQL instance with --network=prod-vpc and --no-assign-ip -> 4. Configure database user accounts.
Provisioning a Private IP Cloud SQL instance requires a specific prerequisite chain: first allocating an internal IP range in the VPC network (`gcloud compute addresses create`), second establishing a Private Service Access peering connection (`gcloud services vpc-peerings connect`), third creating the instance linked to the VPC network with public IP disabled (`gcloud sql instances create`), and finally setting up database users on the running instance (`gcloud sql users create`).

Step-by-Step Solution

1
Allocate an IP range for Private Service Access
A named IP range is reserved within the VPC for Google service producer peering.
Cloud SQL Private IP relies on Private Service Access, which requires a pre-allocated IP range.
2
Create VPC Peering connection
The customer VPC network is peered with Google's Service Networking tenant network.
Without active VPC Peering to servicenetworking.googleapis.com, Cloud SQL cannot attach internal IP endpoints.
3
Create Cloud SQL instance attached to VPC
The instance is provisioned with a private IP address and no public IP assigned.
The flags --network=prod-vpc and --no-assign-ip enforce private network attachment and prevent public Internet exposure.
4
Create database user accounts
Application user accounts are initialized on the running instance.
Database user configuration requires an active, running Cloud SQL instance target.

Key Concept

Sequence of setup tasks for Cloud SQL Private IP provisioning via Private Service Access
PreviousPage 39 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin