GCP ACE Deploying and implementing a cloud solution: 158 practice questions

12 of the 158 Deploying and implementing a cloud solution questions in the Certsqill GCP ACE bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for GCP ACE? Take the free 5-min readiness check →

1. Spot VMs: Which Compute Engine pricing model is most appropriate?

1. Sustained Use Discounts (SUDs)

   Incorrect. Sustained Use Discounts are automatic discounts applied when you use a VM for more than 25% of a month. They apply to N1, N2, N2D, and C2 machine types. For 4-6 hour batch jobs run occasionally, SUDs would provide minimal discount and are far less impactful than Spot pricing.
2. Spot VMs ✓

   Correct. Spot VMs offer up to 91% discount over on-demand pricing. They can be preempted by Google when capacity is needed, but since the jobs can be checkpointed and restarted, preemption is handled gracefully. Spot VMs are the evolution of Preemptible VMs with no maximum 24-hour runtime constraint.
3. On-demand (standard) pricing

   Incorrect. Standard on-demand pricing is the most expensive option. Since cost reduction is the primary goal and the workload tolerates interruption with checkpointing, there is no reason to use full-price VMs.
4. Committed Use Discounts (CUDs) — 1-year commitment

   Incorrect. Committed Use Discounts (55-70% savings) require a 1 or 3-year commitment for a specific amount of compute. While cost-effective for steady-state workloads, they are not ideal for intermittent batch jobs and don't provide the same savings as Spot VMs for batch workloads.

Spot VMs offer up to 91% discount for fault-tolerant batch workloads that can tolerate preemption and support checkpointing.

2. gcloud container clusters get-credentials [CLUSTER]: Which sequence of commands is correct?

1. kubectl create deployment [NAME] --image=[IMAGE] --replicas=3 --port=8080, then gcloud container clusters get-credentials [CLUSTER] --region [REGION]

   Incorrect. kubectl needs cluster credentials configured before it can reach the GKE API server, so running kubectl create before gcloud ... get-credentials fails with an authentication error.
2. gcloud container clusters create [CLUSTER] --region [REGION] --num-nodes=3, then kubectl run [NAME] --image=[IMAGE] --replicas=3 --port=8080

   Incorrect. The cluster already exists, so gcloud container clusters create is wrong, and kubectl run creates a single Pod rather than a 3-replica Deployment as required.
3. gcloud container clusters get-credentials [CLUSTER] --region [REGION], then kubectl create deployment [NAME] --image=[IMAGE] --replicas=3 --port=8080 ✓

   Correct. First, gcloud container clusters get-credentials fetches the cluster credentials and configures kubectl's kubeconfig. Then kubectl create deployment creates the Deployment with the specified image, replica count, and port.
4. gcloud compute instances list --zones [ZONE], then kubectl apply -f deployment.yaml --namespace default --context [CLUSTER]

   Incorrect. gcloud compute instances list shows VMs and never configures kubectl; credentials must come from gcloud container clusters get-credentials before any kubectl apply.

Get GKE credentials first with gcloud container clusters get-credentials, then use kubectl create deployment to deploy the workload.

3. Cloud Storage trigger: Which Cloud Functions trigger type should they use?

1. Pub/Sub trigger firing when a message publishes to a topic

   Incorrect. A Pub/Sub trigger runs on messages published to a topic; Cloud Storage can relay via Pub/Sub, but the direct, recommended path for object uploads is a Cloud Storage trigger.
2. Firebase trigger reacting to Firebase product events

   Incorrect. Firebase triggers fire on Firebase events such as Realtime Database, Auth, or Firestore changes, not on uploads to a standard Cloud Storage bucket.
3. HTTP trigger invoked by an inbound HTTP client request

   Incorrect. An HTTP trigger runs only when it receives an HTTP request, so it cannot automatically react to a new object landing in a bucket without extra plumbing.
