Courseiva

CCNA Deploying And Implementing A Cloud Solution Questions

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

Practice these questionsExam hubAll questions
76
MCQmedium

A team uses Cloud Build to build Docker images and push them to Artifact Registry. The cloudbuild.yaml has a step that requires a secret API key to call an external service during build. How should the secret be provided securely?

A.Pass the API key as a build substitution variable in the gcloud builds submit command
B.Reference the API key from Secret Manager using the availableSecrets field in cloudbuild.yaml
C.Store the API key in a Cloud Storage bucket and download it in a build step
D.Hardcode the API key in the cloudbuild.yaml and store it in the source repository
AnswerB

Cloud Build's `availableSecrets.secretManager` configuration retrieves the secret value at build time and makes it available as an environment variable, without logging the value.

Why this answer

Option B is correct because Cloud Build's `availableSecrets` field allows you to securely inject secrets from Secret Manager into build steps as environment variables or files, without exposing them in the build configuration or logs. This approach ensures the API key is encrypted at rest and in transit, and access can be controlled via IAM permissions, making it the only secure method among the options.

Exam trap

Google Cloud often tests the misconception that substitution variables are secure because they are 'variables,' but they are actually passed as plain text and can be logged, whereas `availableSecrets` is the only method that guarantees the secret is never exposed in the build configuration or logs.

How to eliminate wrong answers

Option A is wrong because substitution variables are passed as plain text in the `gcloud builds submit` command and can be visible in build logs or command history, violating security best practices. Option C is wrong because storing the API key in a Cloud Storage bucket and downloading it in a build step exposes the key to potential unauthorized access if the bucket is misconfigured, and the key is still visible in the build step's command or logs. Option D is wrong because hardcoding the API key in `cloudbuild.yaml` and storing it in the source repository makes the key accessible to anyone with repository access, and it can be exposed in version control history or build logs.

Practice this question →
77
MCQmedium

You are deploying a stateful application to GKE that requires each pod to have its own dedicated persistent disk, and each disk must persist data even if the pod is rescheduled to a different node. Which Kubernetes object type should you use?

A.Deployment with a shared PersistentVolumeClaim mounted by all pods.
B.StatefulSet with volumeClaimTemplates to provision individual PVCs per pod.
C.DaemonSet with a hostPath volume on each node.
D.Deployment with an emptyDir volume for each pod.
AnswerB

StatefulSets with volumeClaimTemplates create a unique PVC for each pod replica. The PVC persists through pod rescheduling, giving each pod its own dedicated, durable persistent disk.

Why this answer

A StatefulSet with volumeClaimTemplates is the correct choice because it automatically provisions a unique PersistentVolumeClaim (PVC) for each pod replica, ensuring each pod gets its own dedicated persistent disk. When a pod is rescheduled to a different node, the PVC remains bound to its original PersistentVolume (PV), allowing the new pod to mount the same disk and retain the data. This meets the requirement for both per-pod dedicated storage and data persistence across rescheduling events.

Exam trap

The trap here is that candidates often choose a Deployment with a shared PVC (Option A) because they think 'shared storage' is simpler, but they overlook the requirement for each pod to have its own dedicated disk, which a shared volume cannot provide.

How to eliminate wrong answers

Option A is wrong because a Deployment with a shared PersistentVolumeClaim mounted by all pods would cause all replicas to write to the same disk, leading to data corruption and failing the requirement for each pod to have its own dedicated persistent disk. Option C is wrong because a DaemonSet with a hostPath volume on each node ties the data to a specific node's filesystem, so if a pod is rescheduled to a different node, the data is lost or inaccessible, violating the persistence requirement. Option D is wrong because a Deployment with an emptyDir volume for each pod creates ephemeral storage that is deleted when the pod terminates, so data does not persist across rescheduling events.

Practice this question →
78
MCQeasy

A company wants to deploy a containerized web application on Google Kubernetes Engine (GKE) with minimal operational overhead. They require automatic scaling based on CPU utilization. Which resource should they configure?

A.Cluster autoscaler
B.VerticalPodAutoscaler
C.HorizontalPodAutoscaler
D.Node auto-provisioning
AnswerC

Correctly scales pods based on CPU utilization.

Why this answer

The HorizontalPodAutoscaler (HPA) is the correct resource because it automatically scales the number of pod replicas in a GKE deployment based on observed CPU utilization (or other custom metrics). This directly meets the requirement for automatic scaling with minimal operational overhead, as HPA is a native Kubernetes controller that adjusts replica counts without manual intervention.

Exam trap

Google Cloud often tests the distinction between horizontal scaling (adding/removing pods) and vertical scaling (adjusting pod resources) or infrastructure scaling (adding/removing nodes), leading candidates to confuse the HorizontalPodAutoscaler with the Cluster autoscaler or VerticalPodAutoscaler.

How to eliminate wrong answers

