Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 801Question →

A database engineer is deploying a Cloud Spanner instance named `prod-spanner-db` to support a high-throughput transactional service. The workload requires sub-node scaling, specifically 300 processing units of compute capacity, hosted in the `us-east1` region. Which `gcloud` command correctly provisions this Cloud Spanner instance according to Google Cloud best practices?

Show answer & explanation

Answer: gcloud spanner instances create prod-spanner-db --config=regional-us-east1 --description="Production DB" --processing-units=300

Answer

The command `gcloud spanner instances create prod-spanner-db --config=regional-us-east1 --description="Production DB" --processing-units=300` correctly provisions the instance.
The correct option executes `gcloud spanner instances create` specifying `--processing-units=300`. In Google Cloud Spanner, compute capacity below 1 full node (1,000 processing units) is configured using the `--processing-units` flag in increments of 100.

Step-by-Step Solution

1
Identify the target managed database product and command group
Cloud Spanner deployment requires the `gcloud spanner instances create` command group.
Cloud SQL CLI commands (`gcloud sql`) cannot provision or manage Cloud Spanner instances.
2
Determine compute capacity units for sub-node scaling
Specify compute capacity using `--processing-units=300`.
Cloud Spanner compute capacity is defined in processing units (where 1,000 processing units equal 1 node). Compute capacity under 1 node must be specified using `--processing-units` with integer multiples of 100, as `--nodes` does not accept fractional values.
3
Verify region and instance parameters
Pass `--config=regional-us-east1` to specify regional deployment in `us-east1`.
Spanner instance configurations use regional or multi-regional config strings to define geographical placement.

Key Concept

Cloud Spanner Instance Provisioning and Processing Unit Scaling via gcloud CLI
Estimated Time:2m 0s
Question 802Question →

A DevOps team is preparing a budget model in the Google Cloud Pricing Calculator for a containerized event-processing application running on Cloud Run, backed by Cloud Storage for long-term log archiving. The application runs processing tasks on an event-driven basis with variable execution durations and outputs non-frequent access logs directly to storage. Which of the following parameters must be explicitly configured in the Google Cloud Pricing Calculator to ensure an accurate monthly cost estimate for these services? (Select TWO)

Select all that apply

Show answer & explanation

Answer: The average request duration, allocated vCPU/memory per instance, and total monthly request count for the serverless container execution.; The expected monthly data storage volume along with estimated retrieval fees and data access operations for the selected Cloud Storage tier.

Answer

Accurately estimating costs for Cloud Run and Cloud Storage in the Pricing Calculator requires configuring Cloud Run execution metrics (vCPU, memory, request duration, and request counts) and Cloud Storage operational costs (storage volume, operation counts, and retrieval fees).
Cloud Run pricing in the Google Cloud Pricing Calculator is modeled on container invocation metrics including request duration, CPU/memory allocations, and request volume. Cloud Storage pricing models require capacity, data retrieval amounts, and operation counts (Class A/B) to accurately project total monthly charges.

Step-by-Step Solution

1
Identify the Cloud Run cost components required in the Pricing Calculator.
Cloud Run charges based on vCPU-seconds, gibibyte-seconds of memory, total requests, and networking egress.
Serverless pricing relies on execution time and requested hardware allocations per request.
2
Identify the Cloud Storage cost components required in the Pricing Calculator.
Storage pricing requires specifying stored capacity (GB/month), class operations (Class A and Class B operations), and data retrieval charges if using Nearline, Coldline, or Archive tiers.
Infrequently accessed logs incur retrieval fees and operation costs in addition to base storage capacity costs.
3
Evaluate the validity of the distractor choices.
Reject committed use discounts for serverless containers and cluster node provisioning for fully managed serverless infrastructure.
Cloud Run is fully managed without user-configured nodes, and standard CUDs apply to Compute Engine resources rather than request-driven Cloud Run invocations.

Key Concept

Configuring multi-service serverless and storage estimates in the GCP Pricing Calculator
Question 803Question →

A DevOps team operates a high-traffic web application on Google Kubernetes Engine (GKE). During traffic bursts, CPU utilization across application pods increases significantly beyond target thresholds. Additionally, during peak events, scaling up pod instances causes newly created pods to remain in a Pending state because current cluster nodes lack available CPU and memory resources. The team needs to implement an automated scaling architecture to handle both pod-level CPU load spikes and node-level resource shortages. Which scaling configuration should they implement?

Show answer & explanation

Answer: Configure a Horizontal Pod Autoscaler (HPA) to dynamically adjust pod replica count based on CPU utilization, and enable Cluster Autoscaler to automatically add nodes when pods are unschedulable.

Answer

