Knowledge + Practice

CCNA Deploying And Implementing A Cloud Solution Questions

75 of 99 questions · Page 1/2 · Deploying And Implementing A Cloud Solution topic · Answers revealed

Practice these questions Exam hub All questions

1

MCQmedium

You need to run a database migration script once before deploying a new version of an application to GKE. The migration must complete before any application pods start. Which Kubernetes feature enables this pattern?

A.A Kubernetes CronJob scheduled to run the migration before deployment.

B.A Kubernetes init container in the Pod spec that runs the migration script.

C.A readiness probe that runs the migration script before marking the pod as ready.

D.A Kubernetes Job that runs the migration, with the Deployment configured to start only after the Job completes.

AnswerB

Init containers run and must complete successfully before the main containers start. This guarantees the migration runs exactly once per pod before the app starts.

Why this answer

Init containers run sequentially before the main application containers in a Pod start, ensuring the migration script completes before any application pods become ready. This guarantees the migration runs exactly once per Pod lifecycle, which aligns with the requirement that the migration must finish before deployment.

Exam trap

Google Cloud often tests the distinction between init containers and Jobs, where candidates mistakenly think a Job can be used as a prerequisite for a Deployment without additional custom controllers or hooks.

How to eliminate wrong answers

Option A is wrong because a CronJob runs on a schedule, not as a prerequisite for Pod startup, and cannot guarantee completion before application pods start. Option C is wrong because a readiness probe only checks if a pod is ready to serve traffic; it does not run scripts before the main container starts, and running a migration in a probe would be unreliable and could cause probe failures. Option D is wrong because a Kubernetes Job runs independently of a Deployment; the Deployment does not automatically wait for a Job to complete unless custom orchestration (e.g., using a hook or manual sequencing) is implemented, which is not a built-in feature.

Practice this question →

2

MCQmedium

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?

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

B.All Pods are terminated immediately; the Service has no backends and requests fail until replicas are restored

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

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

AnswerB

`scale --replicas=0` terminates all Pods. The Service loses all endpoints and incoming traffic fails. Running `kubectl scale --replicas=3` restores the Pods.

Why this answer

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.

Exam trap

Google Cloud often tests the misconception that Kubernetes Services can queue or buffer traffic during scaling events, when in reality they are stateless and rely on real-time endpoint availability.

How to eliminate wrong answers

Option A is wrong because Kubernetes Services do not queue or buffer traffic; they rely on real-time endpoint discovery via the EndpointSlice controller, and with zero endpoints, packets are either rejected or blackholed. Option C is wrong because GKE does not automatically restore a Deployment’s replica count; the user explicitly set `--replicas=0`, and Kubernetes respects that desired state without any built-in high-availability override. Option D is wrong because scaling to 0 immediately terminates Pods; the Deployment is not paused, and Pods do not continue running — `kubectl scale` directly modifies the `spec.replicas` field, triggering a rollout that deletes all Pods.

Practice this question →

3

MCQhard

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?

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

B.Configure a Serverless VPC Access connector and specify it in the Cloud Run service deployment

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

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

AnswerB

Serverless VPC Access connectors create a bridge between Cloud Run and the VPC network. The connector is specified with `--vpc-connector` at deploy time, enabling private IP access to Cloud SQL and Memorystore.

Why this answer

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.

Exam trap

Google Cloud often tests the misconception that serverless services like Cloud Run can natively reach VPC resources without explicit configuration, or that VPC Service Controls provide connectivity rather than security boundaries.

How to eliminate wrong answers

Option A is wrong because VPC Service Controls are a security perimeter mechanism that prevents data exfiltration, not a connectivity method for Cloud Run to reach VPC resources. Option C is wrong because assigning external IPs to Cloud SQL and Memorystore would expose them to the public internet, violating the requirement for no public IP connectivity and introducing security risks. Option D is wrong because Cloud Run does not automatically connect to VPC resources; it runs in a Google-managed network and requires explicit configuration (e.g., Serverless VPC Access or Direct VPC) to access private VPC resources.

Practice this question →

4

MCQhard

An organization needs to deploy a batch job that runs every hour on Compute Engine. The job requires a VM with 16 vCPUs and 64 GB of memory. The job takes approximately 20 minutes to complete. The team wants to minimize costs while ensuring the job completes reliably. Which deployment strategy should they use?

A.Use spot VMs with a restart policy configured in the instance template

B.Use committed use discounts for the VM

C.Create an always-on VM and use sustained-use discounts

D.Use preemptible VMs and accept the risk of termination

AnswerA

Spot VMs are cheaper than preemptible and can be restarted if terminated.

Why this answer

Option A (sustained-use discount) is for always-on VMs, not suitable for hourly jobs. Option B (preemptible VMs) are cheaper but can be terminated, risking job failure. Option D (committed use discounts) require 1- or 3-year commitments, which is overkill.

Option C (spot VMs with a restart policy) is correct: Spot VMs are similar to preemptible but more affordable, and configuring a restart policy ensures the job resumes if interrupted.

Practice this question →

5

MCQeasy

You have pushed a new container image to Artifact Registry. The image is tagged `us-central1-docker.pkg.dev/my-project/my-repo/app:v2.0`. You need to deploy this specific image version to Cloud Run in production. Which command deploys this exact image?

A.`gcloud run deploy app --image us-central1-docker.pkg.dev/my-project/my-repo/app:v2.0 --region us-central1`

B.`gcloud run services update app --tag v2.0 --region us-central1`

C.`docker push us-central1-docker.pkg.dev/my-project/my-repo/app:v2.0` followed by a Cloud Run auto-deploy.

D.`gcloud run deploy app --image app:v2.0 --region us-central1`

AnswerA

This command deploys the exact image version specified by the full Artifact Registry path and tag. --region specifies the Cloud Run deployment region.

Why this answer

Option A is correct because the `gcloud run deploy` command with the `--image` flag explicitly specifies the exact container image URI from Artifact Registry, including the tag `v2.0`. This ensures that Cloud Run deploys that precise version of the image, and the `--region` flag targets the correct regional service. The full URI is required because Cloud Run must pull the image from the exact repository path and tag.

Exam trap

Google Cloud often tests the requirement to use the full image URI (including registry, project, repository, and tag) versus a short name, and the misconception that `docker push` or service update commands can trigger a deployment directly.

How to eliminate wrong answers

Option B is wrong because `gcloud run services update` with `--tag` does not exist; the `--tag` flag is used with `gcloud run deploy` to assign a traffic tag, not to specify an image version. Option C is wrong because `docker push` only uploads the image to the registry; it does not trigger a Cloud Run deployment, and there is no automatic 'auto-deploy' mechanism unless a Cloud Build trigger is configured separately. Option D is wrong because `--image app:v2.0` is a relative reference that omits the full registry path (`us-central1-docker.pkg.dev/my-project/my-repo/`), which Cloud Run requires to locate the image in Artifact Registry; without the full URI, the command will fail or pull from the wrong source.

Practice this question →

6

MCQmedium

A company is running a Cloud SQL for MySQL instance that experiences high read traffic. They want to offload read queries to reduce load on the primary instance. Which action should they take?

A.Enable automatic storage increase on the primary instance

B.Increase the machine type of the primary instance

C.Create one or more read replicas and direct read queries to them

D.Change the instance to use private IP only

AnswerC

Read replicas handle read traffic, reducing load on the primary.

Why this answer

Creating one or more read replicas allows you to offload read queries from the primary Cloud SQL for MySQL instance. Read replicas are asynchronous replicas that can serve read traffic, reducing load on the primary and improving overall read throughput. This is the correct approach for scaling read-heavy workloads without modifying the primary instance.

Exam trap

Google Cloud often tests the distinction between scaling up (increasing machine type) and scaling out (adding read replicas), where candidates mistakenly choose vertical scaling for read offloading instead of horizontal read replication.

How to eliminate wrong answers

Option A is wrong because enabling automatic storage increase only prevents out-of-disk errors by expanding storage, it does not offload read queries or reduce CPU/memory load from reads. Option B is wrong because increasing the machine type of the primary instance scales up the primary itself but does not offload read traffic; it may temporarily improve performance but does not distribute the read load. Option D is wrong because changing to private IP only affects network connectivity and security, not read query distribution or load reduction.

Practice this question →

7

MCQmedium

A team wants to deploy a container image at 'gcr.io/myproject/api:v2' as a Cloud Run service named 'api-service' in us-east1, accessible without authentication. Which command is correct?

A.gcloud run deploy api-service --image=gcr.io/myproject/api:v2 --region=us-east1 --allow-unauthenticated

B.gcloud run create api-service --image=gcr.io/myproject/api:v2 --zone=us-east1 --public

C.gcloud cloud-run deploy api-service --container=gcr.io/myproject/api:v2 --region=us-east1

D.gcloud run deploy --name=api-service --image=gcr.io/myproject/api:v2 --region=us-east1 --no-auth

AnswerA

This is the correct syntax for deploying a Cloud Run service with public access. `--allow-unauthenticated` enables unauthenticated invocations.

Why this answer

Option A is correct because it uses the `gcloud run deploy` command with the `--image` flag to specify the container image, `--region=us-east1` to target the correct region, and `--allow-unauthenticated` to make the service publicly accessible without authentication. This matches the exact requirements for deploying a Cloud Run service with public access.

Exam trap

Google Cloud often tests the distinction between `gcloud run deploy` and `gcloud run create`, and the use of `--allow-unauthenticated` versus `--no-auth`, to catch candidates who confuse command syntax or flag names.

How to eliminate wrong answers

Option B is wrong because `gcloud run create` is not a valid command; the correct command is `gcloud run deploy`. Additionally, Cloud Run uses `--region` (not `--zone`) and `--allow-unauthenticated` (not `--public`). Option C is wrong because `gcloud cloud-run deploy` is not a valid command (the correct service is `gcloud run deploy`), and `--container` is not a valid flag for `gcloud run deploy`; the correct flag is `--image`.

Option D is wrong because `--no-auth` is not a valid flag; the correct flag to allow unauthenticated access is `--allow-unauthenticated`.

Practice this question →

8

Multi-Selecthard

A company is deploying a global web application using an external HTTPS load balancer with Cloud CDN. Which THREE steps are required for proper configuration? (Choose three.)

Select 3 answers

A.Enable Cloud CDN on the backend bucket

B.Enable Identity-Aware Proxy (IAP)

C.Use an external TCP load balancer

D.Configure a health check for the backend services

E.Use Premium Tier networking

AnswersA, D, E

Cloud CDN must be enabled on the backend bucket to cache content.

Why this answer

A is correct because Cloud CDN must be explicitly enabled on the backend bucket (or backend service) to cache content at Google's edge points of presence. Without this step, the load balancer will forward requests directly to the origin without leveraging CDN caching, defeating the purpose of a global web application.

Exam trap

Google Cloud often tests the distinction between HTTP(S) and TCP load balancers, and candidates mistakenly think a TCP load balancer can serve HTTPS traffic or work with Cloud CDN, but Cloud CDN only works with HTTP(S) load balancers.

Practice this question →

9

MCQeasy

A developer has a Kubernetes Deployment manifest in a file named 'api-deployment.yaml'. Which command creates the Deployment if it doesn't exist, or updates it if it does?

A.kubectl create -f api-deployment.yaml

B.kubectl run api-deployment.yaml

C.kubectl apply -f api-deployment.yaml

D.kubectl deploy -f api-deployment.yaml

AnswerC

`kubectl apply -f` reads the manifest and creates or updates the resource declaratively — the standard command for deploying from YAML files.

Why this answer

Option C is correct because `kubectl apply -f api-deployment.yaml` uses a declarative approach: it creates the Deployment if it does not exist, or performs a rolling update if it already exists, by applying the desired state defined in the YAML manifest. This command leverages the Kubernetes API's server-side apply logic, merging changes without requiring the resource to be deleted first.

Exam trap

Google Cloud often tests the distinction between `create` (imperative, fails on existing resources) and `apply` (declarative, idempotent), trapping candidates who think `create` can also update or who confuse `run` with `apply`.

How to eliminate wrong answers

Option A is wrong because `kubectl create -f api-deployment.yaml` will fail with an error if the Deployment already exists, as it only creates new resources and does not support updates. Option B is wrong because `kubectl run api-deployment.yaml` is not a valid command; `kubectl run` is used to create a Pod or Deployment from an image, not from a YAML file. Option D is wrong because `kubectl deploy -f api-deployment.yaml` is not a valid kubectl subcommand; the correct verb for updating existing resources is `apply`, not `deploy`.

Practice this question →

10

MCQeasy

You run `kubectl get pods` and see a pod in `ImagePullBackOff` state. What are the two most common causes of this error?

A.Incorrect image name/tag, or missing pull credentials for a private registry.

B.Insufficient CPU/memory on the node, or the pod's resource requests are too high.

C.The pod's liveness probe is failing, causing the container to restart.

D.The container's entrypoint command is failing, causing the image pull to abort.

AnswerA

These are the two root causes: wrong image reference (404 from registry) or authentication failure (403 from registry). Both result in ImagePullBackOff.

Why this answer

The `ImagePullBackOff` state indicates that the kubelet is unable to pull the container image from the registry. The two most common causes are an incorrect image name or tag (e.g., a typo or a non-existent tag), which results in a `404 Not Found` from the registry, and missing or invalid pull credentials for a private registry, which results in a `401 Unauthorized` or `403 Forbidden` response. Both prevent the image from being downloaded, causing the pod to enter a backoff loop.

Exam trap

Google Cloud often tests the distinction between `ImagePullBackOff` (image retrieval failure) and `CrashLoopBackOff` (container runtime failure) — candidates confuse the two because both involve backoff logic, but the root cause and timing differ.

How to eliminate wrong answers

