Google ACE Deploying and implementing a cloud solution Practice Test 3 — 15 Questions

Question 1

A GKE team is comparing Autopilot and Standard cluster modes for a new project. They want to minimize infrastructure management overhead, automatically right-size node resources, and be billed only for Pod resource requests. Which mode matches these requirements?

Accepted Answer

GKE Autopilot — managed nodes, automatic right-sizing, and per-Pod billing. GKE Autopilot is the correct choice because it fully manages the underlying node infrastructure, automatically right-sizes node resources based on Pod resource requests, and bills only for the requested CPU and memory of Pods, not the underlying nodes. This aligns directly with the team's goals of minimizing management overhead, automatic right-sizing, and per-Pod billing.

Answer

GKE Standard — it provides more control over node configuration

Answer

GKE Standard with cluster autoscaler and node auto-provisioning enabled

Answer

Both modes are equivalent in management overhead — Autopilot is just a pricing model

Question 2

A developer wants to see the details of a specific GKE Pod including its events, container status, and resource requests/limits. Which kubectl command provides this?

Accepted Answer

kubectl describe pod [POD_NAME]. B is correct because `kubectl describe pod` provides a comprehensive view of a pod, including its events (e.g., scheduling, pulling images), container status (e.g., waiting, running, terminated with reasons), and resource requests/limits (CPU and memory). This command aggregates detailed information from the Kubernetes API, making it the standard tool for debugging pod issues.

Answer

kubectl get pod [POD_NAME] -o wide

Answer

kubectl inspect pod [POD_NAME]

Answer

kubectl get pod [POD_NAME] -o json

Question 3

A GKE Deployment is running 3 replicas and receiving steady traffic. A junior engineer runs `kubectl scale deployment api-service --replicas=0` to 'stop it temporarily'. What happens to traffic during and after this command?

Accepted Answer

All Pods are terminated immediately; the Service has no backends and requests fail until replicas are restored. When you scale a Deployment to 0 replicas, `kubectl` immediately terminates all Pods. The associated Kubernetes Service continues to exist but has no healthy endpoints, so any traffic directed to the Service’s ClusterIP or external load balancer will be dropped or result in a connection refusal (TCP RST) or HTTP 503. Traffic is not queued or buffered; it simply fails until new Pods are created by scaling the Deployment back up.

Answer

Traffic is paused and queued by the Service until replicas are restored

Answer

GKE detects the replica count is 0 and automatically restores it to maintain high availability

Answer

The Deployment is paused but Pods continue running until the next rollout

Question 4

A team's GKE Deployment serves variable traffic — 2 Pods at night, 20 Pods at peak hours. Rather than manually changing replica counts, they want automatic scaling based on CPU utilization (target: 60%). What should they deploy?

Accepted Answer

Horizontal Pod Autoscaler (HPA) targeting 60% CPU utilization. The Horizontal Pod Autoscaler (HPA) is the correct choice because it automatically adjusts the number of Pod replicas in a Deployment based on observed CPU utilization, scaling from 2 to 20 Pods as needed to maintain the target of 60% CPU. HPA works by querying the metrics server for CPU usage and calculating the desired replica count using the formula: desiredReplicas = currentReplicas × (currentMetricValue / targetMetricValue). This directly addresses the requirement for variable traffic without manual intervention.

Answer

Vertical Pod Autoscaler (VPA) with CPU target 60%

Answer

Cluster Autoscaler with a CPU threshold of 60%

Answer

Set the Deployment replica count to 20 and rely on resource quotas to limit actual Pod scheduling

Question 5

A team deploys a new version of their application using a blue-green strategy on GKE. The 'green' deployment is running but still in testing. When ready, traffic should instantly switch from 'blue' to 'green' with rollback possible in seconds. How is the instant switch implemented?

Accepted Answer

Update the Service's label selector from 'version: blue' to 'version: green'. Option B is correct because in a blue-green deployment on GKE, the Service acts as a stable network endpoint abstracting the underlying Pods. By changing the Service's label selector from 'version: blue' to 'version: green', traffic is instantly routed to the green Pods without any downtime or need to recreate resources. This allows immediate rollback by simply reverting the selector back to 'version: blue'.

Answer

Delete the blue Deployment and create the green Deployment as the replacement

Answer

Update the Deployment's container image tag — GKE automatically performs a blue-green rollout

Answer

Use kubectl patch to update the Service's ClusterIP to point to the green Deployment

Question 6

A Cloud Run service requires access to a private Cloud SQL instance in the same VPC. The Cloud SQL instance is not publicly accessible. How should the Cloud Run service connect to Cloud SQL without using the Cloud SQL Auth Proxy separately?