Configure a Horizontal Pod Autoscaler (HPA) to scale pod replicas based on CPU metrics, and enable Cluster Autoscaler to automatically add GKE nodes when pending pods cannot be scheduled.
The correct approach combines Horizontal Pod Autoscaler (HPA) and Cluster Autoscaler. HPA scales the number of running pod instances in a Deployment based on metric thresholds like CPU usage. When HPA creates additional pods that exceed total available node memory or CPU, GKE marks those pods as Pending. Cluster Autoscaler detects these pending unschedulable pods and provisions new GKE node instances in the node pool to accommodate them.

Step-by-Step Solution

1
Identify the pod-level scaling requirement.
Recognize that CPU load spikes on existing containers require dynamically adjusting pod replica count.
Horizontal Pod Autoscaler (HPA) monitors pod metrics like CPU utilization and automatically increases or decreases pod replica count in response.
2
Identify the cluster-level scaling requirement.
Recognize that pods remaining in a Pending state due to insufficient cluster compute resources require node-level expansion.
Cluster Autoscaler detects unschedulable pods waiting for compute capacity and resizes GKE node pools by adding new virtual machine instances.
3
Combine the two autoscaling mechanisms for end-to-end elasticity.
Deploying HPA alongside Cluster Autoscaler ensures pods scale out during load increases, and nodes scale out whenever newly created pods exceed current cluster capacity.
HPA and Cluster Autoscaler operate at distinct operational layers in GKE to provide complete autoscaling capabilities.

Key Concept

GKE Workload and Node Autoscaling Architecture
Estimated Time:1m 30s
Question 804Question →

A financial analytics company receives large daily market trading datasets that are continuously queried and analyzed by automated pipelines for the first 30 days after ingestion. After 30 days, the dataset is rarely accessed, but regulatory policy mandates that the company retain these files for at least 7 years. The cloud architecture team wants to design a Cloud Storage bucket lifecycle policy that minimizes total operational and storage costs while avoiding unexpected retrieval charges during the active analytical phase. Which lifecycle management strategy should the team implement?

Show answer & explanation

Answer: Set the bucket's default storage class to Standard, and configure a lifecycle rule to transition objects to Archive storage after an age of 30 days.

Answer

Configure the bucket with Standard storage class as default to handle frequent reads with zero retrieval fees during the first 30 days, then use Object Lifecycle Management to transition objects to Archive storage after 30 days for low-cost 7-year retention.
The correct strategy starts with Standard storage class because data is queried continuously during the first 30 days, avoiding retrieval fees. Transitioning to Archive storage after 30 days minimizes storage costs for 7-year regulatory retention where data is rarely read.

Step-by-Step Solution

1
Analyze the access pattern for the initial period (0–30 days).
Data is continuously read and analyzed during this phase.
Standard storage is required because it has no retrieval fees per gigabyte read, making active analytical workloads cost-effective.
2
Analyze the access pattern for the long-term period (30 days to 7 years).
Data is rarely accessed but must be preserved for compliance.
Archive storage offers the lowest per-gigabyte monthly storage cost among Google Cloud Storage classes, perfectly fitting long-term retention requirements.
3
Determine the optimal Object Lifecycle Management rule.
A transition rule targeting age = 30 days with destination class = Archive.
Automating the transition ensures objects are moved to the cheapest storage tier exactly when active querying finishes.

Key Concept

Selecting Cloud Storage classes and Object Lifecycle Management rules based on access frequency and data retrieval costs.
Question 805Question →

An enterprise migration team has packaged an multi-endpoint REST microservice into a custom container image named `gcr.io/my-project/orders-api:v1`. The web server inside the container is explicitly compiled to listen on internal TCP port `3000` rather than reading standard environment defaults. The deployment requirements mandate using a serverless execution model with a custom identity service account (`[email protected]`) for fine-grained GCP resource access, while allowing unauthenticated public HTTPS ingress. Which `gcloud` command must a Cloud Engineer execute to successfully deploy this application to Cloud Run?

Show answer & explanation

Answer: gcloud run deploy orders-api --image=gcr.io/my-project/orders-api:v1 --port=3000 --service-account=orders-identity@my-project.iam.gserviceaccount.com --allow-unauthenticated --region=us-central1

Answer

The command starting with `gcloud run deploy orders-api --image=gcr.io/my-project/orders-api:v1 --port=3000` correctly provisions a Cloud Run service listening on internal port 3000 with the specified runtime service account and unauthenticated access.
Deploying a containerized web application listening on custom port 3000 requires `gcloud run deploy` combined with `--port=3000`, `--service-account`, and `--allow-unauthenticated`. This ensures correct traffic forwarding, appropriate identity management, and public ingress access.

Step-by-Step Solution