Option B is wrong because insufficient CPU/memory on the node or high resource requests cause `Pending` or `OutOfcpu`/`OutOfmemory` states, not `ImagePullBackOff`; the image pull itself is not affected by resource constraints. Option C is wrong because a failing liveness probe causes container restarts (CrashLoopBackOff) or pod termination, but does not affect the image pull process; `ImagePullBackOff` occurs before the container even starts. Option D is wrong because a failing entrypoint command causes the container to exit immediately after starting (CrashLoopBackOff), not an image pull failure; the image pull completes successfully before the entrypoint runs.

Practice this question →

11

MCQmedium

Your Cloud Build pipeline needs to reference environment-specific configuration: `PROJECT_ID`, `REGION`, and `IMAGE_TAG` (generated from the Git commit SHA). Where should you define these values in `cloudbuild.yaml`?

A.Hardcode the values directly in each build step's `args` field.

B.Use built-in substitutions (`$PROJECT_ID`, `$COMMIT_SHA`) and define custom substitutions (`$_REGION`) in the trigger or `--substitutions` flag.

C.Store all values in Cloud Secret Manager and retrieve them in each build step.

D.Use a `.env` file committed to the repository and source it in build steps.

AnswerB

$PROJECT_ID and $COMMIT_SHA are Cloud Build built-in substitutions. Custom values like REGION use the $_VAR pattern defined in trigger configuration, enabling environment-specific pipelines from a single cloudbuild.yaml.

Why this answer

Option B is correct because Cloud Build provides built-in substitutions like `$PROJECT_ID` and `$COMMIT_SHA` that automatically resolve to the current project ID and the Git commit SHA, respectively. Custom substitutions like `$_REGION` can be defined in the trigger configuration or passed via the `--substitutions` flag, allowing environment-specific values to be injected without hardcoding. This approach keeps the `cloudbuild.yaml` reusable across environments and avoids exposing sensitive or variable data in the build file.

Exam trap

Google Cloud often tests the distinction between built-in and custom substitutions, and the trap here is that candidates assume all environment-specific values must be hardcoded or stored in secrets, overlooking Cloud Build's native substitution mechanism for non-sensitive configuration.

How to eliminate wrong answers

Option A is wrong because hardcoding values in `args` makes the pipeline environment-specific, requiring manual edits for each environment and violating the principle of configuration externalization. Option C is wrong because Cloud Secret Manager is designed for sensitive data (e.g., API keys, passwords), not for non-sensitive environment variables like `PROJECT_ID`, `REGION`, or `IMAGE_TAG`; retrieving secrets in every build step adds unnecessary latency and complexity. Option D is wrong because a `.env` file committed to the repository exposes environment-specific values in version control, creating security risks and maintenance overhead, and Cloud Build does not natively source `.env` files without custom scripting.

Practice this question →

12

MCQhard

A company runs a big data processing pipeline on a Dataproc cluster. To reduce costs, they use a primary cluster with one master node (standard) and 20 worker nodes all using preemptible VMs. Recently, jobs running during peak business hours are failing with 'Task failed' errors. You notice that many preemptible VMs are reclaimed during the middle of these jobs. The jobs are long-running MapReduce tasks that write intermediate results to the cluster's HDFS. What should you do to improve job reliability without significantly increasing costs?

A.Enable graceful decommissioning for the preemptible instances.

B.Increase the number of preemptible worker nodes to 40.

C.Use a higher preemptible instance type (e.g., n1-highmem-2 instead of n1-standard-2).

D.Switch to standard worker nodes with committed use discounts.

AnswerA

Allows Dataproc to handle preemptions gracefully by moving tasks before shutdown.

Why this answer

Option A is correct because enabling graceful decommissioning for preemptible instances allows YARN to handle node loss more gracefully. When a preemptible VM is reclaimed, YARN can wait for running containers to finish before shutting down the node, reducing task failures. This improves job reliability without adding cost, as it leverages existing preemptible VMs more effectively.

Exam trap

Google Cloud often tests the misconception that simply adding more preemptible nodes or upgrading instance types will solve reliability issues, when the real solution is to configure graceful decommissioning to handle preemption gracefully.

How to eliminate wrong answers

Option B is wrong because simply increasing the number of preemptible worker nodes to 40 does not address the root cause of task failures due to VM reclamation; it only spreads the risk but still results in lost intermediate data and failed tasks. Option C is wrong because using a higher preemptible instance type (e.g., n1-highmem-2) does not prevent preemption; it only provides more memory, which does not solve the reliability issue of task failures during reclamation. Option D is wrong because switching to standard worker nodes with committed use discounts would significantly increase costs, contradicting the requirement to not significantly increase costs.

Practice this question →

13

MCQmedium

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?

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

B.kubectl port-forward svc/postgres-service 5432:5432

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

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

AnswerB

`kubectl port-forward` tunnels traffic from localhost:5432 to the cluster service's port 5432 — accessible only from the developer's machine, with no network changes.

Why this answer

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.

Exam trap

Google Cloud often tests the distinction between exposing a service externally (LoadBalancer) and creating a local tunnel (port-forward), and candidates may mistakenly choose a LoadBalancer option thinking it is required for connectivity, ignoring the 'without exposing externally' constraint.

How to eliminate wrong answers

Option A is wrong because `kubectl expose pod postgres-pod --type=LoadBalancer` creates an external LoadBalancer service, which exposes the database to the internet, contradicting the requirement to avoid external exposure. Option C is wrong because `kubectl tunnel` is not a valid kubectl command; the correct command for port forwarding is `kubectl port-forward`. Option D is wrong because `gcloud container ssh` is used to SSH into a GKE node, not to forward ports, and the syntax `--port-forward=5432:5432` is invalid; port forwarding is done via `kubectl port-forward`.

Practice this question →

14

Matchingmedium

Match each Compute Engine machine family to its typical workload.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Cost-optimized, general-purpose workloads

Balanced performance for general workloads

Compute-optimized for high-performance computing

Memory-optimized for large in-memory databases

GPU-accelerated for graphics and ML

Why these pairings

Machine families are optimized for different resource needs.

Practice this question →

15

MCQmedium

You need to deploy a containerized application to GKE that stores user session data. The application has 3 replicas. Session data must not be lost if a replica is restarted. All replicas share the same session store. Which architecture handles this correctly?

A.Store sessions in each pod's memory; use session affinity on the load balancer to route users to the same pod.

B.Store sessions in Cloud Memorystore (Redis) shared by all replicas.

C.Use an emptyDir volume shared between replicas for session storage.

D.Store sessions in a Cloud SQL table with a connection pool per replica.

AnswerB

Redis is a fast, shared, durable session store. All replicas read/write to the same Redis instance. Pod restarts don't lose sessions since data lives outside the pod.

Why this answer

Option B is correct because Cloud Memorystore (Redis) provides a centralized, persistent, and highly available session store that all replicas can access. This ensures session data survives pod restarts and is shared across all replicas, meeting the requirement for no data loss and shared access.

Exam trap

Google Cloud often tests the misconception that session affinity alone ensures session persistence, but the trap here is that session affinity only routes traffic to the same pod, not that the pod's memory survives restarts, so candidates must recognize that shared external storage is required for data durability.

How to eliminate wrong answers

Option A is wrong because storing sessions in each pod's memory means data is lost if a pod restarts, and session affinity only routes users to the same pod but does not prevent data loss on restart. Option C is wrong because an emptyDir volume is ephemeral and tied to a pod's lifecycle; it is deleted when the pod is deleted or restarted, and it cannot be shared across replicas in different pods. Option D is wrong because while Cloud SQL can persist data, using a connection pool per replica does not address session storage efficiently; sessions are transient and high-frequency, making a relational database like Cloud SQL less suitable than an in-memory store like Redis for performance and cost.

Practice this question →

16

MCQeasy

A deployment pipeline runs `kubectl logs` to capture output from a crashed Pod's previous container instance. Which flag retrieves logs from the previous (terminated) container instance rather than the current one?

A.kubectl logs api-pod --terminated

B.kubectl logs api-pod --previous

C.kubectl logs api-pod --all-containers --since-crash

D.kubectl describe pod api-pod | grep -A 50 'Last State'

AnswerB

`--previous` (or `-p`) retrieves logs from the last terminated container instance — essential for debugging containers that crash on startup.

Why this answer

The `--previous` flag in `kubectl logs` retrieves logs from the previous (terminated) container instance of a Pod. This is essential for debugging crashes where the current container has restarted, as the logs from the failed instance are preserved and accessible only with this flag.

Exam trap

Google Cloud often tests the `--previous` flag as the only way to access logs from a terminated container, and candidates mistakenly choose `--terminated` or `--since-crash` because they sound plausible but do not exist in the kubectl command syntax.

How to eliminate wrong answers

Option A is wrong because `--terminated` is not a valid flag for `kubectl logs`; the correct flag is `--previous`. Option C is wrong because `--all-containers` streams logs from all containers in the Pod, and `--since-crash` is not a valid flag; there is no `--since-crash` option in kubectl. Option D is wrong because `kubectl describe pod` shows the 'Last State' field with exit details but does not retrieve the actual log output from the terminated container; it only provides metadata about the previous termination.

Practice this question →

17

MCQeasy

A team has a Docker container image locally and wants to push it to Google Artifact Registry. They've already authenticated Docker with GCP. The registry host is 'us-central1-docker.pkg.dev'. Which commands correctly tag and push the image?

A.docker tag myimage us-central1-docker.pkg.dev/myproject/myrepo/myimage:v1 && docker push us-central1-docker.pkg.dev/myproject/myrepo/myimage:v1

B.gcloud artifacts docker push myimage --location=us-central1 --repository=myrepo

C.docker push gcr.io/myproject/myimage:v1

D.gcloud container images push myimage:v1 --region=us-central1

AnswerA

This correctly tags the local image with the full Artifact Registry path and pushes it. The format is `[REGION]-docker.pkg.dev/[PROJECT]/[REPO]/[IMAGE]:[TAG]`.

Why this answer

Option A is correct because it uses the standard Docker CLI workflow: first tagging the local image with the full Artifact Registry path (including the registry host, project, repository, and image name with tag), then pushing it. Since the team has already authenticated Docker with GCP, the `docker push` command will authenticate via the Docker credential helper and upload the image to the specified Artifact Registry repository.

Exam trap

Google Cloud often tests the distinction between Google Container Registry (gcr.io) and Artifact Registry (LOCATION-docker.pkg.dev), and candidates mistakenly use gcr.io commands or syntax for Artifact Registry, or assume gcloud commands can replace standard Docker CLI commands for pushing images.

How to eliminate wrong answers

Option B is wrong because `gcloud artifacts docker push` is not a valid command; the correct gcloud command for pushing Docker images is `gcloud artifacts docker upload`, but even that requires a different syntax and does not use `--location` and `--repository` flags in the way shown. Option C is wrong because it pushes to `gcr.io` (Google Container Registry), not to Artifact Registry (`us-central1-docker.pkg.dev`), and the registry host must match the target Artifact Registry location. Option D is wrong because `gcloud container images push` is a command for Google Container Registry (gcr.io), not Artifact Registry, and the `--region` flag is not valid for that command.

Practice this question →

18

MCQeasy

Which command creates a Cloud Storage bucket named 'my-archive-bucket' in the US multi-region using the modern gcloud CLI?

A.gcloud storage mk gs://my-archive-bucket --location=US

B.gcloud storage buckets create gs://my-archive-bucket --location=US

C.gcloud cloud-storage create my-archive-bucket --region=US

D.gsutil mk -l US gs://my-archive-bucket

AnswerB

This is the correct modern syntax. `gcloud storage buckets create` followed by the `gs://` bucket URI and `--location` creates the bucket in the US multi-region.

Why this answer

Option B is correct because the modern gcloud CLI uses the `gcloud storage buckets create` command to create a Cloud Storage bucket, and the `--location=US` flag specifies the US multi-region. This command is part of the newer, unified `gcloud storage` command group that replaces the older `gsutil` tool for bucket management.

Exam trap

Google Cloud often tests the distinction between the modern `gcloud storage` command group and the legacy `gsutil` tool, and candidates may mistakenly choose a `gsutil` command or an invalid `gcloud` subcommand when the question explicitly requires the modern CLI.

How to eliminate wrong answers

Option A is wrong because `gcloud storage mk` is not a valid command; the correct subcommand is `gcloud storage buckets create`. Option C is wrong because `gcloud cloud-storage create` is not a valid gcloud command; the correct command group is `gcloud storage buckets`. Option D is wrong because `gsutil mk` is the older, legacy tool, and the question explicitly asks for the 'modern gcloud CLI'.

Practice this question →

19

MCQmedium

You deploy a Cloud Function (gen1) that calls an external API. During testing you find the function times out after 60 seconds even though you set `--timeout=540`. You also notice the function logs show execution completing in 45 seconds before the timeout. What is the most likely cause of the external timeout?

A.Cloud Functions gen1 has a hard maximum timeout of 60 seconds regardless of configuration.

B.The HTTP client library used in the function has a default 60-second socket/connection timeout.

C.Cloud VPC restricts outbound connections to 60 seconds.

D.The function's service account lacks permission to make outbound HTTP calls.

AnswerB

Many HTTP client libraries (requests, axios, etc.) have default timeouts shorter than the function timeout. The function timeout controls Cloud Functions' kill signal, not the client library's connection timeout.

Why this answer

Option B is correct because the external API call is timing out due to the HTTP client library's default socket/connection timeout, which is often set to 60 seconds. Even though the Cloud Function's overall timeout is configured to 540 seconds, the HTTP request itself has its own timeout that expires before the function completes. The function logs show execution finishing in 45 seconds, indicating the function code completes, but the external API call fails silently or the response is not received within the client's timeout window.

Exam trap

Google Cloud often tests the distinction between the Cloud Function's execution timeout and the HTTP client library's timeout, leading candidates to incorrectly blame the platform's timeout limit when the actual issue is application-level configuration.

How to eliminate wrong answers

Option A is wrong because Cloud Functions gen1 supports a configurable timeout up to 540 seconds (9 minutes), not a hard 60-second limit. Option C is wrong because Cloud VPC does not impose a 60-second timeout on outbound connections; VPC firewall rules and routes do not enforce such a low-level timeout. Option D is wrong because the function's service account lacking permissions to make outbound HTTP calls would result in an authorization error (e.g., 403 or 401), not a timeout after 60 seconds.