Option A is wrong because the Cluster autoscaler adjusts the number of nodes in the GKE cluster, not the number of pod replicas; it handles infrastructure-level scaling, not application-level scaling based on CPU utilization. Option B is wrong because the VerticalPodAutoscaler (VPA) adjusts CPU and memory requests/limits of existing pods, not the number of replicas; it is designed for right-sizing resource requests, not horizontal scaling. Option D is wrong because Node auto-provisioning is a feature that automatically creates new node pools when the cluster autoscaler cannot scale up due to insufficient resources; it does not directly scale pods based on CPU utilization.

Practice this question →
79
MCQhard

You are managing Terraform state for a GCP infrastructure project shared by a team of 5 engineers. You need to prevent simultaneous `terraform apply` operations from causing state corruption. What is the recommended backend configuration?

A.Store state locally on each engineer's machine and merge state files manually after each apply.
B.Configure the `gcs` backend in Terraform, pointing to a Cloud Storage bucket with versioning enabled.
C.Use Terraform Cloud (HashiCorp) as the backend for state locking.
D.Use a Cloud Source Repository to store state files with branch-based locking.
AnswerB

The GCS backend stores state remotely with automatic state locking. Concurrent applies are prevented — the second apply fails with a lock error until the first completes. Versioning provides state history for rollback.

Why this answer

Option B is correct because the `gcs` backend with versioning enabled provides both remote state storage and built-in state locking via Cloud Storage's object-level consistency model. When one engineer runs `terraform apply`, the backend acquires a lock by writing a lock file to the bucket; other concurrent operations are blocked until the lock is released, preventing state corruption. Versioning further protects against accidental state deletion or corruption by allowing rollback to previous state versions.

Exam trap

Google Cloud often tests the distinction between a remote backend that supports locking (like `gcs` or `s3`) versus a remote backend that only stores state (like `consul` without locking or a plain HTTP backend), and the trap here is that candidates may think any remote storage (like Cloud Source Repository) or a third-party service (like Terraform Cloud) is equally valid, when the question specifically requires a GCP-native solution with locking.

How to eliminate wrong answers

Option A is wrong because storing state locally on each engineer's machine and manually merging state files is error-prone, does not provide any locking mechanism, and directly contradicts Terraform's recommended practice of using a remote backend for team collaboration. Option C is wrong because Terraform Cloud is a HashiCorp product, not a GCP-native service, and while it does provide state locking, the question specifically asks for a 'recommended backend configuration' within the context of a GCP infrastructure project — the `gcs` backend is the GCP-native solution. Option D is wrong because Cloud Source Repository is a Git repository service, not a Terraform state backend; it does not support state locking or the Terraform state API, and branch-based locking is not a concept Terraform recognizes for state management.

Practice this question →
80
MCQhard

A company is deploying a multi-region application on Google Kubernetes Engine (GKE) with clusters in us-central1 and europe-west1. They want to route user traffic to the closest healthy cluster using a global load balancer with SSL termination. Which load balancing service should they use?

A.Internal Load Balancer
B.SSL Proxy Load Balancer
C.External TCP/UDP Network Load Balancer
D.External HTTPS Load Balancer with a global backend service (using NEGs)
AnswerD

This load balancer can route to multiple backends across regions and terminate SSL.

Why this answer

D is correct because the External HTTPS Load Balancer with a global backend service using Network Endpoint Groups (NEGs) provides global anycast IP, SSL termination, and traffic routing to the closest healthy GKE cluster via Google's global network. This meets the requirement for multi-region GKE clusters with automatic failover and low latency.

Exam trap

The trap here is that candidates often confuse regional load balancers (like SSL Proxy or TCP/UDP Network LB) with global ones, mistakenly thinking SSL termination alone is sufficient, but the key requirement for multi-region routing to the closest cluster demands a global load balancer with a global backend service.

How to eliminate wrong answers

Option A is wrong because an Internal Load Balancer is regional and cannot route traffic globally or terminate SSL for external users. Option B is wrong because the SSL Proxy Load Balancer, while supporting SSL termination, is a regional proxy-based load balancer and does not provide global anycast routing to the closest healthy cluster; it is designed for non-HTTP(S) traffic. Option C is wrong because the External TCP/UDP Network Load Balancer is a regional, passthrough load balancer that does not support SSL termination and cannot route traffic to the closest healthy cluster across regions.

Practice this question →
81
MCQmedium

You want to use Kustomize to manage environment-specific Kubernetes configurations (dev, staging, prod) from a single base set of manifests. How does Kustomize achieve environment customization without duplicating YAML files?

A.Kustomize duplicates all YAML files per environment, then applies find-and-replace on values.
B.Kustomize uses overlays that patch a shared base: environment-specific differences are expressed as patches without duplicating base manifests.
C.Kustomize uses Helm charts with values files per environment for templating.
D.Kustomize requires a separate Git branch per environment where manifests are committed.
AnswerB