1
Select the appropriate GCP serverless service for custom container images with multi-endpoint web APIs.
Identify Cloud Run (`gcloud run deploy`) as the correct execution paradigm instead of Cloud Functions.
Cloud Run is optimized for stateless containerized web applications listening on HTTP/HTTPS ports.
2
Configure internal container port routing.
Include the `--port=3000` flag in the deployment invocation.
Cloud Run defaults to forwarding ingress requests to port `8080`. When a container server strictly listens on custom port `3000`, the `--port` flag overrides the default `PORT` environment variable contract.
3
Attach runtime service account identity and public ingress permissions.
Pass `--service-account=orders-identity@my-project.iam.gserviceaccount.com` and `--allow-unauthenticated` flags.
This establishes least-privilege service identity while exposing the service publicly.

Key Concept

Cloud Run Container Port Contract and Identity Deployment Flags
Estimated Time:2m 0s
Question 806Question →

A Lead Cloud Engineer is optimizing cost and availability for a GKE Standard cluster hosting a critical web API and a batch data processing pipeline. The batch pipeline consists of stateless, fault-tolerant workloads that must run strictly on cost-effective Spot VMs to reduce compute expenditure. The web API workloads must never be scheduled onto the Spot VM instances to ensure stability. Which TWO actions must you perform to configure the GKE cluster resources correctly? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Create a new GKE node pool configured with Spot VMs (`--spot`) and apply a node taint such as `workload=batch:NoSchedule` to the node pool.; Add a corresponding toleration for `workload=batch:NoSchedule` and a node selector or node affinity targeting the Spot VM node pool in the batch workload Deployment specification.

Answer

To isolate batch workloads onto Spot VMs while preventing core API workloads from being scheduled on them, you must create a dedicated Spot VM node pool with a Kubernetes taint (such as workload=batch:NoSchedule) and configure the batch processing Deployment with a matching toleration along with node selector or node affinity rules targeting the Spot node pool.
Isolating workloads on Spot VMs requires combining node taints with pod tolerations and node affinity. Tainting the Spot VM node pool with NoSchedule prevents non-batch pods (such as the web API) from being scheduled on Spot nodes. Adding the matching toleration and node selector/affinity to the batch workload specification enables and directs batch pods to land on the Spot VM nodes.

Step-by-Step Solution

1
Provision a dedicated Spot VM node pool with a taint
Node pool instances are provisioned as Spot VMs, and the taint prevents any Pod without a matching toleration from being placed on these nodes.
This guarantees that regular cluster workloads (like the API service) will not accidentally run on preemptible Spot nodes.
2
Configure batch Deployment pod spec with tolerations and node placement rules
Batch Pods gain the ability to bypass the taint and are explicitly directed to schedule on the Spot VM node pool.
Tolerations allow pods to schedule on tainted nodes, while node selectors or node affinity ensure the batch pods prefer or require the Spot node pool.

Key Concept

GKE Node Pool Isolation with Taints, Tolerations, and Spot VMs
Estimated Time:2m 0s
Question 807Question →

An infrastructure team is deploying a proprietary state-synchronization service on Compute Engine instance groups located in the us-east1 and europe-west3 regions. The service receives non-HTTP TCP traffic on port 9090, requires SSL/TLS offloading at the load balancer proxy layer, and must expose a single global IP address for client connections. Which Google Cloud load balancer type should you deploy?

Show answer & explanation

Answer: Global external Proxy Network Load Balancer

Answer

Global external Proxy Network Load Balancer
The Global external Proxy Network Load Balancer handles non-HTTP TCP traffic, terminates TLS/SSL at the load balancer proxy edge using target SSL proxies or target TCP proxies, and provides a single global IP address with backends in multiple regions.

Step-by-Step Solution

1
Analyze protocol requirements
The application uses non-HTTP raw TCP traffic on port 9090, eliminating HTTP/HTTPS (layer 7) Application Load Balancers.
Application Load Balancers expect valid HTTP/HTTPS protocol headers.
2
Analyze security and proxy requirements
SSL/TLS offloading must occur at the proxy layer before reaching backends, eliminating passthrough load balancers.
Passthrough Network Load Balancers route raw packets directly to instances without terminating SSL/TLS.
3
Determine geographic scope
The requirement specifies a single global IPv4 address distributing traffic across us-east1 and europe-west3.
Global external Proxy Network Load Balancers provide reverse proxying for TCP traffic with SSL offloading globally.

Key Concept

Selecting GCP Load Balancers Based on Traffic Protocol, SSL Termination, and Scope
Question 808Question →

You have deployed a new revision of an existing Cloud Run service named 'sales-service'. You want to route 100% of incoming user traffic to this latest revision named 'sales-service-00002-v2'. Which gcloud command should you execute to update the traffic allocation?