Practice this question →

20

MCQmedium

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?

A.Vertical Pod Autoscaler (VPA) with CPU target 60%

B.Horizontal Pod Autoscaler (HPA) targeting 60% CPU utilization

C.Cluster Autoscaler with a CPU threshold of 60%

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

AnswerB

HPA monitors CPU utilization and scales replicas up when average CPU exceeds 60% and down when it drops below — exactly the described behavior.

Why this answer

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.

Exam trap

Google Cloud often tests the distinction between scaling Pod replicas (HPA) versus scaling Pod resources (VPA) versus scaling cluster nodes (Cluster Autoscaler), and the trap here is confusing VPA's resource adjustment with HPA's replica adjustment, especially when the question mentions 'CPU utilization target'.

How to eliminate wrong answers

Option A is wrong because Vertical Pod Autoscaler (VPA) adjusts CPU and memory requests/limits of existing Pods, not the number of replicas; it cannot scale from 2 to 20 Pods based on load. Option C is wrong because Cluster Autoscaler adds or removes nodes from the cluster, not Pod replicas; it operates at the infrastructure level and does not target CPU utilization for Pod scaling. Option D is wrong because setting a fixed replica count of 20 wastes resources during low traffic, and resource quotas only limit total resource consumption, they do not dynamically scale Pods up or down based on CPU utilization.

Practice this question →

21

MCQhard

A team runs a Kubernetes Deployment with 3 replicas behind a Service. They want to expose it externally with HTTPS and route traffic based on URL paths (/api → backend service, / → frontend service). Which Kubernetes resource handles path-based routing at Layer 7?

A.A LoadBalancer Service with path routing rules

B.A Kubernetes Ingress resource with path rules

C.A NodePort Service with iptables path routing rules

D.Multiple ClusterIP Services with DNS SRV records for path routing

AnswerB

Ingress resources define HTTP routing rules including path-based routing. On GKE, the Ingress controller provisions a GCP Application Load Balancer with TLS and path rules.

Why this answer

A Kubernetes Ingress resource is the native API object designed for Layer 7 (HTTP/HTTPS) routing, including path-based routing. It allows you to define rules that map URL paths (e.g., /api, /) to different backend Services, and it typically works with an Ingress controller (e.g., NGINX, HAProxy) that terminates TLS and performs the routing. This directly meets the requirement for external HTTPS exposure and path-based traffic splitting.

Exam trap

Google Cloud often tests the misconception that a LoadBalancer Service can handle Layer 7 routing, but in Kubernetes, LoadBalancer Services are strictly Layer 4 and cannot inspect HTTP paths; candidates must remember that path-based routing requires an Ingress resource with a compatible controller.

How to eliminate wrong answers

Option A is wrong because a LoadBalancer Service operates at Layer 4 (TCP/UDP) and cannot perform path-based routing; it only distributes traffic to Pods based on IP and port, not URL paths. Option C is wrong because a NodePort Service also works at Layer 4 and relies on iptables for simple port forwarding, not for Layer 7 path inspection or routing. Option D is wrong because ClusterIP Services are internal-only and DNS SRV records provide service discovery at Layer 4, not path-based routing; they cannot route based on URL paths or terminate HTTPS.

Practice this question →

22

MCQmedium

A platform team needs a Kubernetes workload that runs exactly one Pod on every node in a GKE cluster — including nodes added in the future. The workload collects host-level metrics. Which Kubernetes resource type should they use?

A.Deployment with replicas set equal to the node count

B.StatefulSet with one replica per node

C.DaemonSet

D.CronJob running every minute to check and restore missing Pods

AnswerC

DaemonSets guarantee exactly one Pod per matching node, including new nodes added by the cluster autoscaler — purpose-built for node-level workloads like metric collectors.

Why this answer

A DaemonSet ensures that exactly one Pod runs on every node in the cluster, including nodes added after creation. This is the correct resource for host-level metrics collection because it automatically scales with the node pool and guarantees one Pod per node without manual intervention.

Exam trap

Google Cloud often tests the misconception that a Deployment with a fixed replica count can achieve per-node coverage, but candidates fail to realize that DaemonSets are the only resource that automatically scales with the node pool and guarantees one Pod per node without manual replica management.

How to eliminate wrong answers

Option A is wrong because a Deployment with replicas set equal to the node count does not automatically adjust when nodes are added or removed; it requires manual updates to the replica count and does not guarantee one Pod per node. Option B is wrong because a StatefulSet is designed for stateful applications requiring stable network identities and persistent storage, not for running one Pod per node; it does not have a built-in mechanism to schedule one Pod per node. Option D is wrong because a CronJob running every minute to check and restore missing Pods is an inefficient, reactive workaround that introduces unnecessary complexity and latency, and it does not provide the declarative, self-healing guarantee of a DaemonSet.

Practice this question →

23

MCQmedium

A team packages their Kubernetes application as a Helm chart. They need to install it into a GKE cluster with the release name 'webapp' in the 'production' namespace, overriding the default image tag to 'v2.1'. Which Helm command achieves this?

A.helm deploy webapp ./chart -n production --set image.tag=v2.1

B.helm install webapp ./chart -n production --set image.tag=v2.1

C.kubectl apply -f helm-chart.yaml -n production --image-tag=v2.1

D.helm apply webapp -n production --chart=./chart --tag=v2.1

AnswerB

`helm install [RELEASE] [CHART]` installs a chart with the given release name. `-n production` targets the namespace. `--set image.tag=v2.1` overrides the chart's default value.

Why this answer

Option B is correct because `helm install` is the standard Helm command to deploy a chart into a cluster, and the `--set` flag overrides default values like `image.tag`. The `-n` flag specifies the namespace, and the release name 'webapp' is given as the first argument. This matches the Helm CLI syntax exactly.

Exam trap

The trap here is that candidates may confuse Helm commands with kubectl or assume a generic 'deploy' verb exists, when Helm strictly uses `install` for first-time deployments and `upgrade` for updates.

How to eliminate wrong answers

Option A is wrong because `helm deploy` is not a valid Helm command; Helm uses `install` or `upgrade`, not `deploy`. Option C is wrong because `kubectl apply` does not process Helm charts; it applies raw Kubernetes manifests, and `--image-tag` is not a valid kubectl flag. Option D is wrong because `helm apply` is not a valid Helm command, and the `--tag` flag is incorrect; Helm uses `--set image.tag=v2.1` to override values.

Practice this question →

24

MCQmedium

A Cloud Function must execute automatically every time a new object is written to a specific Cloud Storage bucket. Which trigger type should be configured for the function?

A.HTTP trigger

B.Pub/Sub trigger

C.Cloud Storage trigger (object finalized event)

D.Cloud Scheduler trigger

AnswerC

A Cloud Storage trigger on the `object.finalized` event fires the function immediately when a new object is created in the bucket — no intermediate service needed.

Why this answer

The Cloud Storage trigger (object finalized event) is the correct choice because Cloud Functions natively supports Cloud Storage events via the `google.storage.object.finalize` event type, which fires when a new object is created or an existing object is overwritten in a bucket. This trigger automatically invokes the function without requiring any intermediary service, directly binding the function to the bucket's notification system.

Exam trap

Google Cloud often tests the misconception that Pub/Sub is required for Cloud Storage events, but Cloud Functions directly supports Cloud Storage triggers without needing an explicit Pub/Sub topic, making Option B a common distractor.

How to eliminate wrong answers

Option A is wrong because an HTTP trigger requires an explicit HTTP request to invoke the function, not an automatic reaction to a Cloud Storage event. Option B is wrong because a Pub/Sub trigger would require manually publishing a message to a topic from Cloud Storage, adding unnecessary complexity and latency; Cloud Functions can directly listen to Cloud Storage events without Pub/Sub. Option D is wrong because Cloud Scheduler triggers are used for scheduled, time-based execution (e.g., cron jobs), not for event-driven reactions to object creation in a bucket.

Practice this question →

25

MCQhard

Refer to the exhibit. A Deployment is applied to a GKE cluster. The cluster has a single node pool with one node of machine type n1-standard-4 (4 vCPUs, 15 GB memory). After a few minutes, only two Pods are running, and one Pod is in Pending state. The node's resource usage shows 70% CPU allocated and 85% memory allocated. What is the most likely cause of the Pending Pod?

A.The node has insufficient CPU because each Pod requests 1 vCPU.

B.The node has not enough IP addresses available.

C.The Pods are pending due to a failed image pull.

D.The node has insufficient memory because each Pod requests 6 GiB.

AnswerD

Two Pods consume 12 GiB, leaving 3 GiB, insufficient for the third Pod's 6 GiB request.

Why this answer

The node has 15 GB memory. Two Pods each request 6 GiB, consuming 12 GiB. Only 3 GiB remains, which is less than the 6 GiB needed for the third Pod.

CPU: two Pods request 1 vCPU each (2 vCPU total), leaving 2 vCPU for the third, which is sufficient. Therefore, insufficient memory is the cause.

Practice this question →

26

MCQmedium

A distributed database running on GKE requires stable, persistent hostnames (pod-0, pod-1, pod-2) and ordered startup/shutdown for proper cluster initialization. Pods must retain their identity across restarts. Which Kubernetes resource is designed for this?

A.Deployment with pod affinity rules

B.StatefulSet with a headless Service

C.DaemonSet with a unique hostname label on each node

D.ReplicaSet with a fixed replica count

AnswerB

StatefulSets provide stable Pod names (pod-0, pod-1...), stable DNS via headless Services, ordered deployment, and PVC retention across restarts — the standard choice for stateful clustered applications.

Why this answer

StatefulSet is the correct resource because it provides stable, unique network identifiers (e.g., pod-0, pod-1, pod-2) via a headless Service, ordered startup and shutdown (pod-0 starts first, pod-2 terminates first), and persistent pod identity that survives restarts. These features are essential for distributed databases like Cassandra or ZooKeeper that require consistent hostnames and initialization order.

Exam trap

Google Cloud often tests the misconception that a Deployment with a fixed number of replicas can provide stable identities, but Deployments treat pods as interchangeable and do not preserve hostnames or startup order, making StatefulSet the only correct choice for stateful workloads requiring persistent identity.

How to eliminate wrong answers

Option A is wrong because a Deployment with pod affinity rules does not guarantee stable hostnames or ordered startup/shutdown; pods get random names and can be created or terminated in any order, which breaks cluster initialization for stateful applications. Option C is wrong because a DaemonSet runs exactly one pod per node and uses node hostnames, not stable pod hostnames like pod-0, and it does not provide ordered startup/shutdown or persistent pod identity across restarts. Option D is wrong because a ReplicaSet with a fixed replica count does not assign stable, predictable hostnames or enforce ordered startup/shutdown; pods are ephemeral and can be replaced with different names, losing identity.

Practice this question →

27

Multi-Selectmedium

A team is deploying a stateful application on GKE that requires each pod to have its own persistent disk. Which TWO Kubernetes resources are essential for this deployment? (Choose two.)

Select 2 answers

A.Deployment

B.ConfigMap

C.StatefulSet

D.Ingress

E.PersistentVolumeClaim (PVC)

AnswersC, E

StatefulSet provides stable identities and storage for stateful applications.

Why this answer

A StatefulSet is essential because it provides stable, unique network identifiers and ordered, graceful deployment and scaling for stateful applications, ensuring each pod maintains its identity and persistent storage binding across rescheduling. A PersistentVolumeClaim (PVC) is required to request and bind a persistent disk to each pod, enabling the pod to retain its data independently of other pods in the set.

Exam trap

Google Cloud often tests the misconception that a Deployment can handle stateful workloads with persistent storage, but the trap is that a Deployment does not guarantee stable pod identities or ordered PVC binding, causing data loss or identity conflicts when pods are rescheduled.

Practice this question →

28

MCQhard

You are deploying a Cloud Run service revision that should initially receive 0% of traffic (for testing via a direct URL), while the existing revision continues to serve 100% of production traffic. Which `gcloud run deploy` flag achieves this?

A.`--no-traffic`

B.`--traffic=0`

C.`--revision-suffix=canary` with no traffic configuration

D.`--min-instances=0 --max-instances=0`

AnswerA

--no-traffic deploys the new revision without diverting any production traffic to it. The revision is accessible via its unique revision URL for testing without affecting live users.

Why this answer

The `--no-traffic` flag on `gcloud run deploy` deploys a new revision but directs 0% of traffic to it, leaving the existing revision serving 100% of production traffic. This allows you to test the new revision via its direct URL without impacting live users. It is the correct and explicit way to achieve a zero-traffic deployment in Cloud Run.

Exam trap

The trap here is that candidates confuse traffic routing with instance scaling, assuming `--min-instances=0` or a bare `--traffic=0` would prevent traffic, when in fact Cloud Run requires explicit traffic management via `--no-traffic` or the `--traffic` flag with a revision identifier.

How to eliminate wrong answers

Option B is wrong because `--traffic=0` is not a valid flag; `gcloud run deploy` uses `--no-traffic` or `--traffic` with a revision name and percentage (e.g., `--traffic=new-revision=0`) but not a bare `=0`. Option C is wrong because `--revision-suffix=canary` only names the revision; without a traffic flag, the new revision automatically receives 100% of traffic by default, defeating the requirement. Option D is wrong because `--min-instances=0 --max-instances=0` controls instance scaling (allowing zero idle instances) but does not affect traffic routing; the new revision would still receive traffic unless explicitly prevented.

Practice this question →

29

MCQmedium

A GKE Deployment runs a web application with 6 replicas across a 3-node cluster. To ensure no two replicas land on the same node (maximizing availability), which Pod spec configuration should be applied?

A.Set podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and topologyKey: kubernetes.io/hostname

B.Set podAffinity with requiredDuringSchedulingIgnoredDuringExecution and topologyKey: kubernetes.io/hostname

C.Set topologySpreadConstraints with maxSkew: 1 and topologyKey: kubernetes.io/hostname