Accepted Answer

Configure the Cloud Run service with `--add-cloudsql-instances` to connect via the built-in Auth Proxy. Option B is correct because the Cloud Run service can use the `--add-cloudsql-instances` flag, which automatically deploys a built-in Cloud SQL Auth Proxy sidecar container within the same pod. This proxy establishes a secure, encrypted connection to the private Cloud SQL instance using the instance's private IP, without requiring the instance to have a public IP or the user to manage a separate proxy. The proxy authenticates via the service account attached to the Cloud Run service, enabling seamless and secure connectivity.

Answer

Use the Cloud SQL public IP with SSL required — Cloud Run can reach public IPs

Answer

Deploy a separate Cloud SQL Auth Proxy container in the same Cloud Run service as a sidecar

Answer

Enable Serverless VPC Access connector to route Cloud Run traffic to the private Cloud SQL IP

Question 7

A team runs a Kubernetes CronJob that performs nightly database cleanup. The job runs at 2 AM UTC. This morning, the team notices the job failed at 2 AM but no one was alerted. How should the team configure alerting for CronJob failures?

Accepted Answer

Create a log-based metric on CronJob failure events in Cloud Logging and an alerting policy on that metric. Option B is correct because Google Cloud Logging captures Kubernetes CronJob failure events, and you can create a log-based metric to count these failures. An alerting policy on that metric then triggers notifications when failures occur, providing a reliable, customizable alerting mechanism that does not depend on job history or restart policies.

Answer

Set `successfulJobsHistoryLimit: 0` — GKE sends an alert when the history is empty

Answer

Set `restartPolicy: Always` on the CronJob's Pod template — it will retry until success

Answer

Enable GKE's built-in CronJob alerting feature in the cluster's Notifications settings

Question 8

A developer needs to forward traffic from their local port 5432 to a PostgreSQL service running in GKE on port 5432, to test database queries locally without exposing the database externally. Which kubectl command achieves this?

Accepted Answer

kubectl port-forward svc/postgres-service 5432:5432. Option B is correct because `kubectl port-forward` creates a local tunnel from port 5432 on the developer's machine to the specified service's port 5432 inside the GKE cluster. This allows the developer to connect to the PostgreSQL service as if it were running locally, without exposing it to the internet via a LoadBalancer or Ingress.

Answer

kubectl expose pod postgres-pod --type=LoadBalancer --port=5432

Answer

kubectl tunnel --local=5432 --remote=postgres-service:5432

Answer

gcloud container ssh postgres-pod --port-forward=5432:5432

Question 9

A team uses Terraform to manage GCP infrastructure. After running `terraform plan`, they see 15 resources to be created. They want to apply only the Cloud SQL instance (resource name: `google_sql_database_instance.main`) without applying all 15 changes. Which Terraform command targets a specific resource?

Accepted Answer

terraform apply -target=google_sql_database_instance.main. Option B is correct because Terraform uses the `-target` flag to limit the operation to a specific resource address, allowing you to apply only the `google_sql_database_instance.main` resource without affecting the other 14 resources in the plan. This is the standard Terraform syntax for targeting a single resource during `apply` or `destroy` operations.

Answer

terraform apply --resource=google_sql_database_instance.main

Answer

terraform apply -only=google_sql_database_instance.main

Answer

terraform plan --filter=google_sql_database_instance.main && terraform apply

Question 10

A team deploys a Cloud Run service that must access resources in a private VPC (a private Cloud SQL instance and a Redis instance on Memorystore). The Cloud Run service has no public IP connectivity requirements for these resources. What must be configured?

Accepted Answer

Configure a Serverless VPC Access connector and specify it in the Cloud Run service deployment. Cloud Run is a serverless compute platform that runs in a Google-managed VPC, not the customer's VPC. To access private resources like Cloud SQL and Memorystore (Redis) within a customer VPC, you must configure a Serverless VPC Access connector. This connector bridges the serverless environment to the specified VPC, enabling private, internal IP communication without public internet exposure.

Answer

Enable VPC Service Controls around Cloud Run to connect it to the VPC

Answer

Assign an external IP to the Cloud SQL and Memorystore instances — Cloud Run can reach them via public internet

Answer

Cloud Run automatically connects to any VPC resource in the same project via project-level networking

Question 11

A platform engineer is deploying a Kubernetes Job that processes a batch of records. The Job should run 10 parallel workers, each processing a subset of records, and complete when all workers finish successfully. Which Job spec configuration achieves this?