Show answer & explanation

Answer: gcloud run services update-traffic sales-service --to-revisions=sales-service-00002-v2=100

Answer

The command 'gcloud run services update-traffic sales-service --to-revisions=sales-service-00002-v2=100' correctly updates traffic allocation to 100% for the specified revision.
The command 'gcloud run services update-traffic' combined with '--to-revisions=sales-service-00002-v2=100' specifically assigns 100 percent of service traffic to the designated revision name.

Step-by-Step Solution

1
Identify the target Google Cloud service command group.
Cloud Run service management uses the 'gcloud run services' command group.
Cloud Run resources are distinct from Cloud Functions or generic project management.
2
Select the subcommand for modifying traffic distribution.
The subcommand 'update-traffic' modifies revision traffic percentages.
Traffic splitting allows blue/green deployments and immediate rollouts between revisions.
3
Specify the revision target flag and percentage value.
Use '--to-revisions=REVISION_NAME=100' to shift all traffic to the target revision.
The '--to-revisions' flag takes revision-to-percentage mapping pairs.

Key Concept

Cloud Run Traffic Management
Estimated Time:45s
Question 809Question →

A financial technology company is planning the network architecture for a global payment processing service. External payment gateways will communicate with backend Compute Engine instances deployed across multiple Google Cloud regions using a proprietary, non-HTTP raw TCP protocol. The company wants to terminate incoming TCP connections at the Google network edge close to clients to reduce latency and distribute incoming traffic across the multi-region backend instances. Which Google Cloud load balancer should the company select?

Show answer & explanation

Answer: External Proxy Network Load Balancer

Answer

The External Proxy Network Load Balancer is the correct choice because it supports global external non-HTTP TCP traffic and terminates client TCP connections at the Google edge network.
The External Proxy Network Load Balancer is designed for external, non-HTTP raw TCP or SSL traffic. It operates globally, terminating TCP connections at Google's network edge to optimize latency before forwarding connections to Compute Engine backends in multiple regions.

Step-by-Step Solution

1
Analyze protocol requirements
The application uses a proprietary, non-HTTP raw TCP protocol.
This rules out Layer 7 HTTP(S) load balancers which require standard HTTP/HTTPS traffic.
2
Analyze network entry and scope requirements
Traffic originates from external clients on the public internet and must be load balanced across multiple regions with edge TCP termination.
This rules out internal load balancers and regional passthrough load balancers.
3
Select matching Google Cloud load balancing service
The External Proxy Network Load Balancer meets all requirements for global reverse proxying of non-HTTP TCP traffic.
It offloads TCP connections at Google edge locations and proxies the connections to multi-region backend instance groups.

Key Concept

Selecting GCP Load Balancers based on Traffic Scope and Protocol
Question 810Question →

A mobile gaming studio is designing a new Google Kubernetes Engine (GKE) cluster architecture to host its stateless matchmaking microservices. The operations team has a strict requirement to eliminate all underlying node provisioning, node sizing, and cluster infrastructure management overhead while paying only for the CPU, memory, and storage requested by running Pods. Which GKE cluster architecture should you recommend?

Show answer & explanation

Answer: Provision a GKE Autopilot cluster.

Answer

Provisioning a GKE Autopilot cluster is the correct approach because GKE Autopilot completely hands over node management, security patching, and capacity provisioning to Google Cloud while billing only for requested Pod resources.
GKE Autopilot provisions and manages the entire underlying cluster infrastructure, including nodes, security hardening, and autoscaling. Billing is based on Pod resource requests rather than node uptime, directly satisfying the requirement to eliminate node management overhead.

Step-by-Step Solution

1
Analyze the operational requirements.
The scenario requires zero node management overhead and pod-level billing for stateless microservices.
Identifying constraint boundaries determines whether GKE Autopilot or GKE Standard fits the architecture.
2
Compare GKE Autopilot vs. GKE Standard operational models.
GKE Autopilot automates node management, upgrades, and autoscaling, charging per Pod resource request. GKE Standard requires managing node pools and node infrastructure.
Autopilot satisfies the zero node-management overhead requirement directly.

Key Concept

GKE Autopilot vs. Standard Operational Boundaries
Question 811Question →

A global logistics provider is designing a Google Kubernetes Engine (GKE) cluster strategy for two distinct workloads: a critical stateless routing microservice that requires automated infrastructure provisioning without administrative node management, and a non-critical, fault-tolerant batch analytics processing job designed to minimize compute costs. Which TWO architectural decisions should the engineering team implement to satisfy these requirements?

Select all that apply

Show answer & explanation