4. Cloud Storage trigger (Eventarc or direct bucket trigger) ✓

   Correct. Cloud Functions supports Cloud Storage triggers that invoke the function when storage events occur, such as object creation (finalize), deletion, or metadata update. This is the purpose-built trigger for reacting to Cloud Storage events.

A Cloud Storage trigger on Cloud Functions automatically invokes the function in response to object creation, deletion, or update events in a bucket.

4. BigQuery batch load jobs: Which data loading approach is most appropriate?

1. BigQuery batch load jobs (bq load command or load job API) ✓

   Correct. BigQuery batch load jobs are designed for bulk loading of files from Cloud Storage (CSV, JSON, Avro, Parquet, ORC). They are free (no charge for load jobs), efficient for large datasets, and can easily handle 500 GB within a 2-hour window. They can be scheduled daily using Cloud Scheduler.
2. BigQuery Storage Write API using streaming row inserts

   Incorrect. The Storage Write API and streaming inserts target near-real-time, row-by-row ingestion and cost more than batch loads, making them wrong for bulk-loading 500 GB of CSV files.
3. BigQuery Data Transfer Service scheduled from Cloud Storage

   Incorrect. The BigQuery Data Transfer Service is built for scheduled transfers from SaaS sources like Google Ads or YouTube, not for custom CSV files sitting in Cloud Storage.
4. Dataflow pipeline streaming Cloud Storage files into BigQuery

   Incorrect. Dataflow suits complex transformations or streaming, but it is more costly and complex than a native batch load job for a plain daily CSV import.

BigQuery batch load jobs are the standard, free mechanism for loading large files from Cloud Storage into BigQuery tables.

5. Cloud Deployment Manager: Which tool should they use?

1. Config Connector, managing GCP resources via Kubernetes

   Incorrect. Config Connector manages GCP resources through Kubernetes manifests; it is GCP-native but needs a running GKE cluster, so it is not the standalone IaC tool intended here.
2. Cloud Deployment Manager, Google's native IaC service ✓

   Correct. Cloud Deployment Manager is Google Cloud's native IaC service. It uses YAML configuration files with optional Python or Jinja2 templates for parameterization and reuse. Deployments are declarative and can be version-controlled in source control.
3. Terraform, a HashiCorp third-party multi-cloud tool

   Incorrect. Terraform is an excellent GCP IaC option but is a third-party HashiCorp tool, and the requirement explicitly calls for a Google-native solution.
4. Cloud Build, Google Cloud's managed CI/CD pipeline service

   Incorrect. Cloud Build is a CI/CD service that can run IaC commands but is not itself an IaC tool; it automates builds and deployments rather than declaring resources.

Cloud Deployment Manager is GCP's native IaC service using YAML/Python/Jinja2 templates to define and deploy GCP resources declaratively.

6. App Engine traffic splitting using cookie-based splitting: Which App Engine feature supports this?

1. Deploy v2 and configure a cron job that gradually raises v2 traffic over time

   Incorrect. A cron job calling gcloud to change traffic splits is needlessly complex and error-prone; App Engine's built-in traffic splitting handles the 10/90 rollout directly.
2. App Engine traffic splitting using cookie-based splitting for consistent affinity ✓

   Correct. App Engine traffic splitting supports splitting traffic between versions using three methods: IP address, cookie (GOOGAPPUID), or random. Cookie-based splitting ensures the same user is consistently routed to the same version (session affinity), which is ideal for canary deployments.
3. Deploy v2 as the default version and add A/B testing middleware in the application code

   Incorrect. Making v2 the default routes all traffic to it immediately, and coding A/B logic adds complexity that App Engine's infrastructure-level splitting avoids.
4. Use Cloud Load Balancing with weighted backend services split between v1 and v2

   Incorrect. App Engine Standard routes versions with its own built-in splitting and does not use an external Cloud Load Balancer for internal version weighting.

App Engine traffic splitting natively supports weighted version routing with cookie-based affinity for consistent canary deployments.