The base contains common YAML (Deployment, Service, etc.). Overlays per environment contain only what differs (image tag, replicas, ConfigMap values) as patches. kubectl apply -k applies them merged.

Why this answer

Kustomize uses a base set of Kubernetes manifests and applies environment-specific overlays that contain patches. These patches modify only the differences (e.g., replicas, image tags, namespaces) without copying or altering the original base YAML files. This approach avoids duplication and keeps the base clean, with each overlay representing a distinct environment.

Exam trap

Google Cloud often tests the distinction between Kustomize's overlay/patch model and Helm's templating approach, so the trap is assuming any configuration management tool uses find-and-replace or requires separate branches.

How to eliminate wrong answers

Option A is wrong because Kustomize does not duplicate YAML files per environment; it uses a layered overlay model with patches, not find-and-replace. Option C is wrong because Helm charts use templating with values files, which is a different tool; Kustomize is template-free and relies on pure YAML patching. Option D is wrong because Kustomize does not require separate Git branches; it manages environments within the same repository using overlay directories.

Practice this question →
82
MCQhard

A company runs a multi-tier web application on Compute Engine: a frontend instance group (us-east1) and a backend instance group (us-east1) that stores data on persistent disks. They recently experienced a zone failure in us-east1-b, causing all instances in that zone to go down. The application was unavailable for 2 hours. The team is now required to design a solution that provides high availability across multiple zones within the us-east1 region and minimizes data loss. The frontend is stateless, but the backend holds critical state data on persistent disks. The team considers: (A) Migrate backend to use regional persistent disks and distribute backend instances across zones using a regional MIG. (B) Use a zonal MIG in us-east1-b with snapshots to another zone. (C) Move the entire application to a single zone in us-central1 with more resources. (D) Use Cloud SQL for backend data and keep Compute Engine instances in a single zone. Which option best meets the requirements?

A.Replace backend Compute Engine instances with Cloud SQL for data storage and keep frontend as is
B.Move all instances to a single zone in us-central1 with larger machine types
C.Keep the backend in a zonal MIG in us-east1-b but take hourly snapshots of persistent disks to a different zone
D.Use regional persistent disks for backend data and deploy a regional managed instance group for backend instances across us-east1-a and us-east1-b
AnswerD

Regional persistent disks are replicated across zones; regional MIG provides auto-healing and distribution.

Why this answer

Option D is correct because it uses regional persistent disks (which replicate data synchronously across two zones in the same region) combined with a regional managed instance group (MIG) that distributes backend instances across us-east1-a and us-east1-b. This architecture ensures that if one zone fails, the backend instances in the other zone can immediately attach the same regional persistent disk, minimizing data loss and providing high availability without requiring manual snapshot recovery.

Exam trap

Google Cloud often tests the distinction between zonal and regional resources; the trap here is that candidates may think snapshots or backups are sufficient for high availability, but they fail to recognize that snapshots do not provide automatic failover or near-zero data loss, which is only achievable with synchronous replication like regional persistent disks.

How to eliminate wrong answers

Option A is wrong because replacing backend Compute Engine instances with Cloud SQL does not address the requirement to minimize data loss from persistent disks; Cloud SQL is a managed database service, not a direct replacement for stateful application data stored on persistent disks, and it introduces a different data storage paradigm that may not support the existing application architecture. Option B is wrong because moving all instances to a single zone in us-central1 does not provide high availability across multiple zones within us-east1; it actually reduces availability by consolidating into one zone and ignores the requirement to stay within us-east1. Option C is wrong because keeping the backend in a zonal MIG in us-east1-b with hourly snapshots to another zone does not provide high availability; snapshots are point-in-time backups and cannot be used to instantly failover, resulting in up to one hour of data loss and significant recovery time, which fails the 'minimizes data loss' requirement.

Practice this question →
83
Matchingmedium

Match each BigQuery feature to its description.

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

Concepts
Matches

Unit of compute capacity for queries

Divides tables into segments for faster queries

Sorts data within partitions for better performance

Precomputed query results for faster access

In-memory analysis service for sub-second query response

Why these pairings

These features optimize BigQuery performance and cost.

Practice this question →
84
MCQeasy

A company wants to deploy a web application on Compute Engine. They expect variable traffic and want to automatically add or remove virtual machine instances based on CPU utilization. What is the recommended approach?

A.Use a single large instance and rely on Cloud Load Balancing
B.Use an unmanaged instance group and manually add or remove instances
C.Use a managed instance group with an autoscaling policy based on CPU utilization
D.Deploy the application on App Engine Standard environment
AnswerC

Managed instance groups with autoscaling automatically adjust instance count based on CPU utilization metrics.

Why this answer

A managed instance group (MIG) with an autoscaling policy based on CPU utilization is the recommended approach because it automatically adjusts the number of VM instances in response to real-time CPU load, ensuring the application can handle variable traffic without manual intervention. This aligns with Google Cloud's best practices for elastic scaling of stateless web applications on Compute Engine.

