Associate Cloud Engineer · 20% of the exam

Ensuring successful operation: free practice questions

5 sample questions from our 50-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real Google Cloud exam.

1. Your GKE cluster uses Workload Identity for pod authentication to Google Cloud services. A pod in a Deployment is failing to authenticate to Cloud Storage, even though the service account has the necessary Storage permissions. You have verified that Workload Identity is enabled on the cluster. What should you check first?

A. Verify that the pod's Kubernetes service account is annotated with the Google service account mapping (iam.gke.io/gcp-service-account)✓ Correct
B. Check that the Kubernetes service account exists in the 'default' namespace
C. Ensure the pod is using the correct image with GOOGLE_APPLICATION_CREDENTIALS set
D. Confirm that the Google service account has the serviceAccountTokenCreator role on the cluster

Explanation

The correct answer is to verify that the pod's Kubernetes service account is annotated with the Google service account mapping (iam.gke.io/gcp-service-account). This annotation is required for Workload Identity to function; without it, the pod cannot assume the Google service account. Option 1 is wrong because the namespace where the Kubernetes service account exists is relevant, but the annotation is the primary requirement. Option 2 is wrong because GOOGLE_APPLICATION_CREDENTIALS is used for other authentication methods (JSON key files); Workload Identity doesn't require this environment variable. Option 3 is wrong because the cluster itself doesn't need a specific role; the Google service account and Kubernetes service account must be bound via workload identity binding (gcp-iam-binding).

2. You need to rotate credentials for a Cloud Spanner instance that uses a custom VPC connector. Which of the following operations requires a restart or recreation of the instance?

A. Updating the database encryption key in Cloud Spanner console
B. Changing the Spanner instance's node count from 3 nodes to 5 nodes
C. Recreating the VPC connector associated with the instance✓ Correct
D. Updating IAM permissions for the service account that accesses the instance

Explanation

Recreating the VPC connector (option 2) will require re-establishing the connection and may necessitate instance-level changes or validation. Option 0 is incorrect—encryption key rotation in Cloud Spanner is handled transparently and doesn't require a restart. Option 1 is incorrect—scaling node count is a non-disruptive operation in Cloud Spanner. Option 3 is incorrect—IAM permission updates don't require instance changes; they apply immediately. The key distinction is that VPC connector recreation is infrastructure-level and can affect instance connectivity.

3. You manage a Pub/Sub topic that receives approximately 1 million messages per day. A new subscriber is consistently failing to acknowledge messages within the default 10-second deadline, causing message redelivery and processing duplicates. You want to minimize duplicate processing and reduce redelivery rates. What should you do?

A. Increase the Pub/Sub topic's message retention period from 7 days to 30 days
B. Create a new subscription with an increased ack deadline (e.g., 120 seconds) and configure the subscriber to handle longer processing
C. Delete and recreate the Pub/Sub topic with a higher throughput tier
D. Implement idempotency in your subscriber application and increase the ack deadline to provide more processing time✓ Correct

Explanation

Option 3 is best because it combines two key fixes: (1) increasing the ack deadline gives the subscriber more time to process before redelivery, and (2) implementing idempotency ensures that any redelivered messages are handled gracefully without duplicates. Option 0 is incorrect—message retention period doesn't affect ack deadlines; it only controls how long undelivered messages are kept. Option 1 is a partial fix (increasing ack deadline is correct) but doesn't address handling duplicate redeliveries. Option 2 is overkill and unnecessary; the issue isn't topic throughput but subscriber processing speed.

4. You manage a GKE cluster and need to perform a node pool upgrade from Kubernetes 1.25 to 1.26. You want to ensure zero downtime for your production workloads. What is the correct sequence of steps?

A. Upgrade the GKE master to 1.26, then immediately upgrade all nodes in the node pool to 1.26
B. Upgrade the GKE master to 1.26, wait for node auto-upgrades to complete, then manually verify node versions
C. Create a new node pool with Kubernetes 1.26, migrate workloads to the new pool, then delete the old pool✓ Correct
D. Upgrade the node pool to 1.26 first, then upgrade the master after nodes are ready

Explanation

Option 2 is the safest approach for zero-downtime upgrades in a production environment. By creating a new node pool, you can migrate workloads gradually and safely, minimizing risk. Option 0 is dangerous—upgrading the master first creates version skew, and immediately upgrading all nodes causes downtime. Option 1 relies on auto-upgrades which you don't control and may not be fast enough. Option 3 violates the GKE upgrade sequence; the master must be upgraded before nodes. In GKE, the master is always upgraded first, but for minimal downtime with existing workloads, the blue-green node pool approach (option 2) is preferred.

5. You are investigating a production issue in your GKE cluster where node pool scaling is not responding to increased workload demand. Metrics show that CPU usage is at 85%, but new Pods are failing to schedule. What are the three most likely causes? (Select THREE)

A. The node pool has a maximum node limit that has been reached✓ Correct
B. The cluster's Kubernetes API server is overloaded and rejecting new Pod scheduling requests
C. Pods have resource requests that exceed the available capacity on existing nodes✓ Correct
D. The node pool's autoscaler is disabled or the autoscaling configuration is missing✓ Correct
E. The nodes are running out of disk space (ephemeral storage), preventing new Pods from being scheduled
F. The node pool uses a custom machine type with insufficient vCPU allocation

Explanation

The three most likely causes of scheduling failures despite high CPU are: (0) the node pool has reached its max node limit, preventing autoscaling from adding more nodes; (2) Pods request more resources than available nodes can provide, blocking scheduling even if nodes exist; and (3) autoscaling is disabled or misconfigured, so no new nodes are created. Option 1 is unlikely—API server overload typically manifests as slow API responses, not Pod scheduling failures. Option 4 is a possibility but less common than resource request mismatches or autoscaler misconfiguration. Option 5 refers to machine type size, which is a configuration issue not a scaling response issue.

45 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free