D.Set nodeSelector to a specific node for each replica

AnswerA

This hard anti-affinity rule prevents the scheduler from placing a Pod on a node that already runs a Pod matching the selector — guaranteeing one replica per node.

Why this answer

Option A is correct because `podAntiAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` and `topologyKey: kubernetes.io/hostname` forces the scheduler to place each replica on a different node. This ensures that no two pods of the same Deployment run on the same Kubernetes node, maximizing availability by preventing a single node failure from taking down more than one replica.

Exam trap

Google Cloud often tests the distinction between `podAffinity` and `podAntiAffinity` — the trap here is that candidates confuse the two, or assume `topologySpreadConstraints` provides the same hard guarantee as anti-affinity, when it only enforces even distribution, not strict separation.

How to eliminate wrong answers

Option B is wrong because `podAffinity` attracts pods to the same node, which would cause replicas to co-locate, reducing availability. Option C is wrong because `topologySpreadConstraints` with `maxSkew: 1` distributes pods evenly across nodes but does not guarantee that no two replicas land on the same node; it only ensures a balanced distribution, which could still allow multiple replicas on one node if the cluster has fewer nodes than replicas. Option D is wrong because setting `nodeSelector` to a specific node for each replica is not dynamic and would require manual management; it also cannot guarantee anti-affinity across all replicas without complex scripting, and it violates the declarative nature of Kubernetes scheduling.

Practice this question →

30

MCQhard

An organization is deploying a stateful application on Google Kubernetes Engine (GKE). The application requires persistent storage with high read/write performance and must be available across multiple zones for disaster recovery. Which storage solution should they use?

A.Cloud Filestore

B.Regional persistent disk

C.Local SSD

D.Zonal persistent disk

AnswerB

Regional persistent disk replicates across zones, providing high performance and DR.

Why this answer

Regional persistent disks provide synchronous replication across two zones in the same region, ensuring data availability during a zonal failure. They offer high read/write performance suitable for stateful applications and can be attached to GKE pods via PersistentVolumeClaims, meeting the requirement for multi-zone disaster recovery.

Exam trap

Google Cloud often tests the distinction between zonal and regional persistent disks, where candidates mistakenly choose zonal disks for high performance without considering the multi-zone disaster recovery requirement, or they confuse Cloud Filestore's shared file access with the block storage performance needed for stateful applications.

How to eliminate wrong answers

Option A is wrong because Cloud Filestore is a managed NFS file server designed for shared file storage, not block storage, and its performance is lower than persistent disks for high-throughput workloads; it also introduces network latency. Option C is wrong because Local SSDs are ephemeral and tied to a single node, so data is lost if the node or pod is rescheduled, making them unsuitable for stateful applications requiring persistence across zones. Option D is wrong because Zonal persistent disks are confined to a single zone and cannot survive a zonal outage, failing the disaster recovery requirement for multi-zone availability.

Practice this question →

31

MCQeasy

A data analytics team needs to run a Spark job on a schedule. They want to minimize operational overhead and only pay for resources used during job execution. Which service should they use?

A.Create a Dataproc cluster and keep it running for ad-hoc jobs

B.Use Dataproc workflow templates with scheduled execution

C.Provision Compute Engine instances with Spark installed and start/stop them manually

D.Use BigQuery for all analytics

AnswerB

Workflow templates create ephemeral clusters that are deleted after job completion.

Why this answer

Option B is correct because Dataproc workflow templates allow you to define a Spark job as a workflow and schedule its execution using Cloud Scheduler or a cron-like mechanism. This minimizes operational overhead by automatically provisioning a cluster, running the job, and tearing down the cluster when finished, ensuring you only pay for resources used during execution.

Exam trap

Google Cloud often tests the distinction between persistent clusters (always-on) and ephemeral clusters (created on-demand), and the trap here is that candidates may assume any Dataproc usage is cost-effective, overlooking that only workflow templates with scheduled execution enforce automatic teardown.

How to eliminate wrong answers

Option A is wrong because keeping a Dataproc cluster running 24/7 incurs continuous compute costs, even when no jobs are running, which contradicts the requirement to pay only for resources used during job execution. Option C is wrong because manually provisioning and stopping Compute Engine instances with Spark installed introduces significant operational overhead and does not provide automated scheduling or lifecycle management. Option D is wrong because BigQuery is a serverless data warehouse for SQL-based analytics, not a Spark execution environment, and cannot run Spark jobs directly.

Practice this question →

32

MCQeasy

You have an Artifact Registry repository for Python packages (`format: python`). A developer needs to publish a new Python package to this repository. Which tool and configuration allows them to publish?

A.Use `pip install` pointing to the Artifact Registry URL to upload the package.

B.Use `twine upload` with the Artifact Registry Python repository URL as the repository target.

C.Use `docker push` to push the Python package as a container layer.

D.Use `gsutil cp` to copy the wheel file to the Artifact Registry bucket.

AnswerB

Twine is the standard Python packaging upload tool. Configured with the Artifact Registry Python repository URL and authenticated via Google Cloud credentials, twine uploads packages directly.

Why this answer

B is correct because `twine` is the standard tool for uploading Python packages to package indices, and Artifact Registry's Python repositories are compatible with the PyPI API. By specifying the Artifact Registry repository URL as the `--repository-url` target in `twine upload`, the developer can authenticate via a service account or OAuth token and publish the package directly.

Exam trap

Google Cloud often tests the distinction between tools for different artifact types (pip vs. twine, docker push vs. gsutil), and the trap here is that candidates may confuse `pip install` (download) with `twine upload` (publish) because both are Python-related commands.

How to eliminate wrong answers

Option A is wrong because `pip install` is used to download and install packages, not to upload or publish them; it has no capability to push artifacts to a repository. Option C is wrong because `docker push` is used to upload container images to a container registry, not Python wheel or source distribution files to a package repository. Option D is wrong because Artifact Registry for Python packages does not expose a GCS bucket interface; `gsutil cp` works only with Cloud Storage buckets, not with the PyPI-compatible API endpoints that Artifact Registry uses.

Practice this question →

33

MCQeasy

A developer wants to deploy a containerized web application that can scale to zero when not in use, and only pay for request processing time. Which compute service should they choose?

A.App Engine Flexible Environment

B.Cloud Functions

C.Cloud Run

D.Google Kubernetes Engine (GKE)

AnswerC

Cloud Run runs containers and scales to zero when idle.

Why this answer

Cloud Run is the correct choice because it is a managed compute platform that runs containerized applications in a serverless environment, automatically scaling to zero when there are no requests and charging only for the resources used during request processing (billed in 100-millisecond increments). This matches the requirement for a containerized web app that scales to zero and has pay-per-use pricing.

Exam trap

Google Cloud often tests the distinction between serverless compute options: candidates confuse Cloud Functions (for event-driven code) with Cloud Run (for containerized apps), or assume App Engine Flexible can scale to zero when it cannot.

How to eliminate wrong answers

Option A is wrong because App Engine Flexible Environment runs containers but does not scale to zero; it requires at least one instance to be running at all times, leading to continuous costs. Option B is wrong because Cloud Functions is serverless and scales to zero, but it is designed for event-driven functions, not containerized applications; it does not support arbitrary container images. Option D is wrong because Google Kubernetes Engine (GKE) is a Kubernetes orchestration service that can scale down, but it does not scale to zero by default (requires at least one node) and incurs costs for the underlying node pool even when idle.

Practice this question →

34

MCQmedium

A team's Cloud Build pipeline must: (1) run unit tests, (2) build a Docker image only if tests pass, (3) push the image to Artifact Registry. Which cloudbuild.yaml structure correctly enforces this sequential dependency?

A.Define all three steps in a single `steps` list — they run sequentially by default and stop on failure

B.Use `waitFor` with step IDs to create a dependency graph between all three steps

C.Define the steps in three separate cloudbuild.yaml files and chain them with Cloud Composer

D.Set `parallel: false` at the top level of cloudbuild.yaml to enforce sequential execution

AnswerA

Cloud Build steps execute sequentially by default. If any step fails (non-zero exit), the build stops and subsequent steps don't run — enforcing the test-before-build-before-push dependency.

Why this answer

Option A is correct because Cloud Build executes steps in a `steps` list sequentially by default, and any step that exits with a non-zero status (e.g., test failure) immediately stops the entire pipeline. This enforces the required dependency: unit tests must pass before the Docker image is built, and the image must be built before it is pushed to Artifact Registry.

Exam trap

Google Cloud often tests the misconception that you must explicitly use `waitFor` to enforce step dependencies, when in fact Cloud Build runs steps in a list sequentially by default and stops on failure.

How to eliminate wrong answers

Option B is wrong because using `waitFor` with step IDs is unnecessary; Cloud Build already runs steps in a list sequentially by default, and adding explicit `waitFor` only adds redundant configuration without changing behavior. Option C is wrong because Cloud Composer is a workflow orchestration service for Apache Airflow, not designed for chaining Cloud Build pipelines; it would add unnecessary complexity and cost for a simple sequential dependency. Option D is wrong because there is no `parallel: false` top-level field in cloudbuild.yaml; Cloud Build controls parallelism via `waitFor` and step ordering, not a global flag.

Practice this question →

35

Drag & Dropmedium

Order the steps to attach a persistent disk to a running Compute Engine instance and format/mount it.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Disk must exist and be attached before formatting and mounting.

Practice this question →

36

MCQmedium

A team wants to configure a Cloud Scheduler job to invoke a Cloud Run service endpoint every hour using HTTP POST. The Cloud Run service requires authentication. How should the Scheduler job be configured to authenticate?

A.Include a Bearer token in the Authorization header of the scheduled HTTP request

B.Configure the Cloud Scheduler job with OIDC authentication using a service account that has Cloud Run Invoker permission

C.Make the Cloud Run service publicly accessible and use Cloud Armor to restrict access to Cloud Scheduler IPs

D.Configure an API key for the Cloud Run service and include it in the scheduled request URL

AnswerB

Cloud Scheduler supports OIDC token authentication — it generates a short-lived token for the configured service account and sends it with each request. The service account needs Cloud Run Invoker on the target service.

Why this answer

Cloud Scheduler can authenticate to Cloud Run using OIDC (OpenID Connect) by attaching a service account to the job. The scheduler obtains an OIDC token for that service account and includes it as a Bearer token in the Authorization header. The service account must have the `run.invoker` IAM role on the Cloud Run service to authorize the invocation.

Exam trap

Google Cloud often tests the distinction between OIDC and OAuth 2.0 in Cloud Scheduler, and the trap here is that candidates mistakenly think a static Bearer token or an API key can be used for Cloud Run authentication, when in fact only OIDC (or OAuth 2.0 for Google APIs) is supported for service-to-service invocation.

How to eliminate wrong answers

Option A is wrong because a static Bearer token (e.g., a long-lived personal access token) is not a supported authentication method for Cloud Scheduler; Cloud Scheduler uses OIDC or OAuth 2.0 access tokens, not arbitrary tokens. Option C is wrong because making the Cloud Run service publicly accessible defeats the purpose of requiring authentication, and Cloud Armor cannot restrict access based on Cloud Scheduler IPs since Cloud Scheduler uses a dynamic IP range that is not reliably scoped. Option D is wrong because Cloud Run does not support API key authentication; API keys are used for Google Cloud APIs (e.g., Maps), not for invoking Cloud Run services.

Practice this question →

37

MCQmedium

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?

A.Set replicas: 10 in the Job spec

B.Set parallelism: 10 and completions: 10 in the Job spec

C.Create 10 separate Job objects — one per worker

D.Set concurrency: 10 in the Job spec

AnswerB

`parallelism: 10` runs up to 10 Pods simultaneously. `completions: 10` requires 10 successful completions total. Together they create a parallel batch Job.

Why this answer

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.

Exam trap

Google Cloud often tests the distinction between Deployment fields (like `replicas`) and Job-specific fields (like `parallelism` and `completions`), trapping candidates who confuse the two or assume `replicas` applies to Jobs.

How to eliminate wrong answers

Option A is wrong because `replicas` is not a valid field in a Kubernetes Job spec; it is used in Deployments and StatefulSets to maintain a desired number of Pods, not to control parallel execution or completion count. Option C is wrong because creating 10 separate Job objects would result in 10 independent Jobs, each with its own lifecycle and status, rather than a single Job that tracks overall completion; this approach lacks coordination and does not guarantee that the batch is considered complete only when all workers finish. Option D is wrong because `concurrency` is not a valid field in a Kubernetes Job spec; it is a concept used in other systems (e.g., database connection pools) but not in the Job API, where parallelism controls concurrent Pod execution.

Practice this question →

38

Multi-Selectmedium

Which TWO actions should a Cloud Engineer take to deploy a containerized application on Cloud Run with a custom domain and SSL certificate automatically provisioned? (Choose two.)

Select 2 answers

A.Enable automatic SSL certificate provisioning

B.Create a self-managed SSL certificate in Cloud Load Balancing

C.Configure Serverless VPC Access to handle DNS

D.Create an external HTTPS load balancer in front of Cloud Run

E.Map a custom domain to the Cloud Run service in the Cloud Run console

AnswersA, E

Cloud Run automatically manages SSL when you map a domain; but you must ensure the 'automatic' option is enabled (it is by default).

Why this answer

Option A is correct because Cloud Run's managed SSL feature automatically provisions and renews a Google-managed SSL certificate for the custom domain when you map it to the service. This eliminates the need for manual certificate management and is the simplest way to achieve HTTPS with a custom domain.

Exam trap

Google Cloud often tests the misconception that you need a load balancer or self-managed certificate for custom domains on serverless services, but Cloud Run's built-in domain mapping and managed SSL eliminate those requirements.

Practice this question →

39

MCQeasy

A development team stores Docker images in Artifact Registry. A new team member needs to pull images to their local machine using Docker. Which command authenticates Docker to pull from a specific Artifact Registry repository in us-central1?

A.docker login us-central1-docker.pkg.dev --username=_json_key --password-stdin < key.json