Answer: Deploy the stateless routing microservice in a GKE Autopilot cluster to eliminate node management and infrastructure maintenance overhead.; Provision a GKE Standard node pool utilizing Spot VMs to run the fault-tolerant batch analytics workload at a significantly discounted compute rate.

Answer

The correct decisions are to deploy the stateless routing microservice in a GKE Autopilot cluster and to provision a GKE Standard node pool utilizing Spot VMs for the batch analytics workload.
Deploying the stateless routing microservice on GKE Autopilot eliminates the need to manage, patch, or scale underlying node infrastructure. Utilizing Spot VMs in a GKE Standard node pool for fault-tolerant batch workloads dramatically reduces compute expenses while accounting for potential instance interruptions.

Step-by-Step Solution

1
Analyze the operational requirements for the critical routing microservice.
Identified that zero node management overhead and automated cluster operations are required for stateless workloads.
GKE Autopilot handles node lifecycle, security patching, and autoscaling automatically, satisfying zero node management overhead.
2
Analyze the compute and availability requirements for the batch analytics processing job.
Identified that the job is non-critical, fault-tolerant, and targeted at minimizing compute expenses.
Spot VMs offer steep discounts (up to 60-91%) compared to standard compute instances, making them optimal for interruptible batch workloads.
3
Evaluate the architectural constraints of GKE Autopilot vs. Standard and Spot VM suitability.
Confirmed that Autopilot eliminates node overhead for stateless apps and Spot node pools in GKE Standard accommodate fault-tolerant batch processing.
Critical workloads should not run on Spot VMs due to preemption risk, and Autopilot cannot be used if host OS sysctl kernel adjustments are mandatory.

Key Concept

GKE Autopilot vs Standard Operational Boundaries & Spot VM Workload Suitability
Question 812Question →

Your organization needs to perform a zero-downtime update of a production stateless web application hosted on a Compute Engine Managed Instance Group (MIG). Place the operational steps in the correct sequential order to deploy the new application version according to Google Cloud best practices.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for updating the Managed Instance Group with zero downtime is: 1) Create a new instance template containing the updated configuration, 2) Set the MIG target instance template to the new template, 3) Execute a rolling replace command with surge and unavailability constraints, and 4) Monitor instance health checks until all instances reach the UPDATED state.
Because Compute Engine instance templates are immutable, updating a Managed Instance Group (MIG) requires creating a new instance template first. Once created, the MIG target instance template reference must be updated to point to this new template. After updating the target reference, running a `rolling-action replace` command with defined `max-surge` and `max-unavailable` parameters starts the automated rollout while preserving application capacity. Finally, monitoring instance health checks ensures all new instances successfully serve traffic and transition to the `UPDATED` state.

Step-by-Step Solution

1
Create a new Compute Engine instance template
A new immutable template object is created containing the updated image and configuration.
Instance templates in Google Cloud are immutable and cannot be edited after creation.
2
Assign the new template to the Managed Instance Group
The MIG configuration points to the new template as its target resource.
The group must be explicitly configured to point to the new template before initiating rolling replacements.
3
Initiate rolling-action replace with surge controls
The MIG controller begins replacing old instances with new instances in batches.
Configuring max-surge and max-unavailable parameters ensures service capacity is maintained during the rollout.
4
Validate rollout completion via health status monitoring
All group instances complete transition to the target template and pass health checks.
Verifying instance health ensures application readiness before concluding the maintenance procedure.

Key Concept

Managed Instance Group (MIG) Rolling Updates and Instance Template Lifecycle Management
Question 813Question →

A cloud engineer is managing a Google Kubernetes Engine (GKE) Standard cluster hosting a critical microservice. During a peak traffic period, the Horizontal Pod Autoscaler (HPA) successfully increases the workload deployment replica count from 10 to 25. However, several newly created pods remain in a `Pending` state, displaying the scheduling error `0/3 nodes are available: 3 Insufficient memory`. Diagnostic checks confirm that the node pool's Cluster Autoscaler has reached its configured upper boundary of 3 nodes per zone. The application must scale out on compute nodes without altering container resource requests or converting the existing cluster operational mode. Which command should the engineer execute to allow the cluster to scale node capacity for the unscheduled workloads?

Show answer & explanation

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

Answer

Execute `gcloud container node-pools update pool-1 --cluster=prod-cluster --enable-autoscaling --min-nodes=1 --max-nodes=10 --zone=us-central1-a` to expand the maximum node limit of the node pool, enabling the Cluster Autoscaler to provision new compute nodes.
The correct option updates the node pool autoscaling configuration via `gcloud container node-pools update` to raise `--max-nodes` from 3 to 10. When pods remain in `Pending` due to insufficient memory and the node pool has reached its maximum size, increasing `--max-nodes` empowers the Cluster Autoscaler to provision additional GKE nodes dynamically.