Exam trap

Google Cloud often tests the distinction between managed and unmanaged instance groups, where candidates mistakenly think unmanaged groups can be autoscaled, but only managed instance groups support autoscaling policies.

How to eliminate wrong answers

Option A is wrong because relying on a single large instance with Cloud Load Balancing does not provide autoscaling; a single instance cannot scale out to handle increased traffic and introduces a single point of failure. Option B is wrong because an unmanaged instance group requires manual addition or removal of instances, which contradicts the requirement for automatic scaling based on CPU utilization. Option D is wrong because App Engine Standard is a fully managed platform that abstracts infrastructure, but the question specifically asks about deploying on Compute Engine, not App Engine.

Practice this question →
85
MCQmedium

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

A.Set `successfulJobsHistoryLimit: 0` — GKE sends an alert when the history is empty
B.Create a log-based metric on CronJob failure events in Cloud Logging and an alerting policy on that metric
C.Set `restartPolicy: Always` on the CronJob's Pod template — it will retry until success
D.Enable GKE's built-in CronJob alerting feature in the cluster's Notifications settings
AnswerB

Kubernetes CronJob failures are logged as events in Cloud Logging. A log-based metric counting failure events, combined with a Cloud Monitoring alerting policy, sends notifications when failures occur.

Why this answer

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

Exam trap

The trap here is that candidates assume GKE has a native CronJob alerting toggle or that restart policies alone solve monitoring, when in reality you must explicitly create a log-based metric and alerting policy to detect job failures.

How to eliminate wrong answers

Option A is wrong because setting `successfulJobsHistoryLimit: 0` only removes completed job pods from history; it does not generate any alert and GKE has no built-in alert for an empty history. Option C is wrong because `restartPolicy: Always` is not valid for a CronJob's Pod template (only `Never` or `OnFailure` are allowed) and even if it were, it would retry the pod but not alert on failure. Option D is wrong because GKE does not have a built-in 'CronJob alerting feature' in cluster Notifications settings; cluster Notifications cover node and upgrade events, not CronJob failures.

Practice this question →
86
MCQmedium

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

A.terraform apply --resource=google_sql_database_instance.main
B.terraform apply -target=google_sql_database_instance.main
C.terraform apply -only=google_sql_database_instance.main
D.terraform plan --filter=google_sql_database_instance.main && terraform apply
AnswerB

The `-target` flag limits apply to the specified resource and its direct dependencies — creating only the Cloud SQL instance from the 15-resource plan.

Why this answer

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

Exam trap

Google Cloud often tests the distinction between valid Terraform flags like `-target` and common but invalid flags such as `--resource`, `-only`, or `--filter`, exploiting candidates' familiarity with other tools (e.g., `kubectl` or `gcloud`) that use similar but different syntax.

How to eliminate wrong answers

Option A is wrong because `--resource` is not a valid Terraform flag; Terraform uses `-target` for resource targeting. Option C is wrong because `-only` is not a valid Terraform flag; it does not exist in Terraform's CLI syntax. Option D is wrong because `--filter` is not a valid Terraform flag for `plan`; Terraform does not support filtering resources in `plan` output, and the proposed command chain would not achieve targeted application.

Practice this question →
87
MCQmedium

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

A.The Cloud Run service's container image is too large; reduce image size.
B.Set `min-instances: 1` to keep a warm instance running and eliminate the cold start latency.
C.Switch from Cloud Run to GKE, which doesn't have cold starts.
D.Increase Cloud Run's request timeout to 30 seconds to accommodate cold starts.
AnswerB

min-instances: 1 prevents scale-to-zero, keeping a container warm. The first request after inactivity hits a ready instance instead of waiting for container startup.

Why this answer

Cold starts occur when Cloud Run needs to spin up a new container instance from zero. The 3–5 second delay is the container startup time. Setting `min-instances: 1` keeps at least one instance warm at all times, eliminating cold starts for the first request.

This adds a small cost (one always-running instance) but is the most targeted fix. Increasing memory or CPU doesn't directly address cold start if the issue is container initialization time.

Practice this question →
88
MCQmedium

A company runs an App Engine Standard application with multiple versions. They want to gradually roll out new features by sending a small percentage of traffic to a new version. How should they implement this?

A.Deploy the new version and delete the old version
B.Use Cloud Load Balancing to distribute traffic between versions
C.Create a new service for the new version and use a custom domain
D.Use App Engine's traffic splitting feature to assign a percentage of traffic to the new version
AnswerD

Traffic splitting is natively supported by App Engine for gradual rollouts.

Why this answer

App Engine Standard provides built-in traffic splitting, allowing you to assign a percentage of incoming requests to different versions of the same service. This is the simplest and most direct way to gradually roll out a new feature by sending a small percentage of traffic to the new version without needing external load balancers or additional services.