B.gcloud auth configure-docker us-central1-docker.pkg.dev

C.kubectl create secret docker-registry artifactregistry --server=us-central1-docker.pkg.dev

D.gcloud artifacts docker auth --region=us-central1

AnswerB

This command configures Docker's credential helper to use gcloud credentials for the specified Artifact Registry endpoint — no key file needed if the user is authenticated with `gcloud auth login`.

Why this answer

Option B is correct because `gcloud auth configure-docker` is the official Google Cloud command that configures Docker to authenticate to Artifact Registry. When you specify the registry location (e.g., `us-central1-docker.pkg.dev`), it updates Docker's configuration file with the appropriate credential helper, enabling Docker to automatically obtain and refresh short-lived access tokens for pulling images from that specific repository.

Exam trap

The trap here is that candidates confuse `gcloud artifacts` (which manages artifact metadata) with `gcloud auth configure-docker` (which sets up Docker authentication), or they mistakenly think a static JSON key file with `docker login` is the correct approach for Artifact Registry.

How to eliminate wrong answers

Option A is wrong because `docker login` with a JSON key file is used for Docker Hub or self-managed registries, not for Artifact Registry; Artifact Registry requires a credential helper (gcloud) to handle token-based authentication, and using a static key file bypasses the short-lived token mechanism and is not the supported method. Option C is wrong because `kubectl create secret docker-registry` creates a Kubernetes secret for pulling images in a cluster, not for authenticating Docker on a local machine; it is a cluster-side operation, not a client-side authentication command. Option D is wrong because `gcloud artifacts docker auth` is not a valid command; the correct gcloud command for Docker authentication is `gcloud auth configure-docker`, and `gcloud artifacts` subcommands are for managing artifacts, not configuring Docker authentication.

Practice this question →

40

MCQhard

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?

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

B.Configure the Cloud Run service with `--add-cloudsql-instances` to connect via the built-in Auth Proxy

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

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

AnswerB

Cloud Run natively integrates with Cloud SQL via the `--add-cloudsql-instances` flag. This configures a Unix socket via Cloud SQL Auth Proxy, providing secure, authenticated connectivity without public IPs.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse Serverless VPC Access connectors with the Cloud SQL Auth Proxy, thinking that VPC connectivity alone is sufficient to reach a private Cloud SQL instance, but they miss that the proxy is required for authentication and encrypted tunneling even within the same VPC.

How to eliminate wrong answers

Option A is wrong because Cloud Run services can reach public IPs, but the Cloud SQL instance is explicitly not publicly accessible, so using a public IP with SSL would fail due to no public endpoint being available. Option C is wrong because deploying a separate Cloud SQL Auth Proxy container as a sidecar is unnecessary and redundant; the built-in proxy via `--add-cloudsql-instances` already handles this automatically without manual sidecar configuration. Option D is wrong because a Serverless VPC Access connector enables Cloud Run to reach resources in a VPC, but it does not provide the authentication and encryption that the Cloud SQL Auth Proxy offers; the connector alone cannot connect to Cloud SQL without additional proxy or private IP configuration.

Practice this question →

41

MCQmedium

A Cloud Function (gen2) is triggered by Pub/Sub messages. The function processes each message by calling three external APIs sequentially. The total processing time is 25 seconds per message. The Pub/Sub subscription's ack deadline is 10 seconds. What will happen, and how should you fix it?

A.Pub/Sub will wait indefinitely for the function to acknowledge; no issue occurs.

B.Messages will be redelivered before processing completes; extend the Pub/Sub subscription ack deadline to exceed 25 seconds.

C.The Cloud Function will automatically extend its own ack deadline via the Pub/Sub client library.

D.Increase the Cloud Function's memory to process faster and complete within 10 seconds.

AnswerB

The ack deadline must be longer than the function processing time. Extending it to 30–60 seconds prevents premature redelivery. The minimum ack deadline is 10 seconds, maximum is 600 seconds on a subscription.

Why this answer

The Pub/Sub subscription has a 10-second ack deadline, but the Cloud Function takes 25 seconds to process each message. Since the function does not acknowledge the message within the deadline, Pub/Sub considers the message unacknowledged and redelivers it, causing duplicate processing. The fix is to increase the ack deadline to exceed 25 seconds, ensuring the function has enough time to complete processing and send an acknowledgment.

Exam trap

The trap here is that candidates assume Cloud Functions automatically handle Pub/Sub ack deadlines or that increasing resources speeds up I/O-bound operations, but the exam tests understanding of the explicit ack deadline configuration and the need to match it to processing time.

How to eliminate wrong answers

Option A is wrong because Pub/Sub does not wait indefinitely; it enforces the ack deadline and redelivers messages if no acknowledgment is received within that time. Option C is wrong because the Cloud Function (gen2) does not automatically extend the ack deadline; the Pub/Sub client library can be used to modify the ack deadline programmatically, but this is not automatic and requires explicit code. Option D is wrong because increasing memory does not reduce processing time for sequential external API calls; the bottleneck is network latency and API response times, not compute speed.

Practice this question →

42

MCQmedium

A team needs to build a CI/CD pipeline that automatically tests and deploys to GKE when code is pushed to the main branch. Which GCP-native service builds and deploys the code automatically based on source code repository events?

A.Cloud Composer with a Git polling DAG

B.Cloud Build with a trigger configured on the repository's main branch

C.Cloud Run jobs triggered by a Pub/Sub subscription on the repository

D.Cloud Functions triggered by Cloud Source Repositories push events

AnswerB

Cloud Build Triggers monitor repository events and execute build steps defined in cloudbuild.yaml — including running tests and deploying to GKE.

Why this answer

Cloud Build is the correct GCP-native service for building and deploying code automatically based on source code repository events. By configuring a Cloud Build trigger on the main branch, any push to that branch automatically initiates a build and deployment to GKE, fulfilling the CI/CD pipeline requirement without additional orchestration.

Exam trap

Google Cloud often tests the distinction between event-driven compute services (Cloud Functions, Cloud Run) and purpose-built CI/CD services (Cloud Build), leading candidates to mistakenly choose Cloud Functions or Cloud Run because they can be triggered by repository events, even though they lack the integrated build-and-deploy pipeline required for GKE deployments.

How to eliminate wrong answers

Option A is wrong because Cloud Composer is a workflow orchestration service for Apache Airflow, not a CI/CD build-and-deploy service; using a Git polling DAG would be an inefficient, non-native workaround that does not provide event-driven, automated builds. Option C is wrong because Cloud Run jobs are designed for batch or scheduled compute tasks, not for building container images or deploying to GKE; they lack native source-code event triggers and CI/CD capabilities. Option D is wrong because Cloud Functions triggered by Cloud Source Repositories push events can run custom code on a push, but they are not designed to build container images or orchestrate deployments to GKE; they lack the integrated build, test, and deploy pipeline that Cloud Build provides.

Practice this question →

43

Multi-Selectmedium

Which TWO statements are correct about deploying an application with an HTTP(S) load balancer on Compute Engine?

Select 2 answers

A.A network load balancer can be used for UDP traffic.

B.A TCP proxy load balancer can only be used for non-HTTP traffic.

C.SSL proxy load balancers cannot terminate HTTPS traffic.

D.Internal load balancers require a proxy instance.

E.An HTTP(S) load balancer requires a backend service with a health check.

AnswersA, E

Network load balancers support UDP.

Why this answer

Option A is correct because a network load balancer (external) operates at Layer 4 and can forward UDP traffic, unlike HTTP(S) load balancers which only handle HTTP/HTTPS at Layer 7. This makes it suitable for UDP-based applications such as DNS, gaming, or streaming.

Exam trap

The trap here is that candidates confuse the TCP proxy load balancer's ability to handle HTTP traffic with the HTTP(S) load balancer's Layer 7 capabilities, leading them to incorrectly think TCP proxy is restricted to non-HTTP traffic.

Practice this question →

44

MCQmedium

A GKE node pool needs to be upgraded to a new node version. The cluster has 10 nodes. You need to minimize disruption to running workloads — no more than 2 nodes should be unavailable simultaneously. Which upgrade strategy should you configure?

A.Configure surge upgrade with `max-surge: 0, max-unavailable: 2`.

B.Configure surge upgrade with `max-surge: 10, max-unavailable: 10`.

C.Manually cordon and drain 2 nodes, upgrade them, then repeat.

D.Enable GKE Auto-upgrade with default settings.

AnswerA

max-unavailable: 2 limits simultaneous unavailable nodes to 2, meeting the requirement. max-surge: 0 means no extra nodes are provisioned (workloads are rescheduled as nodes drain sequentially in pairs).

Why this answer

Option A is correct because configuring `max-surge: 0` and `max-unavailable: 2` ensures that during the upgrade, no additional nodes are created (surge), and at most 2 nodes can be unavailable at any time. This directly satisfies the requirement of minimizing disruption by keeping at least 8 nodes available, while allowing the upgrade to proceed in controlled batches.

Exam trap

Google Cloud often tests the distinction between `max-surge` and `max-unavailable` parameters, and the trap here is that candidates may confuse `max-unavailable` with the number of nodes that can be upgraded simultaneously, or incorrectly assume that manual cordon-and-drain is the only way to control disruption, missing that GKE's surge upgrade configuration directly supports this requirement.

How to eliminate wrong answers

Option B is wrong because `max-surge: 10` would create 10 additional nodes, and `max-unavailable: 10` would allow all 10 original nodes to be unavailable simultaneously, which violates the constraint of no more than 2 nodes unavailable. Option C is wrong because manually cordoning and draining 2 nodes, upgrading them, then repeating is a valid approach but not a configured upgrade strategy within GKE's node pool upgrade settings; it requires manual intervention and does not leverage GKE's automated surge upgrade mechanism, making it less efficient and error-prone. Option D is wrong because GKE Auto-upgrade with default settings uses a rolling update with `max-surge: 1` and `max-unavailable: 0` by default, which would only upgrade one node at a time, but the question asks for a configured strategy that minimizes disruption to no more than 2 nodes unavailable, and auto-upgrade does not allow customizing these parameters to achieve the exact constraint.

Practice this question →

45

MCQmedium

A GKE application Pod needs a sidecar container that proxies all outbound network requests through an audit logger before they reach the internet. Both containers share the same network namespace. Which Kubernetes pattern implements this?

A.Run the audit logger as a separate Deployment and route traffic via a Service

B.Add the audit logger as a second container in the same Pod spec (sidecar pattern)

C.Use a DaemonSet for the audit logger on each node to intercept node-level traffic

D.Add an initContainer to start the audit logger before the main application

AnswerB

Containers in the same Pod share the network namespace — the sidecar can listen on localhost and proxy all traffic before it leaves the Pod's network namespace.

Why this answer

Option B is correct because the sidecar pattern allows two containers to share the same network namespace within a single Pod, enabling the audit logger to intercept all outbound traffic from the application container before it reaches the internet. This is achieved by configuring the application container to route its outbound requests through the sidecar (e.g., via a localhost proxy or iptables rules), ensuring all traffic is logged without external network hops.

Exam trap

Google Cloud often tests the distinction between initContainers and sidecars, where candidates mistakenly choose initContainers because they think 'start before the main app' implies ongoing traffic interception, but initContainers exit after completion and cannot proxy runtime traffic.

How to eliminate wrong answers

Option A is wrong because running the audit logger as a separate Deployment and routing traffic via a Service introduces network latency and a separate IP address, breaking the requirement for the sidecar to intercept traffic within the same network namespace; the application would need to be explicitly configured to use the Service, which is not a transparent proxy. Option C is wrong because a DaemonSet runs a pod on each node for node-level traffic interception (e.g., using eBPF or iptables), but it does not share the same network namespace as the application Pod and cannot intercept per-Pod outbound requests without complex network policies. Option D is wrong because an initContainer runs to completion before the main application starts and cannot persist to proxy ongoing outbound traffic; it is used for setup tasks, not for runtime traffic interception.

Practice this question →

46

MCQmedium

A company is migrating a legacy monolithic application to Google Cloud. The application runs on a single VM and contains both the web server and backend processes. The team wants to separate concerns and deploy the web tier on Cloud Run and the backend on Compute Engine. They need to allow the Cloud Run service to initiate HTTPS connections to the backend VM. What is the most secure way to accomplish this?

A.Assign a public IP to the backend VM and configure firewall rules to allow HTTPS from any source

B.Set up a VPN tunnel between Cloud Run and the VPC

C.Use Cloud NAT to provide outbound internet access to Cloud Run

D.Use Serverless VPC Access to connect Cloud Run to the VPC, and keep the VM internal

AnswerD

Serverless VPC Access enables private communication without public exposure.

Why this answer

Option D is correct because Serverless VPC Access creates a direct, private connection between Cloud Run and your VPC, allowing the Cloud Run service to reach the backend VM using its internal IP address. This avoids exposing the VM to the public internet, which is the most secure approach for initiating HTTPS connections between the two tiers.

Exam trap

Google Cloud often tests the misconception that Cloud NAT or public IPs are needed for serverless-to-VM communication, but the correct approach is to use Serverless VPC Access for private, secure connectivity without exposing the backend.

How to eliminate wrong answers

Option A is wrong because assigning a public IP and allowing HTTPS from any source exposes the backend VM to the entire internet, violating the principle of least privilege and creating a significant security risk. Option B is wrong because a VPN tunnel is used to connect external networks (e.g., on-premises) to a VPC, not to connect a serverless service like Cloud Run to a VM within the same VPC. Option C is wrong because Cloud NAT provides outbound internet access for private instances, but Cloud Run already has outbound internet access by default; the issue is inbound connectivity to the backend VM, which Cloud NAT does not address.

Practice this question →

47

Multi-Selecteasy

A developer is deploying an HTTP-triggered Cloud Function for a production application. Which TWO configuration options should be applied to ensure security and control costs? (Choose two.)

Select 2 answers

A.Allow unauthenticated invocations

B.Set a maximum instances limit

C.Set minimum instances to 0

D.Configure a custom domain for the function

E.Use a service account to authenticate invocations

AnswersB, E

Maximum instances prevents uncontrolled scaling and cost spikes.

Why this answer

Setting a maximum instances limit (option B) is correct because it prevents uncontrolled scaling of Cloud Functions, which could lead to excessive costs due to high concurrency. By capping the number of concurrent function instances, you ensure that even under heavy load, the function does not scale beyond a predefined budget, directly controlling cost in a production environment.

Exam trap

Google Cloud often tests the misconception that setting minimum instances to 0 is a cost-saving measure, but it is actually the default and does not control costs; the trap is confusing 'minimum instances' with 'maximum instances' for cost control.

Practice this question →

48

MCQhard

A platform team is deploying a multi-tier application on GKE: a frontend Deployment, a backend Deployment, and a Redis StatefulSet. The backend must be reachable by name from the frontend, but not from outside the cluster. Which Kubernetes resource enables internal name-based service discovery?

A.A NodePort Service for the backend

B.A ClusterIP Service for the backend

C.A LoadBalancer Service for the backend

D.A Kubernetes Ingress resource for the backend

AnswerB

ClusterIP Services get a stable cluster-internal IP and DNS name. Pods within the cluster resolve the service by name; it's not reachable from outside.

Why this answer

A ClusterIP Service exposes the backend Pods on a stable, internal IP address that is only reachable from within the GKE cluster. The frontend can resolve the backend by the Service's DNS name (e.g., `backend.default.svc.cluster.local`) using the cluster's internal DNS (CoreDNS), enabling name-based service discovery without exposing the backend to external traffic.

Exam trap

Google Cloud often tests the misconception that Ingress is used for internal service discovery, but Ingress is an external-facing layer-7 routing resource that requires a Service (typically ClusterIP or NodePort) to route traffic, and it does not provide internal DNS-based name resolution by itself.

How to eliminate wrong answers

Option A is wrong because a NodePort Service exposes the backend on a static port on every node's IP address, making it reachable from outside the cluster, which violates the requirement that the backend not be accessible externally. Option C is wrong because a LoadBalancer Service provisions an external cloud load balancer with a public IP, explicitly exposing the backend to the internet or external networks. Option D is wrong because a Kubernetes Ingress resource is an API object that manages external HTTP/S traffic routing to Services, typically requiring an Ingress controller and exposing the backend to external clients; it does not provide internal-only name-based discovery.

Practice this question →

49

Multi-Selecthard

Which TWO configurations are required to deploy a stateful workload on a regional managed instance group in Compute Engine? (Choose two.)

Select 2 answers

A.Define a stateful configuration that includes persistent disk

B.Configure a health check for the instance group

C.Assign static internal IPs to each instance

D.Attach a GPU to the instance template

E.Enable autoscaling

AnswersA, B

Stateful configuration ensures that persistent disks are preserved when instances are recreated.

Why this answer

Option A is correct because a stateful workload requires persistent data that survives instance restarts or failures. A stateful configuration in a regional managed instance group (MIG) must include a persistent disk definition to ensure that the disk is preserved and reattached to the new instance when the instance is recreated, maintaining state across instance lifecycle events.

Exam trap

Google Cloud often tests the misconception that autoscaling is required for any managed instance group, but for stateful workloads, autoscaling is typically avoided because it can lead to data loss by automatically terminating instances without preserving their stateful disks.

Practice this question →

50

MCQmedium

A network team is creating a new VPC and must decide between auto mode and custom mode. Why would they choose custom mode?

A.Auto mode VPCs cost more per subnet than custom mode

B.Custom mode allows full control over which regions have subnets and what CIDR ranges are used

C.Auto mode VPCs cannot be used with GKE clusters

D.Custom mode VPCs support more IP addresses per subnet than auto mode

AnswerB

In custom mode, the team creates subnets explicitly, choosing regions and CIDRs. This avoids CIDR conflicts with on-premises networks and prevents unnecessary subnet sprawl.

Why this answer

Custom mode VPCs give the network team full control over the IP address range (CIDR block) and the ability to create subnets in any region, unlike auto mode VPCs which automatically create subnets in every region with a fixed /20 range per region. This is essential when you need to avoid overlapping CIDRs with on-premises networks or other VPCs, or when you want to restrict subnets to specific regions for compliance or cost reasons.

Exam trap

Google Cloud often tests the misconception that auto mode VPCs are more expensive or have IP limitations, when in fact the key differentiator is control over subnet placement and CIDR range, not cost or capacity.

How to eliminate wrong answers

Option A is wrong because auto mode and custom mode VPCs have the same pricing model—there is no cost difference per subnet; both are free to create and use, with charges only for resources like NAT gateways or VPNs. Option C is wrong because auto mode VPCs can be used with GKE clusters; GKE supports both auto and custom mode VPCs, though custom mode is often preferred for more precise subnet control. Option D is wrong because both auto and custom mode VPCs support the same maximum IP address per subnet (the default limit is 256 IPs per subnet, which can be increased via quota request, but the mode does not affect this limit).

Practice this question →

51

MCQmedium

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?

A.Recreate strategy with `minReadySeconds: 30`.

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

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

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

AnswerB

maxUnavailable: 1 means at least 4 pods remain available. maxSurge: 1 means at most 6 pods exist simultaneously. This matches both constraints exactly.

Why this answer

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.

Exam trap

Google Cloud often tests the interaction between `maxSurge` and `maxUnavailable` by presenting values that seem reasonable but violate the given constraints, and the trap here is assuming that a higher surge or higher unavailable count is safe without calculating the resulting minimum available and maximum total replicas.

How to eliminate wrong answers

Option A is wrong because the Recreate strategy terminates all existing pods before creating new ones, causing downtime and violating the requirement of at least 4 replicas always available. Option C is wrong because `maxSurge: 2` allows up to 7 replicas (5 desired + 2 surge), exceeding the limit of 6 replicas at any time. Option D is wrong because `maxUnavailable: 2` allows up to 2 replicas to be unavailable, which could drop the available count to 3, violating the requirement of at least 4 replicas always available.

Practice this question →

52

Multi-Selectmedium

Which THREE steps are part of deploying a containerized application to Google Kubernetes Engine (GKE) using a CI/CD pipeline? (Choose three.)

Select 3 answers

A.Configure Cloud NAT for the cluster

B.Create a Compute Engine instance for the pipeline

C.Apply a Deployment manifest to the cluster

D.Create an instance template for the node pool

E.Push the image to Container Registry

.Build a Docker image from source code

AnswersC, E

The manifest defines the desired state of the application.

Why this answer

A typical CI/CD pipeline for GKE includes: building a container image, pushing it to Container Registry, and applying a Kubernetes manifest to deploy. Option B (create a Compute Engine instance) is not part of GKE deployment; Option C (create an instance template) is for MIGs. Option E (set up Cloud NAT) is for outbound networking, not deployment.

So A, D, and F are correct.

Practice this question →

53

MCQmedium

A team wants to roll back a GKE Deployment to its previous revision because the new version introduced a regression. Which kubectl command performs this rollback?

A.kubectl revert deployment/my-app --to-previous

B.kubectl rollout undo deployment/my-app

C.kubectl apply -f previous-deployment.yaml

D.kubectl delete deployment/my-app && kubectl create -f deployment.yaml

AnswerB

`kubectl rollout undo` reverts the Deployment to the previous ReplicaSet, effectively rolling back to the last stable version.

Why this answer

Option B is correct because `kubectl rollout undo deployment/my-app` is the standard Kubernetes command to roll back a Deployment to the previous revision. This command leverages the Deployment's revision history, which is automatically maintained by the Kubernetes controller, to revert the desired state to the prior revision without needing to manually reapply an old manifest.

Exam trap

Google Cloud often tests the distinction between `rollout undo` and non-existent commands like `revert`, or the misconception that reapplying an old YAML file is equivalent to a proper rollback, when in fact it bypasses the Deployment's revision history and can cause version mismatches.

How to eliminate wrong answers

Option A is wrong because `kubectl revert` is not a valid kubectl command; the correct verb is `rollout undo`, not `revert`. Option C is wrong because `kubectl apply -f previous-deployment.yaml` would reapply an old manifest file, but it does not perform a rollback to the previous revision tracked by the Deployment's history; it simply applies whatever YAML is provided, which may not match the exact previous revision and could introduce configuration drift. Option D is wrong because deleting and recreating the Deployment from a YAML file is a manual, error-prone process that bypasses the built-in revision history and does not guarantee a clean rollback to the exact previous revision; it also causes unnecessary downtime and does not leverage the Deployment's automatic revision tracking.

Practice this question →

54

MCQeasy

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?

A.Run the container using `docker run -p 8080:8080 IMAGE` with the required environment variables.

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

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

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

AnswerA

Cloud Run containers listen on port 8080 (by default) and are configured via environment variables. `docker run` locally replicates this environment closely for functional testing.

Why this answer

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.

Exam trap

The trap here is that candidates assume any `gcloud` command or Cloud Shell can simulate a local runtime, but the ACE exam tests the distinction between local container execution (Docker) and cloud deployment commands, where only `docker run` with proper port mapping and environment variables provides a local test that closely mimics the Cloud Run execution environment.

How to eliminate wrong answers

Option B is wrong because deploying to a staging Cloud Run environment using `gcloud run deploy --no-traffic` does not test the service locally; it deploys the container to GCP, which requires network connectivity and incurs costs, and the `--no-traffic` flag only prevents routing requests to the new revision, not enabling local testing. Option C is wrong because `gcloud run services describe` is a read-only command that retrieves metadata about an existing Cloud Run service (e.g., URL, revision details) and cannot simulate or execute a local run of the container. Option D is wrong because Cloud Shell, while having Docker installed, runs in a remote, resource-constrained environment that does not replicate the Cloud Run execution environment (e.g., it lacks the same sandboxing, request handling, and scaling behavior), and it is not intended for local testing of containerized services.

Practice this question →

55

MCQhard

You are configuring a GKE Autopilot cluster. A developer reports that their pod keeps being rejected with: `Autopilot rejected pod: resource request 0.5 vCPU and 64Mi memory is below minimum`. What should the developer do?

A.Switch to GKE Standard cluster to remove resource minimums.

B.Set resource requests to at least 250m CPU and 512Mi memory to meet Autopilot's pod minimums.

C.Add a LimitRange to the namespace to override Autopilot's minimum requirements.

D.Set `resources: {}` (empty) to let Autopilot choose the correct resource allocation automatically.

AnswerB

GKE Autopilot enforces minimum resource requests. Setting requests at or above the minimum (250m CPU, 512Mi memory) allows the pod to be scheduled.

Why this answer

B is correct because GKE Autopilot enforces minimum resource requests per pod: at least 0.5 vCPU (500m CPU) and 512Mi memory. The developer's request of 0.5 vCPU (500m) and 64Mi memory meets the CPU minimum but fails the memory minimum, so setting requests to at least 250m CPU and 512Mi memory satisfies both thresholds. This is a fundamental constraint of Autopilot's managed infrastructure model, not a configurable limit.

Exam trap

Google Cloud often tests the misconception that Autopilot's minimums are configurable via LimitRange or that empty resource requests will automatically assign compliant values, when in fact the minimums are hard-coded and must be explicitly met in the pod spec.

How to eliminate wrong answers

Option A is wrong because switching to GKE Standard removes Autopilot's resource minimums but is an unnecessary workaround that loses Autopilot's automated node management and security benefits; the correct solution is to adjust requests within Autopilot's constraints. Option C is wrong because a LimitRange cannot override Autopilot's hard-coded minimums—those are enforced at the cluster level by the Autopilot admission controller, not by namespace-scoped policies. Option D is wrong because setting empty resource requests (`resources: {}`) will cause Autopilot to apply its default minimums (0.5 vCPU, 512Mi memory), which still fails if the pod's actual needs are below that; the developer must explicitly set requests to meet or exceed the minimums.

Practice this question →

56

MCQeasy

A company wants to deploy a new version of their application with zero downtime. They are using a managed instance group (MIG) behind a load balancer. Which deployment method should they use?

A.Create a new MIG, then update the load balancer's backend service

B.Delete the current MIG and create a new one with the updated template

C.Update the instance template and restart all instances

D.Perform a rolling update using a new instance template, with a health check

AnswerD

Rolling updates replace instances gradually, and health checks ensure availability.

Why this answer

Option D is correct because a rolling update using a new instance template allows the managed instance group (MIG) to gradually replace instances with the new version while health checks ensure each new instance is healthy before proceeding. This maintains the desired capacity and avoids downtime, as the load balancer automatically directs traffic only to healthy instances throughout the process.

Exam trap

Google Cloud often tests the misconception that updating the instance template and restarting all instances (Option C) is acceptable for zero downtime, but this ignores the fact that simultaneous restarts cause a full outage unless the MIG is configured for a rolling update with health checks.

How to eliminate wrong answers

Option A is wrong because creating a new MIG and updating the load balancer's backend service introduces a manual cutover step that risks traffic disruption or misconfiguration, and does not leverage the MIG's built-in rolling update mechanism for zero downtime. Option B is wrong because deleting the current MIG before creating a new one causes a period with zero instances, resulting in downtime until the new MIG is fully operational. Option C is wrong because updating the instance template and restarting all instances simultaneously would cause all instances to be unavailable at once, leading to downtime; a rolling update is required to replace instances incrementally.

Practice this question →

57

MCQhard

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?

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

B.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.

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

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

AnswerB

This is the correct sequence: KMS key for signing → Container Analysis note → attestor referencing the key → Cloud Build signing step → BinAuthz policy requiring the attestor's signature at deploy time.

Why this answer

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.

Exam trap

Google Cloud often tests the misconception that enabling Binary Authorization on a cluster automatically integrates with Cloud Build to sign images, when in fact you must manually create the attestor, key, and attestation step.

How to eliminate wrong answers

Option A is wrong because enabling Binary Authorization on the GKE cluster does not cause Cloud Build to automatically sign images; Cloud Build requires explicit configuration to create attestations using an attestor and signing key. Option C is wrong because Artifact Registry vulnerability scanning only identifies vulnerabilities and does not create cryptographic attestations; GKE does not automatically trust scanned images without a Binary Authorization policy requiring attestations. Option D is wrong because the `gcloud container binauthz attestations sign-and-create` command requires a properly configured attestor and signing key (e.g., Cloud KMS) to be in place; simply adding the command as a build step without prior setup of the attestor and key will fail.

Practice this question →

58

MCQmedium

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?

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

B.Update the Service's label selector from 'version: blue' to 'version: green'

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

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

AnswerB

Changing the Service selector instantly redirects all new traffic to green Pods. Blue Pods continue running for instant rollback — simply change the selector back.

Why this answer

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'.

Exam trap

Google Cloud often tests the misconception that updating a Deployment's image tag or using kubectl patch on ClusterIP is the correct way to switch traffic, when in fact the Service's label selector is the precise mechanism for instant traffic redirection in blue-green deployments.

How to eliminate wrong answers

Option A is wrong because deleting the blue Deployment and creating the green Deployment as a replacement would cause downtime during the deletion and creation process, and does not provide an instant switch or easy rollback. Option C is wrong because updating a Deployment's container image tag triggers a rolling update, not a blue-green switch; GKE does not automatically perform a blue-green rollout based on image tag changes. Option D is wrong because a Service's ClusterIP is a virtual IP assigned by Kubernetes and cannot be patched to point to a different Deployment; the correct way to redirect traffic is by updating the label selector, not the ClusterIP.

Practice this question →

59

MCQmedium

A team is migrating a stateful application with local disk writes to GKE. The application requires a dedicated persistent disk that follows the Pod if it's rescheduled to a different node. Which Kubernetes resource provides this?

A.A HostPath volume pointing to a directory on the node

B.A ConfigMap mounted as a volume

C.A PersistentVolumeClaim backed by a GCE persistent disk StorageClass

D.An emptyDir volume scoped to the Pod

AnswerC

A PVC with a GCE persistent disk StorageClass provisions a durable disk that is detached from one node and reattached to the new node when the Pod is rescheduled.

Why this answer

A PersistentVolumeClaim (PVC) backed by a GCE persistent disk StorageClass is the correct choice because it provides a durable, network-attached block storage volume that persists independently of the Pod's lifecycle. When the Pod is rescheduled to a different node, the PVC ensures the GCE persistent disk is detached from the old node and reattached to the new node, preserving the application's state. This meets the requirement for a dedicated persistent disk that follows the Pod across rescheduling events.

Exam trap

Google Cloud often tests the distinction between ephemeral (emptyDir, HostPath) and persistent (PVC-backed) storage, trapping candidates who confuse node-local storage with cluster-wide persistent volumes that follow Pods across nodes.

How to eliminate wrong answers

Option A is wrong because a HostPath volume mounts a directory from the host node's filesystem, which is node-specific and does not follow the Pod if it is rescheduled to a different node; it also lacks the durability and portability required for stateful applications. Option B is wrong because a ConfigMap is designed for injecting non-sensitive configuration data (e.g., key-value pairs or small files) and is not a persistent storage volume; it cannot handle disk writes or maintain state across Pod reschedules. Option D is wrong because an emptyDir volume is ephemeral and scoped to the Pod's lifecycle—it is created when the Pod starts and deleted when the Pod is removed, so it does not persist data if the Pod is rescheduled to a different node.

Practice this question →

60

MCQmedium

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?

A.GKE Standard — it provides more control over node configuration

B.GKE Autopilot — managed nodes, automatic right-sizing, and per-Pod billing

C.GKE Standard with cluster autoscaler and node auto-provisioning enabled

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

AnswerB

Autopilot removes all node management: Google provisions, scales, and optimizes nodes automatically. Billing is based on Pod resource requests — precisely matching the described requirements.

Why this answer

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.

Exam trap

Google Cloud often tests the misconception that GKE Standard with autoscaling features provides the same per-Pod billing and zero node management as Autopilot, but the key difference is that Standard always bills for the underlying nodes, not the Pods.

How to eliminate wrong answers

Option A is wrong because GKE Standard requires manual node management and does not automatically right-size node resources; it bills for the underlying nodes, not per Pod. Option C is wrong because even with cluster autoscaler and node auto-provisioning, GKE Standard still bills for the provisioned nodes, not per Pod, and does not provide the same level of automatic right-sizing as Autopilot. Option D is wrong because Autopilot and Standard are fundamentally different in management overhead and billing model; Autopilot is not just a pricing model but a fully managed mode with distinct operational characteristics.

Practice this question →

61

MCQmedium

A DevOps engineer needs to deploy a new GKE Pod that mounts a ConfigMap named 'app-config' as environment variables. The ConfigMap already exists in the cluster. Which YAML snippet correctly references it?

A.envFrom: - configMapRef: name: app-config

B.volumes: - name: config / configMap: name: app-config

C.env: - name: CONFIG / valueFrom: secretKeyRef: name: app-config

D.envFrom: - secretRef: name: app-config

AnswerA

The `envFrom.configMapRef` pattern loads all keys from the named ConfigMap as environment variables — the correct approach for mounting an entire ConfigMap.

Why this answer

Option A is correct because the `envFrom` field with a `configMapRef` allows a Pod to load all key-value pairs from a ConfigMap as environment variables. This is the standard Kubernetes syntax for injecting ConfigMap data into a container's environment without specifying individual keys.

Exam trap

Google Cloud often tests the distinction between `configMapRef` and `secretRef` in `envFrom` blocks, and the trap here is that candidates confuse ConfigMaps with Secrets or incorrectly use volume syntax for environment variables.

How to eliminate wrong answers

Option B is wrong because it defines a volume mount for a ConfigMap, not environment variables; the correct syntax for a ConfigMap volume uses `configMap` (not `config`) and requires a `volumes` block plus a `volumeMounts` entry. Option C is wrong because it uses `secretKeyRef` to reference a ConfigMap, which is only valid for Secrets, not ConfigMaps; also, the `valueFrom` field is used for individual key references, not for loading the entire ConfigMap. Option D is wrong because it uses `secretRef` instead of `configMapRef`; `secretRef` is used to load Secrets as environment variables, not ConfigMaps.

Practice this question →

62

MCQmedium

A team is deploying a Cloud Function that requires a private environment variable containing an API key. They want the key stored securely and automatically injected at runtime. Which approach follows GCP best practices?

A.Hardcode the API key in the function source code

B.Pass the API key as a plain-text environment variable in the function configuration

C.Store the key in Secret Manager and reference it as a secret environment variable in the function deployment

D.Store the API key in a Cloud Storage bucket and download it at function startup

AnswerC

Cloud Functions support secret environment variables backed by Secret Manager. The secret value is injected at runtime, never stored in plain text in the function config.

Why this answer

Option C is correct because Secret Manager is the GCP-native service designed to securely store API keys and other sensitive data. By referencing a secret as an environment variable in the Cloud Function deployment configuration, the key is automatically decrypted and injected at runtime without exposing it in source code or configuration files. This follows the principle of least privilege and ensures the secret is encrypted at rest and in transit.

Exam trap

Google Cloud often tests the misconception that storing secrets in Cloud Storage with fine-grained ACLs is sufficient, but the trap here is that Secret Manager is the only service that provides automatic encryption, versioning, and audit logging for secrets without requiring custom code.

How to eliminate wrong answers

Option A is wrong because hardcoding the API key in source code exposes it in version control systems, logs, and build artifacts, violating security best practices. Option B is wrong because passing the API key as a plain-text environment variable in the function configuration stores it unencrypted in the deployment metadata and can be viewed in the Cloud Console or API responses. Option D is wrong because storing the key in a Cloud Storage bucket requires additional code to download and parse the file at startup, introduces latency, and risks exposing the key if bucket permissions are misconfigured or if the bucket is publicly accessible.

Practice this question →

63

MCQmedium

A company is deploying a microservices application on Google Kubernetes Engine (GKE). They want to expose their services to the internet using a single external IP address and route traffic based on the request path. Which resource should they use?

A.An Ingress resource

B.A Service of type NodePort

C.A Service of type LoadBalancer for each microservice

D.A Network Endpoint Group (NEG)

AnswerA

Ingress provides path-based routing with a single external IP.

Why this answer

An Ingress resource is the correct choice because it provides HTTP(S) layer 7 routing, allowing you to expose multiple services behind a single external IP address and route traffic based on request paths (e.g., /api to one service, /web to another). This meets the requirement of using one external IP and path-based routing, which a Service alone cannot achieve.

Exam trap

The trap here is that candidates often confuse a Service of type LoadBalancer with an Ingress, thinking that a LoadBalancer can also provide path-based routing, but a LoadBalancer operates at layer 4 (TCP/UDP) and cannot inspect HTTP paths, whereas Ingress operates at layer 7 and is specifically designed for such routing.

How to eliminate wrong answers

Option B is wrong because a Service of type NodePort exposes the service on a static port on each node's IP, but it does not provide a single external IP or path-based routing; it requires additional infrastructure (like an external load balancer) to route traffic. Option C is wrong because a Service of type LoadBalancer for each microservice would create a separate external IP per service, violating the requirement for a single external IP and not supporting path-based routing. Option D is wrong because a Network Endpoint Group (NEG) is a backend resource used with load balancers to specify endpoints (e.g., pods), but it does not itself expose services or route traffic based on request paths; it is a configuration component, not a routing resource.

Practice this question →

64

MCQhard

A company manages a production GKE cluster with node auto-upgrade enabled. They want to ensure that during a node upgrade, the workloads are rescheduled gracefully without downtime. What Kubernetes resource should be configured on their Deployments?

A.PodDisruptionBudget

B.HorizontalPodAutoscaler

C.ResourceQuota

D.Node affinity rules

AnswerA

PDB ensures a minimum number of pods remain available during voluntary disruptions.

Why this answer

PodDisruptionBudget (PDB) allows you to specify the minimum available or maximum unavailable pods during voluntary disruptions like node upgrades. Without a PDB, a node upgrade could evict all pods at once, causing downtime. ResourceQuota and HorizontalPodAutoscaler do not control disruption.

Practice this question →

65

Drag & Dropmedium

Arrange the steps to deploy a containerized application to Google Kubernetes Engine (GKE) using a Deployment and expose it via a Service.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Cluster must exist first; then Deployment, then Service to expose.

Practice this question →

66

MCQeasy

Which gcloud command creates a Compute Engine VM named 'web-01' using the e2-medium machine type in zone us-central1-a?

A.gcloud vm create web-01 --zone=us-central1-a --machine=e2-medium

B.gcloud compute instances create web-01 --zone=us-central1-a --machine-type=e2-medium

C.gcloud instances create web-01 --region=us-central1 --type=e2-medium

D.gcloud compute create-instance web-01 --zone=us-central1-a --size=e2-medium

AnswerB

This is the correct syntax. `gcloud compute instances create` is the command, `--zone` specifies the zone, and `--machine-type` specifies the VM size.

Why this answer

Option B is correct because the `gcloud compute instances create` command is the proper syntax for creating a Compute Engine VM, and it requires the `--machine-type` flag (not `--machine`) to specify the machine type. The zone is specified with `--zone`, and the VM name is provided as a positional argument.

Exam trap

Google Cloud often tests the exact command syntax, and the trap here is that candidates confuse the `gcloud compute instances create` command with shorter, non-existent variants like `gcloud vm create` or `gcloud instances create`, or they use incorrect flag names like `--machine` or `--size` instead of the correct `--machine-type`.

How to eliminate wrong answers

Option A is wrong because `gcloud vm create` is not a valid gcloud command; the correct resource hierarchy is `gcloud compute instances create`. Additionally, the flag for machine type is `--machine-type`, not `--machine`. Option C is wrong because it uses `--region=us-central1` instead of `--zone=us-central1-a`, and zones are required for VM creation (regions are used for regional resources like managed instance groups).

It also uses `--type=e2-medium` instead of `--machine-type=e2-medium`. Option D is wrong because `gcloud compute create-instance` is not a valid command; the correct verb is `instances create`. It also uses `--size=e2-medium` instead of `--machine-type=e2-medium`.

Practice this question →

67

MCQeasy

A company wants to expose a web application running on Compute Engine instances behind a managed instance group. They need a single IP address that distributes incoming HTTP traffic across instances. Which type of load balancer should they use?

A.Internal TCP/UDP Load Balancer

B.External TCP/UDP Network Load Balancer

C.SSL Proxy Load Balancer

D.External HTTP(S) Load Balancer

AnswerD

This is the correct choice for HTTP traffic distribution with a single IP.

Why this answer

Option D is correct because the External HTTP(S) Load Balancer is a regional or global, proxy-based Layer 7 load balancer that provides a single external IP address for distributing incoming HTTP traffic across Compute Engine instances in a managed instance group. It supports HTTP and HTTPS protocols, health checks, and autoscaling, making it ideal for web applications.

Exam trap

The trap here is that candidates often confuse the External HTTP(S) Load Balancer with the External TCP/UDP Network Load Balancer, mistakenly thinking that any load balancer with an external IP can handle HTTP traffic, but the Network Load Balancer lacks Layer 7 features and is not optimized for HTTP workloads.

How to eliminate wrong answers

Option A is wrong because the Internal TCP/UDP Load Balancer is used for internal traffic within a VPC network, not for exposing a web application to the internet. Option B is wrong because the External TCP/UDP Network Load Balancer is a Layer 4 load balancer that forwards traffic based on IP and port, but it does not support HTTP-specific features like URL routing or SSL termination, and it is not the recommended choice for HTTP traffic distribution. Option C is wrong because the SSL Proxy Load Balancer is designed for terminating SSL/TLS connections and forwarding TCP traffic, but it does not handle HTTP protocol inspection or routing, and it is not the standard choice for distributing HTTP traffic.

Practice this question →

68

MCQhard

A data engineering team is deploying a streaming Dataflow pipeline that reads from Pub/Sub and writes to BigQuery. They need to ensure that each event is processed exactly once, even in the event of failures. Which Dataflow feature should they use?

A.Enable at-least-once delivery on the Pub/Sub subscription

B.Set the Dataflow pipeline to use the 'exactly_once' parameter in the pipeline options

C.Rely on Dataflow's exactly-once processing guarantees

D.Use Cloud Functions to deduplicate messages before sending to Dataflow

AnswerC

Dataflow ensures exactly-once processing for streaming pipelines using its consistent model.

Why this answer

Dataflow's streaming engine provides built-in exactly-once processing guarantees for sources like Pub/Sub and sinks like BigQuery. This is achieved through a combination of checkpointing, deterministic replay, and idempotent writes, ensuring that each record is processed exactly once even during worker failures or pipeline updates. No additional configuration or external deduplication is required.

Exam trap

Google Cloud often tests the misconception that exactly-once processing requires explicit configuration or external deduplication, when in fact Dataflow provides it as a default behavior for supported sources and sinks.

How to eliminate wrong answers

Option A is wrong because enabling at-least-once delivery on the Pub/Sub subscription would allow duplicate deliveries, which contradicts the requirement for exactly-once processing. Option B is wrong because there is no 'exactly_once' parameter in Dataflow pipeline options; Dataflow's exactly-once behavior is inherent to the service and not controlled by a pipeline option. Option D is wrong because using Cloud Functions to deduplicate messages before sending to Dataflow adds complexity and latency, and Dataflow already handles exactly-once processing natively without needing external deduplication.

Practice this question →

69

MCQhard

A company is extending its on-premises network to Google Cloud using a Cloud VPN tunnel with dynamic routing (BGP). They have set up a Cloud Router in the VPN region. Which additional step is required for the Cloud Router to exchange routes with the on-premises router?

A.Create a static route for the on-premises network on the VPC

B.Configure a BGP session on the Cloud Router with the on-premises router's ASN and IP address

C.Assign an external IP address to the Cloud Router

D.Enable the IP forwarding feature on the VPN gateway

AnswerB

A BGP session is required to exchange routes. Cloud Router does not automatically peer without configuration.

Why this answer

For a Cloud VPN with dynamic routing (BGP), the Cloud Router must have a BGP session configured with the on-premises router. This session requires the on-premises router's ASN and its BGP peer IP address to exchange routes. Without this explicit BGP session configuration, the Cloud Router cannot establish a peering relationship or advertise/learn routes dynamically.

Exam trap

The trap here is that candidates often think Cloud Routers need an external IP (Option C) because they confuse Cloud Router with a physical router, but Cloud Routers are software-defined and communicate over the VPN tunnel using internal IPs.

How to eliminate wrong answers

Option A is wrong because creating a static route for the on-premises network on the VPC is unnecessary when using dynamic routing (BGP); BGP automatically exchanges routes, and static routes would conflict or be redundant. Option C is wrong because Cloud Routers do not require an external IP address; they operate within the VPC and communicate with the on-premises router via the VPN tunnel's internal IP addresses. Option D is wrong because IP forwarding is a VM-level setting (for instances acting as routers) and is not relevant to a Cloud VPN gateway; the VPN gateway inherently forwards traffic based on the routing table and BGP-learned routes.

Practice this question →

70

MCQhard

A Cloud Build pipeline builds a container image and pushes it to Artifact Registry. The next step needs to deploy the image to Cloud Run. The pipeline runs as the Cloud Build service account. What minimum permission does the Cloud Build SA need for the deployment step?

A.`roles/run.admin` only.

B.`roles/run.admin` and `roles/iam.serviceAccountUser` on the Cloud Run runtime service account.

C.`roles/owner` to ensure all necessary permissions are covered.

D.`roles/cloudbuild.builds.editor` on the Cloud Run project.

AnswerB

run.admin manages Cloud Run services. iam.serviceAccountUser (which grants `iam.serviceAccounts.actAs`) allows the Cloud Build SA to configure which SA Cloud Run runs as — both are required.

Why this answer

The Cloud Build service account needs `roles/run.admin` to deploy services to Cloud Run, but it also requires `roles/iam.serviceAccountUser` on the Cloud Run runtime service account (the identity the Cloud Run service runs as) because the deployment step impersonates that runtime service account to create or update the service. Without the `iam.serviceAccountUser` permission, the deployment fails with a permission denied error, even if the Cloud Build SA has full Cloud Run admin rights.

Exam trap

Google Cloud often tests the nuance that deploying to Cloud Run requires not just Cloud Run permissions but also the ability to impersonate the runtime service account, leading candidates to incorrectly choose `roles/run.admin` alone.

How to eliminate wrong answers

Option A is wrong because `roles/run.admin` alone does not grant the Cloud Build service account the ability to impersonate the Cloud Run runtime service account; the `iam.serviceAccountUser` role is required on that runtime service account for the deployment to succeed. Option C is wrong because `roles/owner` is overly permissive and violates the principle of least privilege; the minimum permissions are `roles/run.admin` and `roles/iam.serviceAccountUser` on the runtime service account, not full project ownership. Option D is wrong because `roles/cloudbuild.builds.editor` only allows managing Cloud Build builds, not deploying to Cloud Run; it does not include any Cloud Run or IAM impersonation permissions.

Practice this question →

71

MCQmedium

A startup is building a web application using Cloud Run. They want to deploy multiple independent services that can communicate with each other internally, but each service should be deployed and scaled independently. Which deployment strategy should they use?

A.Create multiple Cloud Run services and use internal endpoints for communication

B.Deploy the application to App Engine Standard Environment

C.Use a single GKE cluster with multiple deployments and services

D.Deploy a single Cloud Run service with multiple containers

AnswerA

Each Cloud Run service is independent and can communicate via internal URLs.

Why this answer

Cloud Run natively supports deploying multiple independent services, each with its own URL and scaling configuration. Internal communication between these services can be achieved using Cloud Run's built-in internal endpoints (e.g., using the `run.app` domain with internal traffic routing), which avoids exposing services to the public internet. This approach allows each service to scale independently based on its own request load, meeting the startup's requirement for independent deployment and scaling.

Exam trap

Google Cloud often tests the misconception that Cloud Run supports multiple containers per service (like a pod in Kubernetes), but Cloud Run services are single-container per revision, and multiple containers require separate services or a different platform like Cloud Run for Anthos.

How to eliminate wrong answers

Option B is wrong because App Engine Standard Environment is a fully managed platform that deploys a single application as a monolithic service; it does not natively support deploying multiple independent services that scale independently within the same project without using additional modules or services, which adds complexity and does not match the requirement for independent scaling. Option C is wrong because using a single GKE cluster with multiple deployments and services introduces the overhead of managing a Kubernetes cluster (node pools, networking, etc.) and is overkill for a simple web application; Cloud Run abstracts away cluster management entirely, making it a simpler and more cost-effective choice for independent services. Option D is wrong because a single Cloud Run service can only run one container per revision; multiple containers within a single service would share the same scaling behavior and cannot be deployed or scaled independently, which directly contradicts the requirement.

Practice this question →

72

MCQeasy

You need to deploy a new version of an App Engine standard environment application. The new version should receive 10% of traffic while the current version continues to receive 90%. Which command achieves this?

A.`gcloud app deploy --version=v2 --no-promote`

B.`gcloud app services set-traffic default --splits v1=0.9,v2=0.1`

C.`gcloud app versions migrate v2`

D.`gcloud app deploy --version=v2 --promote --stop-previous-version`

AnswerB

This command splits traffic between v1 (90%) and v2 (10%) for the default service — precisely the canary deployment pattern required.

Why this answer

Option B is correct because the `gcloud app services set-traffic` command explicitly splits traffic between versions of an App Engine service. By specifying `--splits v1=0.9,v2=0.1`, you direct 90% of requests to version v1 and 10% to version v2, without deploying a new version or promoting it. This is the standard method for gradual traffic migration in App Engine standard environment.

Exam trap

Google Cloud often tests the distinction between deploying a version (`deploy`), migrating all traffic (`migrate`), and splitting traffic (`set-traffic`), so the trap here is that candidates confuse `--no-promote` with traffic splitting, thinking it allocates a percentage of traffic when it actually just deploys without routing any traffic to the new version.

How to eliminate wrong answers

Option A is wrong because `gcloud app deploy --version=v2 --no-promote` deploys version v2 but does not split traffic; it leaves all traffic on the default version (v1), so v2 receives 0% of traffic. Option C is wrong because `gcloud app versions migrate v2` migrates all traffic to version v2 (100%), not a 10% split. Option D is wrong because `gcloud app deploy --version=v2 --promote --stop-previous-version` deploys v2, promotes it to receive all traffic, and stops the previous version, resulting in 100% traffic to v2, not a 10/90 split.

Practice this question →

73

MCQmedium

A team needs a GKE cluster named 'prod-cluster' in the us-central1 region with cluster autoscaling enabled, scaling between 3 and 10 nodes. Which command achieves this?

A.gcloud container clusters create prod-cluster --region=us-central1 --num-nodes=3 --enable-autoscaling --min-nodes=3 --max-nodes=10

B.gcloud kubernetes clusters create prod-cluster --location=us-central1 --autoscale=3:10

C.gcloud container cluster create prod-cluster --zone=us-central1 --scaling=3-10

D.kubectl create cluster prod-cluster --region=us-central1 --autoscale --min=3 --max=10

AnswerA

This command creates a regional GKE cluster with the node autoscaler configured to scale between 3 and 10 nodes. `--region` creates a regional (multi-zone) cluster.

Why this answer

Option A is correct because it uses the `gcloud container clusters create` command with the `--enable-autoscaling` flag, which enables cluster autoscaler for the GKE cluster. The `--min-nodes=3` and `--max-nodes=10` flags define the scaling range, while `--num-nodes=3` sets the initial node count, ensuring the cluster starts with 3 nodes and can scale up to 10 as needed. The `--region=us-central1` specifies a regional cluster, which is appropriate for production workloads requiring high availability across zones.

Exam trap

Google Cloud often tests the distinction between `gcloud container clusters` (correct for GKE) and `gcloud kubernetes clusters` (invalid), as well as the requirement to use `--enable-autoscaling` with separate `--min-nodes` and `--max-nodes` flags instead of shorthand syntax like `--autoscale=3:10`.

How to eliminate wrong answers

Option B is wrong because `gcloud kubernetes clusters create` is not a valid gcloud command; the correct command uses `gcloud container clusters create`. Additionally, `--autoscale=3:10` is not a valid flag; the correct flags are `--enable-autoscaling`, `--min-nodes`, and `--max-nodes`. Option C is wrong because `--zone=us-central1` is invalid since us-central1 is a region, not a zone; a zone would be like `us-central1-a`.

Also, `--scaling=3-10` is not a valid gcloud flag; the correct syntax uses `--enable-autoscaling` with separate min and max flags. Option D is wrong because `kubectl create cluster` is not a valid kubectl command; kubectl is used to manage Kubernetes resources, not to create GKE clusters. Additionally, `--autoscale`, `--min`, and `--max` are not kubectl flags for cluster creation.

Practice this question →

74

MCQeasy

A developer wants to deploy a Cloud Function that processes images uploaded to a Cloud Storage bucket. The function should be triggered automatically when an object is created. What is the best practice for setting up this trigger?

A.Use a Pub/Sub topic and a push subscription to invoke the Cloud Function

B.Create a Cloud Function with a Cloud Storage trigger and specify the bucket and event type

C.Use a Compute Engine instance to watch the bucket and call the function

D.Set up a Cloud Scheduler job to periodically scan the bucket and invoke the function

AnswerB

Cloud Functions natively support Cloud Storage triggers; this is the simplest approach.

Why this answer

Option B is correct because Cloud Functions natively supports Cloud Storage triggers via the `google.storage.object.finalize` event type, which fires when a new object is created in the specified bucket. This is the simplest and most reliable approach, as it eliminates the need for intermediate services and ensures low-latency, event-driven invocation directly from the storage layer.

Exam trap

Google Cloud often tests the misconception that Pub/Sub is required for all event-driven triggers, but Cloud Storage has a direct integration with Cloud Functions that avoids the overhead of an additional messaging layer.

How to eliminate wrong answers

Option A is wrong because using a Pub/Sub topic and push subscription adds unnecessary complexity and latency; Cloud Storage can directly trigger Cloud Functions without an intermediary, and Pub/Sub is typically used for decoupling or fan-out scenarios, not for direct storage events. Option C is wrong because using a Compute Engine instance to poll the bucket introduces compute cost, polling latency, and operational overhead, violating the serverless and event-driven best practices that Cloud Functions are designed for. Option D is wrong because Cloud Scheduler is a cron-based job scheduler for periodic tasks, not for real-time event triggers; it would introduce delays and inefficiency compared to the native event-driven trigger.

Practice this question →

75

MCQeasy

A small business wants to host a static website (HTML, CSS, JS) on Google Cloud. The site should have high availability and low latency for global users. The team has limited experience with infrastructure management and wants to minimize operational overhead and costs. They already have a custom domain. Which solution should they implement?

A.Use Firebase Hosting with the custom domain and enable Cloud CDN.

B.Store the website on Cloud Storage, point the custom domain to a global HTTP(S) load balancer, and enable Cloud CDN.

C.Package the static files as a container and deploy on Cloud Run with a managed SSL certificate.

D.Deploy the website on a single Compute Engine instance with a static IP and install a web server.

AnswerB

Standard, low-overhead, global solution.

Why this answer

Cloud Storage can host static content and integrate with Cloud CDN for low-latency delivery worldwide. This is serverless, highly available, and cost-effective. Option A is correct because it meets all requirements with minimal management.

Option B (Compute Engine) requires instance management and is overkill. Option C (Cloud Run) is for containerized apps, not ideal for pure static sites. Option D (Firebase Hosting) is also good but redundant with Cloud Storage; however, Cloud Storage with CDN is a standard solution and more flexible for custom domains.

Practice this question →

Page 1 of 2 · 99 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Deploying And Implementing A Cloud Solution questions.

Start 20-question session