Step-by-Step Solution

1
Analyze the cluster error state.
Pods are stuck in `Pending` state because nodes lack available memory (`3 Insufficient memory`) and the node pool has hit its max node limit.
The Horizontal Pod Autoscaler (HPA) successfully scaled the pod replicas, but Cluster Autoscaler cannot add worker nodes because it has reached `--max-nodes=3`.
2
Identify the proper scaling layer.
Cluster capacity issues must be resolved at the infrastructure layer using GKE Cluster Autoscaler node pool settings, not at the Kubernetes pod layer using HPA.
Adding more pod replicas via HPA exacerbates scheduling pressure when node capacity is capped.
3
Select the correct `gcloud` command to modify node pool autoscaling limits.
Updating the node pool autoscaling parameters using `gcloud container node-pools update` with `--max-nodes=10` increases the maximum node count constraint.
This allows GKE to automatically spin up additional GKE compute nodes to accommodate the pending pods.

Key Concept

Distinguishing between Horizontal Pod Autoscaler (HPA) pod-level scaling and Cluster Autoscaler node-level capacity management in GKE Standard clusters.
Estimated Time:2m 0s
Question 814Question →

You need to migrate a standalone application's stateful data from a persistent disk located in zone us-central1-a to a newly created Compute Engine VM instance in zone us-central1-b. What is the correct sequence of steps to accomplish this cross-zone disk data migration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: First, create a persistent disk snapshot from the source disk in us-central1-a. Second, create a new zonal persistent disk in us-central1-b using the snapshot as the source. Third, create a new Compute Engine instance in us-central1-b and attach the newly created persistent disk.
The correct sequence requires creating a snapshot first because snapshots are global resources available across all zones in a project. Next, a new zonal persistent disk must be initialized in the target zone (us-central1-b) from that global snapshot. Finally, the Compute Engine instance is launched in us-central1-b with the new disk attached, satisfying the GCP requirement that VMs and persistent disks must reside in the same zone.

Step-by-Step Solution

1
Take a snapshot of the source persistent disk in us-central1-a.
A point-in-time global snapshot of the persistent disk data is stored.
Persistent disk snapshots are project-level global resources, allowing them to cross zone boundaries.
2
Provision a new persistent disk in us-central1-b sourced from the snapshot.
A new persistent disk containing the original data is created in us-central1-b.
Persistent disks are single-zone resources and cannot be directly attached across different zones.
3
Deploy the Compute Engine instance in us-central1-b attaching the new disk.
The target instance in us-central1-b boots or mounts the restored disk data.
VM instances and their attached persistent disks must reside within the identical Google Cloud zone.

Key Concept

Compute Engine Persistent Disk Snapshots and Cross-Zone Migration
Estimated Time:1m 0s
Question 815Question →

A cloud engineer needs to deploy a Compute Engine virtual machine instance that automatically executes an initialization script stored in a private Google Cloud Storage bucket upon booting. What is the correct sequence of steps to configure access, provision the VM instance, and verify deployment execution?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by uploading the bash initialization script to the target Cloud Storage bucket, followed by granting the Storage Object Viewer IAM role to the VM's custom service account on that bucket. Next, the VM instance is created using gcloud with the attached service account, cloud-platform scope, and startup-script-url metadata key. Finally, serial port output logs are retrieved using gcloud to verify script completion.
To successfully deploy a VM configured with a startup script located in Cloud Storage, the file must first exist in the bucket. Second, the custom service account assigned to the VM must be granted `roles/storage.objectViewer` on that bucket so the boot agent can read the file. Third, running `gcloud compute instances create` with `--service-account`, `--scopes=cloud-platform`, and `--metadata=startup-script-url` provisions the VM and initiates execution. Fourth, running `gcloud compute instances get-serial-port-output` provides verification that the initialization script executed properly.

Step-by-Step Solution

1
Upload the script artifact to Google Cloud Storage.
The file `startup.sh` is stored at `gs://prod-init-scripts-bucket/startup.sh`.
The startup script resource must be uploaded to Cloud Storage before it can be referenced in metadata.
2
Configure IAM access permissions on the bucket.
Service account `[email protected]` receives `roles/storage.objectViewer`.
Applying least-privilege IAM roles ensures the VM identity is authorized to access the private bucket when fetching the script.
3
Provision the Compute Engine VM via gcloud CLI.
Instance `app-vm` starts up with custom identity and startup script metadata.
Combining `--service-account`, `--scopes=cloud-platform`, and `--metadata=startup-script-url` allows the instance startup agent to retrieve and execute the script at boot.
4
Inspect serial port output logs.
Console output confirms the initialization script finished without errors.
Retrieving serial port output is the standard method for validating startup script execution status post-deployment.