Accepted Answer

Set parallelism: 10 and completions: 10 in the Job spec. Option B is correct because in Kubernetes, a Job's `parallelism` field specifies the number of Pods that can run concurrently, and `completions` specifies the total number of successful Pod completions required for the Job to be considered finished. Setting both to 10 ensures exactly 10 Pods run in parallel, each processing a subset of records, and the Job completes only when all 10 have succeeded.

Answer

Set replicas: 10 in the Job spec

Answer

Create 10 separate Job objects — one per worker

Answer

Set concurrency: 10 in the Job spec

Question 12

You have a Kubernetes Deployment running 5 replicas. You need to update the container image with zero downtime, ensuring that at least 4 replicas are always available during the update, and no more than 6 replicas exist at any time. Which Deployment strategy and settings achieve this?

Accepted Answer

RollingUpdate with `maxUnavailable: 1` and `maxSurge: 1`.. Option B is correct because a RollingUpdate strategy with `maxUnavailable: 1` and `maxSurge: 1` ensures that during the update, at most one replica is taken down (so at least 4 remain available) and at most one extra replica is created above the desired 5 (so no more than 6 exist at any time). This satisfies both constraints while achieving zero downtime.

Answer

Recreate strategy with `minReadySeconds: 30`.

Answer

RollingUpdate with `maxUnavailable: 0` and `maxSurge: 2`.

Answer

RollingUpdate with `maxUnavailable: 2` and `maxSurge: 1`.

Question 13

A developer needs to test a Cloud Run service locally before deploying it to GCP. The service is packaged as a Docker container. Which tool allows them to run and test the container locally in a way that closely mimics the Cloud Run execution environment?

Accepted Answer

Run the container using `docker run -p 8080:8080 IMAGE` with the required environment variables.. Option A is correct because `docker run -p 8080:8080 IMAGE` with the required environment variables directly runs the containerized Cloud Run service on your local machine, mapping port 8080 to the container's port 8080 (the default Cloud Run listens on). This approach closely mimics the Cloud Run execution environment because Cloud Run also runs containers in a Docker-like runtime, and you can replicate environment variables, memory limits, and concurrency settings locally for accurate testing before deployment.

Answer

Deploy the service to a staging Cloud Run environment using `gcloud run deploy --no-traffic`.

Answer

Use `gcloud run services describe` to simulate a local run.

Answer

Use Cloud Shell to run the container since Cloud Shell has Docker installed.

Question 14

Your team uses Cloud Build to build and push Docker images to Artifact Registry. A new security requirement mandates that only images signed by Cloud Build (using Binary Authorization with attestors) can be deployed to your GKE cluster. Which sequence of steps correctly implements this?

Accepted Answer

Create a Cloud KMS key and attestor, configure Cloud Build to create attestations post-build, then set a BinAuthz policy requiring the attestation on the GKE cluster.. Option B is correct because it follows the required workflow: you must first create a Cloud KMS key and an attestor in Binary Authorization, then configure Cloud Build to generate an attestation (signed by the attestor) after each successful build. Finally, you set a Binary Authorization policy on the GKE cluster that enforces the attestation, ensuring only signed images are deployed. Cloud Build does not automatically sign images when BinAuthz is enabled; the attestation must be explicitly created.

Answer

Enable BinAuthz on the GKE cluster; Cloud Build automatically signs images when BinAuthz is enabled.

Answer

Use Artifact Registry vulnerability scanning; images that pass scanning are automatically trusted by GKE.

Answer

Add a Cloud Build step that runs `gcloud container binauthz attestations sign-and-create` without additional configuration.

Question 15

You have a Cloud Run service configured with `min-instances: 0`. During load testing you notice the first request after a period of inactivity takes 3–5 seconds instead of the normal 100ms. Subsequent requests are fast. What is causing this, and what is the most cost-effective fix?

Accepted Answer

Set `min-instances: 1` to keep a warm instance running and eliminate the cold start latency.. Cold starts occur when Cloud Run needs to spin up a new container instance from zero. The 3–5 second delay is the container startup time. Setting `min-instances: 1` keeps at least one instance warm at all times, eliminating cold starts for the first request. This adds a small cost (one always-running instance) but is the most targeted fix. Increasing memory or CPU doesn't directly address cold start if the issue is container initialization time.

Answer

The Cloud Run service's container image is too large; reduce image size.

Answer

Switch from Cloud Run to GKE, which doesn't have cold starts.

Answer

Increase Cloud Run's request timeout to 30 seconds to accommodate cold starts.