7. Create one topic with three separate subscriptions: How should the Pub/Sub subscriptions be structured?

1. Create three separate topics, one per service, and have the publisher application send each event to all three simultaneously

   Incorrect. Publishing to three topics forces the publisher to fan out explicitly; a single topic with multiple subscriptions is more decoupled since the publisher need not know its consumers.
2. Create one subscription shared by all three services, expecting each service to receive every published message

   Incorrect. With one shared subscription, competing consumers each get only a portion of messages, so each event would reach just one service rather than all three.
3. Create one topic with three separate subscriptions (one per service); each subscription will receive every message ✓

   Correct. In Pub/Sub, each subscription receives an independent copy of every message published to the topic. Three subscriptions = three independent copies of each message. Each microservice creates its own subscription and processes messages independently.
4. Use Pub/Sub message ordering keys to route each order event to the correct specific subscribing service

   Incorrect. Ordering keys only preserve per-key delivery order within a subscription; they do not route messages to particular subscribers or provide fan-out to multiple services.

Each Pub/Sub subscription receives an independent copy of every message — create one subscription per consuming service for fan-out delivery.

8. Partner Interconnect using two connections from two: Which connectivity option meets all requirements?

1. Dedicated Interconnect with a single 10 Gbps circuit terminated at the partner colocation facility

   Incorrect. Dedicated Interconnect requires the customer to be present in a Google-supported colocation facility, connecting physically to Google's network there. This scenario uses a 'partner' colocation facility, so Dedicated Interconnect cannot be provisioned.
2. Classic VPN over the public internet using a static route paired with BGP dynamic routing

   Incorrect. Classic VPN provides only a 99.9% SLA and traverses the public internet, so it is neither a dedicated private connection nor capable of 10 Gbps of guaranteed bandwidth.
3. HA VPN with two tunnels providing a 99.99% SLA over the public internet at limited bandwidth

   Incorrect. HA VPN offers a 99.99% availability SLA but runs over the public internet and is bandwidth-limited per tunnel, so it is not the dedicated, private 10 Gbps connection the requirement demands.
4. Partner Interconnect using two connections from two separate service providers for a 99.99% SLA ✓

   Correct. Partner Interconnect connects to GCP through a service provider at a partner colocation facility. A 99.99% SLA topology requires two connections from redundant providers, it supports high bandwidth including 10 Gbps, and MACsec or IPsec can encrypt traffic in transit.

Partner Interconnect connects via an authorized Google partner at a colocation facility and can achieve 99.99% SLA with a redundant dual-provider topology.

9. Store the Terraform state file in a Cloud Storage bucket: Which GCP-native approach is recommended for storing

1. Store the Terraform state file in a Cloud Storage bucket with object versioning enabled ✓

   Correct. Cloud Storage is the recommended GCP backend for Terraform state. Object versioning preserves historical state, the backend supports state locking, and multiple engineers share the same state by pointing at the same bucket and path.
2. Commit the terraform.tfstate file directly into the application's shared Git repository

   Incorrect. Storing state in Git is a known anti-pattern: state files can contain secrets, cause merge conflicts, and offer no locking to prevent concurrent modifications.
3. Use Cloud Source Repositories to hold the state file protected by branch permissions

   Incorrect. Cloud Source Repositories is Git-based and shares the same problems as any Git storage for state: no locking, possible secret exposure, and merge conflicts. Cloud Storage is the correct backend.
4. Store the state file as rows inside a managed Cloud SQL for PostgreSQL database instance

   Incorrect. Although Terraform's pg backend supports PostgreSQL, it requires running and maintaining a Cloud SQL instance with access configured. Cloud Storage is simpler, cheaper, and the standard GCP-native choice.

Cloud Storage with versioning enabled is the GCP-recommended backend for shared Terraform state management with locking support.

10. A startup script placed into the instance metadata using: Which mechanism enables this automated configuration