Key Concept

Provisioning Compute Engine VMs with GCS-based Startup Scripts and Custom Service Accounts
Question 816Question →

An organization is configuring an automated CI/CD pipeline to deploy infrastructure in Google Cloud using Terraform. The pipeline must store the Terraform state file in a central Google Cloud Storage (GCS) bucket named `corp-tf-state-prod` located within the project `proj-prod-infra`. The pipeline service account will execute `terraform plan` and `terraform apply`. Which TWO configurations or operational steps are required to establish a secure and resilient remote backend implementation according to Google Cloud best practices?

Select all that apply

Show answer & explanation

Answer: Configure the Terraform backend block using the `gcs` provider referencing `corp-tf-state-prod` and ensure Object Versioning is enabled on the bucket.; Authenticate the CI/CD pipeline execution using Workload Identity Federation or short-lived Service Account Impersonation instead of exporting long-lived JSON service account keys.

Answer

The two correct requirements are configuring the Terraform backend block with the `gcs` provider while ensuring Object Versioning is enabled on the GCS state bucket, and authenticating the deployment pipeline using Workload Identity Federation or Service Account Impersonation rather than downloading long-lived service account keys.
Configuring the Terraform `gcs` backend provider alongside GCS Object Versioning establishes native state locking and disaster recovery capabilities. Authenticating the deployment pipeline via Workload Identity Federation or IAM Service Account Impersonation avoids long-lived credentials, aligning directly with Google Cloud security benchmarks for automated infrastructure deployment.

Step-by-Step Solution

1
Identify the proper backend configuration and state preservation mechanism for Terraform on Google Cloud.
Terraform uses the `gcs` backend type for Google Cloud Storage, which automatically provides native object locking. Object Versioning on the bucket ensures state state history is retained for disaster recovery.
Remote state files are critical assets; versioning prevents permanent data loss during concurrent or failed updates.
2
Select the secure authentication strategy for automated pipeline service accounts.
Workload Identity Federation allows short-lived token generation for external CI/CD systems without managing physical JSON key files.
Google Cloud security best practices explicitly advise against exporting long-lived service account keys.
3
Evaluate distractor options regarding IAM privilege scope and API requirements.
Over-privileged primitive roles and enabling unrelated APIs in billing accounts are incorrect operational procedures.
Least privilege access must be enforced using granular predefined roles scoped to specific resources.

Key Concept

Terraform GCS Remote Backend Architecture & Secure Service Account Authentication
Question 817Question →

A software engineering team is deploying a custom containerized internal service named billing-service to Google Cloud Run in the us-central1 region. The application container is hardcoded to listen for incoming gRPC traffic on TCP port 5000 rather than the default port 8080. The service must execute under a specific non-default service account named [email protected] and must block unauthenticated public invocations. Which gcloud command correctly deploys this service according to the security and operational requirements?

Show answer & explanation

Answer: gcloud run deploy billing-service --image=gcr.io/my-project/billing-service:v1 --port=5000 [email protected] --no-allow-unauthenticated

Answer

The correct deployment command is gcloud run deploy billing-service --image=gcr.io/my-project/billing-service:v1 --port=5000 [email protected] --no-allow-unauthenticated.
The correct command uses gcloud run deploy with --port=5000 to direct incoming traffic to the container's listening port, --service-account to bind the dedicated IAM identity, and --no-allow-unauthenticated to restrict unauthenticated access.

Step-by-Step Solution

1
Identify container port requirements for Cloud Run
By default, Cloud Run routes HTTP requests to port 8080. If a container listens on port 5000, the --port=5000 flag must be passed to gcloud run deploy.
Ensures the Cloud Run proxy forwards ingress requests to the container's active listening port.
2
Identify service account configuration flag
To override the default Compute Engine service account, use --service-account followed by the full service account email address.
Adheres to the principle of least privilege by running the workload under a dedicated IAM identity.
3
Configure authentication requirements
Pass --no-allow-unauthenticated to ensure IAM authentication is enforced for all ingress requests.
Prevents unauthorized public access to the deployed microservice.

Key Concept

Deploying containerized workloads on Cloud Run with non-default port bindings, custom service accounts, and IAM ingress controls.
Question 818Question →

An infrastructure engineer needs to grant local administrative tools access to a newly created Google Kubernetes Engine (GKE) cluster named `analytics-prod` located in the `us-central1` region. When attempting to execute `kubectl get nodes`, the command fails with a connection refused error because local context credentials are missing. Which command should the engineer run to populate kubeconfig with the required cluster credentials?

Show answer & explanation

Answer: gcloud container clusters get-credentials analytics-prod --region us-central1

Answer