Exam trap

The trap here is that candidates may confuse App Engine's internal traffic splitting with external Cloud Load Balancing, thinking they need to set up a separate load balancer when App Engine already provides this capability natively for version-level traffic distribution.

How to eliminate wrong answers

Option A is wrong because deleting the old version would immediately send 100% of traffic to the new version, which defeats the purpose of a gradual rollout. Option B is wrong because Cloud Load Balancing is used for distributing traffic across different services or regions, not for splitting traffic between versions of the same App Engine service; App Engine's traffic splitting handles this internally. Option C is wrong because creating a new service for the new version and using a custom domain would require separate scaling and routing, and it does not provide the fine-grained percentage-based traffic splitting between versions within the same service that the question requires.

Practice this question →
89
MCQmedium

A team deploys a containerized service to Cloud Run. After deployment, requests are timing out after 60 seconds. The service sometimes needs 3 minutes to process certain long-running requests. What should the team adjust?

A.Increase the minimum number of instances to reduce cold starts
B.Increase the Cloud Run request timeout to at least 180 seconds
C.Set concurrency to 1 to ensure each instance handles only one request at a time
D.Switch to Cloud Run Jobs instead of Cloud Run Services
AnswerB

Cloud Run's default request timeout is 60 seconds. For requests needing up to 3 minutes, the timeout must be explicitly increased (up to 3600 seconds via the console or `--timeout` flag).

Why this answer

Cloud Run has a default request timeout of 60 seconds. Since the service requires up to 3 minutes (180 seconds) for certain long-running requests, the timeout must be increased to at least 180 seconds. This is configured via the `--timeout` flag or the `timeout_seconds` field in the YAML configuration, and the maximum allowed value is 60 minutes (3600 seconds).

Exam trap

Google Cloud often tests the distinction between timeout-related issues and scaling or concurrency issues, so candidates mistakenly choose options that address cold starts or concurrency when the real problem is a hard timeout limit.

How to eliminate wrong answers

Option A is wrong because increasing the minimum number of instances reduces cold start latency but does not affect the request timeout; the 60-second timeout will still terminate long-running requests. Option C is wrong because setting concurrency to 1 limits the number of concurrent requests per instance but does not extend the request timeout; the request will still be terminated after 60 seconds. Option D is wrong because Cloud Run Jobs are designed for batch workloads that run to completion, not for handling HTTP requests; switching to Jobs would break the service's HTTP endpoint functionality.

Practice this question →
90
MCQmedium

A company recently deployed a web application on a managed instance group (MIG) behind a regional external HTTP(S) load balancer. The application is a Python Flask app running on Compute Engine VMs. After a code update that caused increased response times under load, users report intermittent 503 errors. You examine the load balancer logs and see that the backend instances are periodically marked as unhealthy. The health check is configured to query the /health endpoint every 5 seconds with a healthy threshold of 2 and a timeout of 1 second. The application's /health endpoint returns 200 OK, but sometimes takes up to 1.5 seconds to respond. What is the most likely cause of the health check failures?

A.The instances are overloaded and failing health checks intermittently.
B.The health check response timeout is too low for the application's increased response time.
C.The health check firewall rule is missing or misconfigured.
D.The health check is checking the wrong port.
AnswerB

Timeout of 1 second causes false negatives when response takes 1.5 seconds.

Why this answer

The health check is configured with a timeout of 1 second, but the /health endpoint now takes up to 1.5 seconds to respond due to the code update. Since the health check waits only 1 second for a response, any request that takes longer than that will be considered a failure, causing the backend to be marked unhealthy and triggering 503 errors. This is a classic mismatch between health check timeout and application response time.

Exam trap

Google Cloud often tests the distinction between a health check timing out versus the instance being truly unhealthy—candidates may incorrectly attribute intermittent 503s to overload (Option A) rather than recognizing that the health check timeout value is the direct cause when the endpoint response time exceeds it.

How to eliminate wrong answers

Option A is wrong because while overloaded instances can cause health check failures, the specific evidence here is that the /health endpoint itself takes up to 1.5 seconds to respond, which directly exceeds the 1-second timeout—overload is a possible symptom but not the root cause. Option C is wrong because a missing or misconfigured firewall rule would cause health checks to fail consistently (all probes would time out or be dropped), not intermittently with some successful responses. Option D is wrong because the health check is configured to query the /health endpoint on the correct port (default HTTP 80 or the port the app listens on), and the logs show that the endpoint does respond, just slowly—so the port is not the issue.

Practice this question →
91
MCQmedium

A company is deploying a stateful application on Google Kubernetes Engine (GKE) that requires persistent storage. Each pod needs its own dedicated persistent disk that is not shared. Which Kubernetes resource should be used to manage the deployment?

A.Job with PersistentVolume
B.DaemonSet with hostPath volumes
C.Deployment with PersistentVolumeClaim template
D.StatefulSet with volumeClaimTemplates
AnswerD

StatefulSet creates unique PersistentVolumeClaims for each pod, ensuring dedicated persistent storage.

Why this answer

Option D is correct because a StatefulSet with volumeClaimTemplates is designed for stateful applications where each pod requires its own dedicated PersistentVolume (PV) that is not shared. The volumeClaimTemplates automatically generate a unique PersistentVolumeClaim (PVC) for each pod replica, ensuring each pod gets a separate, stable persistent disk that persists across rescheduling. This matches the requirement for a stateful application on GKE where pods need dedicated, non-shared storage.

Exam trap

Google Cloud often tests the distinction between Deployments and StatefulSets, and the trap here is that candidates mistakenly choose a Deployment with a PVC template, not realizing that Deployments treat all pods as interchangeable and would share the same PVC, violating the 'dedicated disk per pod' requirement.

How to eliminate wrong answers

Option A is wrong because a Job is used for batch or one-time tasks, not for managing a long-running stateful application, and a PersistentVolume alone does not provide per-pod dedicated storage without a PVC. Option B is wrong because a DaemonSet runs one pod per node, typically for cluster-level services like logging or monitoring, and hostPath volumes use the node's local filesystem, which does not provide dedicated, persistent storage that survives pod rescheduling across nodes. Option C is wrong because a Deployment with a PersistentVolumeClaim template would share the same PVC across all replicas, leading to shared storage and potential data corruption, whereas the requirement is for each pod to have its own dedicated disk.

Practice this question →
92
MCQhard

A DevOps team uses Terraform to manage GCP infrastructure and wants to store Terraform state in a shared location that all team members can access securely, with state locking to prevent concurrent modifications. Which backend configuration achieves this?

A.gcs backend storing state in a Cloud Storage bucket
B.gcp backend storing state in a BigQuery table
C.remote backend connected to a Cloud SQL database
D.local backend with a path shared over Cloud Filestore
AnswerA

The `gcs` backend stores Terraform state in a Cloud Storage bucket and supports state locking via GCS object lock, enabling safe concurrent team usage.

Why this answer

The `gcs` backend is the correct choice because it stores Terraform state in a Google Cloud Storage bucket, which provides secure, shared access via IAM policies and supports state locking natively through object versioning and write-preconditions. This ensures that only one team member can modify the state at a time, preventing conflicts and corruption.

Exam trap

The trap here is that candidates confuse the `gcp` provider (which manages GCP resources) with a backend name, or assume that any shared filesystem (like Cloud Filestore) can provide locking, ignoring that Terraform requires atomic, server-side locking which only object storage backends like `gcs` or `s3` provide natively.

How to eliminate wrong answers

Option B is wrong because BigQuery is a data warehouse for analytics, not a state storage backend; it lacks native state locking and is not designed for the atomic write operations Terraform requires. Option C is wrong because the `remote` backend in Terraform is specifically for Terraform Cloud or Terraform Enterprise, not for connecting to a Cloud SQL database, which would require custom scripting and does not support built-in state locking. Option D is wrong because the `local` backend stores state on the local filesystem; sharing a path over Cloud Filestore does not provide state locking, as NFS does not support the atomic file locks Terraform needs, leading to race conditions and state corruption.

Practice this question →
93
MCQeasy

A developer needs to run an interactive shell inside a running GKE Pod named 'api-pod-7d4f9' in the 'production' namespace to investigate a runtime issue. Which kubectl command opens an interactive shell?

A.kubectl ssh api-pod-7d4f9 -n production
B.kubectl exec -it api-pod-7d4f9 -n production -- /bin/bash
C.kubectl run debug --image=busybox --attach=api-pod-7d4f9
D.gcloud container exec api-pod-7d4f9 --namespace=production -- bash
AnswerB

This command opens an interactive bash shell in the Pod. `-i` keeps stdin open, `-t` allocates a pseudo-TTY, `-n production` targets the correct namespace.

Why this answer

Option B is correct because `kubectl exec -it` attaches an interactive terminal to a running container in a Pod, with `-i` for stdin and `-t` for a TTY. The `-- /bin/bash` launches a Bash shell inside the container, allowing the developer to investigate runtime issues. This is the standard Kubernetes method for interactive shell access.

Exam trap

Google Cloud often tests the distinction between `kubectl exec` (for existing containers) and `kubectl run` (for creating new Pods), and candidates mistakenly choose options that use non-existent commands like `kubectl ssh` or `gcloud container exec`.

How to eliminate wrong answers

Option A is wrong because `kubectl ssh` is not a valid kubectl command; Kubernetes does not use SSH for container access, and this would fail. Option C is wrong because `kubectl run debug --image=busybox --attach=api-pod-7d4f9` creates a new Pod named 'debug' rather than attaching to the existing 'api-pod-7d4f9', and the `--attach` flag is misused (it attaches to the new Pod's logs, not the target Pod). Option D is wrong because `gcloud container exec` is not a valid gcloud command; the correct gcloud command for exec access is `gcloud container clusters get-credentials` followed by `kubectl exec`, and the syntax shown is incorrect.

Practice this question →
94
MCQmedium

A developer has an App Engine Standard application ready to deploy. The app.yaml file is in the current working directory. Which command deploys the application?

A.gcloud app create --config=app.yaml
B.gcloud app deploy
C.gcloud appengine deploy app.yaml
D.gcloud run deploy --platform=appengine
AnswerB

`gcloud app deploy` reads the app.yaml in the current directory, builds the application, and deploys it to App Engine Standard.

Why this answer

The `gcloud app deploy` command is the correct way to deploy an App Engine Standard application when the `app.yaml` file is present in the current working directory. This command automatically detects the configuration file and uploads the application code to the specified App Engine service, handling the deployment process including staging, versioning, and traffic migration.

Exam trap

The trap here is that candidates confuse `gcloud app deploy` with `gcloud app create` or Cloud Run commands, or they misremember the exact subcommand syntax, leading them to choose invalid options like `gcloud appengine deploy`.

How to eliminate wrong answers

Option A is wrong because `gcloud app create` is used to create a new App Engine application (project) in a region, not to deploy code; it does not accept a `--config` flag for deployment. Option C is wrong because `gcloud appengine deploy` is not a valid gcloud command; the correct subcommand is `gcloud app deploy`, and the syntax `app.yaml` as an argument is not required when it is in the current directory. Option D is wrong because `gcloud run deploy` is used for Cloud Run services, not App Engine; the `--platform=appengine` flag is invalid as Cloud Run does not support that platform.

Practice this question →
95
MCQeasy

A retail company has a customer-facing web application that runs on a legacy architecture. The application consists of a PHP frontend and a MySQL database that must be co-located on the same virtual machine due to hardcoded configuration paths. The company is migrating to Google Cloud. They want to minimize operational overhead and ensure the application is resilient to a single zone failure. Additionally, they need to apply critical OS security patches monthly without causing downtime. The application's traffic is predictable, with peak load during business hours. The company has a small IT team with limited Kubernetes expertise. They are willing to use managed services but want to keep the application architecture as simple as possible. The existing application is not containerized and uses a specific Linux distribution. They have already tested the application on Compute Engine and confirmed it works on Debian 10. The database is approximately 50 GB and needs to be durable. They also need to ensure that the application can recover quickly if an instance fails. Which deployment strategy should they use? (Choose the best option.)

A.Deploy the application on a managed instance group with at least two instances, each in different zones, behind a TCP load balancer. Use a shared persistent disk for the database mounted on both instances and configure the application to use the same database path. Use rolling replacement for patching.
B.Deploy the application in a GKE cluster with a single pod and a persistent volume claim for the database, using a LoadBalancer service. Use node auto-upgrades for patching.
C.Deploy the application on a managed instance group with at least two instances, each in different zones, behind a TCP load balancer. Use a regional persistent disk for the database and attach it to the primary instance; use a startup script to mount the disk and start the application. Use rolling updates for patching by updating the instance template and performing a rolling replacement.
D.Deploy the application on a single Compute Engine instance in a single zone. Use snapshots for backup and a Cloud Load Balancer with a health check pointing to the instance.
AnswerC

Provides zonal resilience, regional disk for durability, and rolling updates for zero-downtime patching.

Why this answer

Option C provides zonal resilience via a managed instance group across zones, uses a regional persistent disk for durability (can be attached to a new instance in case of failure), and rolling updates allow zero-downtime patching. Option A has no zonal resilience. Option B uses a shared persistent disk that cannot be attached read-write to multiple instances.

Option D requires containerization and Kubernetes expertise, which the company lacks.

Practice this question →
96
MCQeasy

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

A.kubectl get pod [POD_NAME] -o wide
B.kubectl describe pod [POD_NAME]
C.kubectl inspect pod [POD_NAME]
D.kubectl get pod [POD_NAME] -o json
AnswerB

`kubectl describe pod` provides full Pod details: container state, resource requests/limits, QoS class, scheduling events, probes, volumes, and the events section showing recent cluster activity for the Pod.

Why this answer

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

Exam trap

Google Cloud often tests the distinction between `get` and `describe`, where candidates mistakenly think `-o wide` or `-o json` provides the same event and status detail, but only `describe` automatically includes pod events and presents container status in a human-readable summary.

How to eliminate wrong answers

Option A is wrong because `kubectl get pod -o wide` only shows additional node and IP information, not events, container status details, or resource requests/limits. Option C is wrong because `kubectl inspect` is not a valid kubectl command; the correct verb for detailed inspection is `describe` or `get -o yaml/json`. Option D is wrong because `kubectl get pod -o json` outputs the raw JSON representation of the pod object, which includes resource requests/limits and container status but does not include pod events (which are a separate API resource) and is less human-readable than `describe`.

Practice this question →
97
MCQhard

A company uses Cloud Build to deploy a containerized application to a GKE cluster. The build process runs kubectl commands to apply Kubernetes manifests. The build fails with a 'Permission denied' error when executing kubectl. The Cloud Build service account has been granted roles/container.clusterAdmin and roles/cloudbuild.builds.builder. What is the most likely missing configuration?

A.Grant the Cloud Build service account roles/iam.serviceAccountTokenCreator
B.Add the Cloud Build service account to the GKE cluster's RBAC
C.Use a different Cloud Build trigger
D.Enable the Kubernetes Engine API
AnswerB

The service account needs RBAC permissions to run kubectl commands.

Why this answer

The Cloud Build service account has cluster-admin permissions via roles/container.clusterAdmin, but GKE uses Kubernetes RBAC for authorization within the cluster. The service account must be bound to a Kubernetes RBAC role (e.g., cluster-admin) via a ClusterRoleBinding to execute kubectl commands. Without this RBAC binding, the service account is authenticated but not authorized to perform actions, causing the 'Permission denied' error.

Exam trap

Google Cloud often tests the distinction between IAM roles (which control access to GCP APIs) and Kubernetes RBAC (which controls access within the cluster), causing candidates to mistakenly think that granting container.clusterAdmin alone is sufficient for kubectl operations.

How to eliminate wrong answers

Option A is wrong because roles/iam.serviceAccountTokenCreator allows generating OAuth2 access tokens for service accounts, which is unrelated to Kubernetes RBAC permissions needed for kubectl commands. Option C is wrong because the trigger type (e.g., push, pull request) does not affect the service account's permissions within the GKE cluster; the error is authorization-based, not trigger-related. Option D is wrong because the Kubernetes Engine API must already be enabled for the GKE cluster to exist and for Cloud Build to interact with it; the error occurs at the kubectl execution step, not at the API enablement level.

Practice this question →
98
Multi-Selectmedium

A company is deploying a stateless web application on Compute Engine. The application is served by a managed instance group with autoscaling behind an HTTP(S) load balancer. To minimize instance startup time and ensure that the application is ready to serve traffic as soon as an instance is created, which two steps should the company take? (Choose two.)

Select 2 answers
A.Increase the initial delay for the load balancer health check to 5 minutes.
B.Configure a startup script in the instance template that installs dependencies and starts the application.
C.Set the managed instance group's autohealing to replace unhealthy instances based on the load balancer health check.
D.Use a container-optimized OS and deploy the application as a Docker container via the startup script.
E.Create a custom machine image that includes the application and all dependencies.
AnswersD, E

Container-optimized OS with a Docker container can start quickly if the image is cached.

Why this answer

Option A (custom image) includes the application and dependencies, eliminating the need to install them at boot. Option C (container-optimized OS) allows the application to run as a Docker container, which can start quickly if the image is cached. Option B (startup script) adds time for installation.

Option D (autohealing) addresses health, not startup time. Option E (increase health check delay) increases time to serve traffic.

Practice this question →
99
MCQhard

A team has a streaming pipeline built with Apache Beam that reads from Cloud Pub/Sub and writes transformed data to BigQuery. Which GCP service executes this pipeline with managed autoscaling?

A.Cloud Composer
B.Cloud Dataflow
C.Cloud Dataproc
D.Cloud Data Fusion
AnswerB

Cloud Dataflow is the managed execution environment for Apache Beam pipelines. It autoscales workers for both streaming and batch jobs.

Why this answer

Cloud Dataflow is the correct service because it is a fully managed, autoscaling service specifically designed to execute Apache Beam pipelines. It handles the reading from Cloud Pub/Sub and writing to BigQuery, automatically scaling worker resources based on the pipeline's processing demands.

Exam trap

The trap here is that candidates often confuse Cloud Dataproc (which runs Spark) with Cloud Dataflow (which runs Beam), not realizing that Beam pipelines require Dataflow for managed autoscaling, while Dataproc requires manual cluster sizing or separate autoscaling policies.

How to eliminate wrong answers

Option A is wrong because Cloud Composer is a managed workflow orchestration service based on Apache Airflow, not a stream processing engine; it can trigger Dataflow jobs but does not execute Beam pipelines directly. Option C is wrong because Cloud Dataproc is a managed Spark and Hadoop service that can run batch or stream processing but does not natively execute Apache Beam pipelines with managed autoscaling; it requires manual cluster management or separate autoscaling configuration. Option D is wrong because Cloud Data Fusion is a fully managed data integration service for building ETL/ELT pipelines using a visual interface, but it does not execute Apache Beam pipelines and does not provide managed autoscaling for Beam-based streaming jobs.

Practice this question →
← PreviousPage 2 of 2 · 99 questions total

Ready to test yourself?

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

Start 20-question session