1. A Cloud Functions trigger firing on Compute Engine Audit Logs whenever a brand-new VM instance is created

   Incorrect. Event-driven automation via Cloud Functions is possible but overly complex for simple bootstrap configuration. Startup scripts run locally on the instance without external triggers or added dependencies.
2. A startup script placed into the instance metadata using the startup-script key or startup-script-url ✓

   Correct. Compute Engine runs startup scripts automatically at boot. The script can be supplied directly in the startup-script metadata key or fetched from Cloud Storage via startup-script-url, running as root to install packages and configure software.
3. Configure the guest OS to pull and run its installation commands over SSH from the Google Cloud Console

   Incorrect. Manually connecting over SSH to configure each instance does not scale and is not automated. Startup scripts provide fully automated, repeatable first-boot configuration.
4. A Cloud Scheduler job that connects over SSH to each new instance and runs the installation commands

   Incorrect. A Cloud Scheduler job would need to discover new instances, maintain SSH access, and run remote commands, which is fragile. Startup scripts are the native, purpose-built mechanism for first-boot setup.

Compute Engine startup scripts in instance metadata automatically run on first boot, enabling automated software installation and configuration.

11. It adds new nodes to the existing node pool: What does the Cluster Autoscaler do?

1. It evicts lower-priority Pods from the existing nodes to make room for the new Deployment's Pods here

   Incorrect. The Cluster Autoscaler scales nodes, not Pods. Evicting lower-priority Pods is Pod preemption, handled by the Kubernetes Scheduler using PriorityClasses, which is a separate mechanism.
2. It immediately provisions a brand-new node pool sized with the resources the new Deployment requires

   Incorrect. The Cluster Autoscaler scales existing node pools rather than creating new ones. Creating new node pools automatically is the job of Node Auto-Provisioning, a separate capability.
3. It adds new nodes to the existing node pool, up to the configured maximum, to place the pending Pods here ✓

   Correct. The GKE Cluster Autoscaler watches for Pods stuck in Pending due to insufficient resources and automatically adds nodes to the pool, up to the configured maximum, so those Pods can be scheduled.
4. It raises an alert in Cloud Monitoring and then simply waits for an operator to add the required nodes manually

   Incorrect. The Cluster Autoscaler acts autonomously; it does not alert and wait. It makes scaling decisions automatically based on Pod scheduling needs without manual intervention.

The GKE Cluster Autoscaler adds nodes to existing node pools (up to the configured maximum) when Pods cannot be scheduled due to insufficient resources.

12. gcloud storage cp -r /data/reports gs: Which command is correct?

1. gcloud storage put /data/reports gs://company-reports/2026/june/

   Incorrect. There is no gcloud storage put command. The correct subcommand for copying/uploading is cp.
2. gsutil sync /data/reports gs://company-reports/2026/june/

   Incorrect. gsutil sync (or gcloud storage rsync) synchronizes a source and destination by only transferring new or modified files. The question asks for an upload/copy operation, and 'sync' is a distinct command for incremental synchronization.
3. gcloud storage upload /data/reports gs://company-reports/2026/june/

   Incorrect. There is no gcloud storage upload command. The correct command is gcloud storage cp (or gsutil cp for the legacy tool). Using a non-existent command would result in an error.
4. gcloud storage cp -r /data/reports gs://company-reports/2026/june/ ✓

   Correct. The gcloud storage cp command copies files to Cloud Storage. The -r flag enables recursive copying of directories. This is the current recommended CLI (gcloud storage, formerly gsutil cp). The destination includes the bucket name and object prefix.

gcloud storage cp -r copies a local directory recursively to a Cloud Storage bucket, replacing the older gsutil cp command.

Other GCP ACE domains

• Planning and configuring a cloud solution — 108 questions →
• Ensuring successful operation of a cloud solution — 96 questions →
• Configuring access and security — 77 questions →
• Setting up a cloud solution environment — 61 questions →
• All 500 GCP ACE questions →