The command `gcloud container clusters get-credentials analytics-prod --region us-central1` updates the local kubeconfig file with endpoint details and authentication credentials required by kubectl.
Executing `gcloud container clusters get-credentials analytics-prod --region us-central1` automatically downloads the endpoint information and authentication token helper for the specified cluster, appending or updating the context in the local `kubeconfig` file.

Step-by-Step Solution

1
Identify the requirement to configure local cluster context for kubectl.
Recognize that gcloud CLI manages GKE cluster authentication entry generation.
Directly running `kubectl` without cluster credentials in kubeconfig results in endpoint connection failures.
2
Select the correct gcloud container command and location flags.
`gcloud container clusters get-credentials analytics-prod --region us-central1` writes authentication context into `~/.kube/config`.
Specifying the cluster name and region ensures the correct control plane API endpoint is targeted.

Key Concept

Configuring kubectl credentials for GKE cluster management using gcloud CLI.
Estimated Time:1m 30s
Question 819Question →

A financial technology company uses the Google Cloud Pricing Calculator to model monthly compute expenses for a batch processing workload running on standard Compute Engine virtual machines. The workload executes for 4 hours each night, totaling 120 hours over a standard 730-hour billing month.

How will the Google Cloud Pricing Calculator apply Sustained Use Discounts (SUDs) to this Compute Engine estimate?

Show answer & explanation

Answer: The calculator will not apply Sustained Use Discounts because the workload runs for less than the 25% monthly usage threshold (~182.5 hours) required to qualify for SUDs.

Answer

The Google Cloud Pricing Calculator will not apply Sustained Use Discounts because the total runtime of 120 hours is below the 25% monthly usage threshold (~182.5 hours) required for SUD eligibility.
Google Cloud Sustained Use Discounts (SUDs) automatically apply to Compute Engine instances that run for more than 25% of a billing month (~182.5 hours based on a 730-hour month). Because the batch workload runs for 4 hours per day for 30 days, total runtime is 120 hours. Since 120 hours is below the 25% threshold, the Pricing Calculator correctly estimates costs at the baseline hourly rate without applying SUDs.

Step-by-Step Solution

1
Determine total monthly hours used in the cost estimation scenario.
4 hours/day * 30 days = 120 hours per month.
Cumulative instance runtime determines eligibility for automatic sustained use discounting.
2
Calculate the sustained use discount threshold percentage for a standard GCP billing month (730 hours).
25% of 730 hours = 182.5 hours.
Google Cloud Compute Engine requires instances to run for more than 25% of the month before SUD discounts begin to accrue.
3
Compare workload runtime against the SUD eligibility threshold.
120 hours < 182.5 hours, so 0% SUD discount is applied in the calculator.
Workloads falling below the 25% threshold incur standard baseline hourly rates without automatic sustained use discounts.

Key Concept

Compute Engine Sustained Use Discount (SUD) Threshold Mechanics
Estimated Time:1m 30s
Question 820Question →

A cloud engineer needs to configure a Google Kubernetes Engine (GKE) Standard cluster to execute fault-tolerant, stateless batch processing workloads while minimizing compute expenditure. The cluster control plane and core system workloads must remain stable, while the batch jobs should run on low-cost compute resources that can be reclaimed at any time. Which TWO actions should the engineer perform to implement this operational strategy?

Select all that apply

Show answer & explanation

Answer: Create a secondary node pool configured with Spot VMs to host the batch processing workloads.; Add node selectors or taints and tolerations to the batch workload deployment manifest to target the Spot VM node pool.

Answer

To minimize compute costs for fault-tolerant workloads on GKE, the engineer should create a secondary node pool utilizing Spot VMs and configure the batch deployment manifests with node selectors or taints and tolerations to ensure pods are scheduled onto the Spot nodes.
For fault-tolerant, stateless batch workloads, creating a dedicated node pool powered by Spot VMs provides maximum cost efficiency. To ensure batch tasks execute strictly on these nodes and do not disrupt system services, node selectors or taints and tolerations must be defined in the workload deployment specification.

Step-by-Step Solution

1
Provision a dedicated Spot VM node pool
A node pool using discounted Spot VMs is added to the existing GKE cluster.
Spot VMs offer steep discounts compared to standard Compute Engine instances and are ideal for fault-tolerant batch workloads.
2
Configure Kubernetes scheduling constraints in the batch workload manifest
Batch pods are targeted specifically to the Spot VM node pool via nodeSelector or taints and tolerations.
Explicit scheduling constraints prevent batch workloads from consuming standard nodes and ensure core system pods remain separated from preemptible infrastructure.

Key Concept

Deploying fault-tolerant workloads using GKE Spot VM node pools and Kubernetes pod scheduling
PreviousPage 41 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin