GCP ACE Ensuring successful operation of a cloud solution: 96 practice questions

12 of the 96 Ensuring successful operation of 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. An alerting policy with a metric threshold condition: What should they configure in Cloud Monitoring?

1. An uptime check in Cloud Monitoring targeting the production Compute Engine instances that pages the SRE team when connectivity probes fail for over 5 minutes

   Incorrect. Uptime checks only verify endpoint reachability over HTTP, HTTPS, or TCP; they never measure CPU utilization, so they cannot alert on the described performance threshold.
2. A Cloud Logging log-based alert that parses VM log entries for CPU warnings and sends a PagerDuty notification to the SRE team whenever that pattern recurs on production instances

   Incorrect. Log-based alerts fire on log-text patterns, but CPU utilization is a metric, not a log entry, so a Cloud Monitoring metric-threshold alerting policy is the correct tool.
3. An alerting policy with a metric threshold condition on compute.googleapis.com/instance/cpu/utilization, a 5-minute alignment window, and a PagerDuty notification channel ✓

   Correct. Cloud Monitoring alerting policies consist of conditions (metric type, threshold, duration) and notification channels. The CPU utilization metric is compute.googleapis.com/instance/cpu/utilization. A condition duration of 5 minutes ensures the alert fires only if the threshold is sustained. PagerDuty is a supported notification channel.
4. A Cloud Scheduler job that polls the Cloud Monitoring API every minute and invokes PagerDuty whenever any instance reports CPU utilization above 80 percent

   Incorrect. A custom Cloud Scheduler polling loop is far more complex to build and maintain than Cloud Monitoring's native, managed alerting policies designed for exactly this case.

Cloud Monitoring alerting policies combine metric conditions (threshold + duration) with notification channels (including PagerDuty) for automated incident response.

2. Create a log sink that routes all audit logs to a Cloud: What is the most efficient solution?

1. Enable Cloud Audit Logs and configure them to write directly to BigQuery with a 5-year dataset expiration

   Incorrect. While a log sink to BigQuery is valid for audit log analysis, BigQuery is more expensive for long-term archiving than Cloud Storage. For pure retention/compliance purposes, Cloud Storage is more cost-effective. Additionally, audit logs are already automatically generated — you don't need to 'enable' them to write to BigQuery.
2. Configure Cloud Monitoring to archive all audit logs for 5 years

   Incorrect. Cloud Monitoring handles metrics and alerting, not log archiving. Log archiving is managed through Cloud Logging's log sinks and destinations.
3. Upgrade to Cloud Logging's Premium tier to extend retention to 5 years

   Incorrect. Cloud Logging does not have a 'Premium tier' with extended retention as of the current exam scope. Log buckets in Cloud Logging can be configured with custom retention (up to 3650 days = 10 years), but the standard solution for multi-year compliance archiving is exporting to Cloud Storage via a log sink.
4. Create a log sink that routes all audit logs to a Cloud Storage bucket with a 5-year retention policy ✓

   Correct. Log sinks export log entries to external destinations (Cloud Storage, BigQuery, Pub/Sub, or another log bucket). A Cloud Storage bucket with a 5-year Object Lifecycle Management policy or retention policy provides cost-effective long-term storage for compliance audit logs.

Log sinks export Cloud Logging entries to Cloud Storage, BigQuery, or Pub/Sub; a Cloud Storage sink with a retention policy is the cost-effective solution for long-term compliance archiving.

3. Cloud Error Reporting: Which Google Cloud service provides this capability?

1. Cloud Error Reporting ✓

   Correct. Cloud Error Reporting automatically groups and counts application errors, displays error frequency over time, shows stack traces, and can send notifications when new errors are detected. It integrates natively with App Engine, Cloud Functions, Cloud Run, GKE, and Compute Engine.
2. Cloud Logging with log-based metrics

   Incorrect. Cloud Logging stores log entries including exceptions, but it does not automatically group errors, deduplicate stack traces, or provide frequency analysis. Log-based metrics count log entries matching a pattern but require manual configuration and don't provide the automatic error grouping that Error Reporting offers.
3. Cloud Trace

   Incorrect. Cloud Trace is a distributed tracing service that tracks request latency across microservices. It helps identify performance bottlenecks in request paths, not application errors and exceptions.
4. Cloud Profiler

   Incorrect. Cloud Profiler continuously profiles CPU and heap memory usage of running applications to identify performance bottlenecks in code. It does not handle error tracking or exception grouping.

Cloud Error Reporting automatically groups, counts, and surfaces application exceptions with stack traces, providing a centralized error management view.

4. Create a custom image from the boot disk: Which approach creates a reusable template for new instance creation

1. Clone the instance using gcloud compute instances copy

   Incorrect. There is no gcloud compute instances copy command in GCP. To copy an instance, you create an image from its disk and launch new instances from that image.
2. Create a custom image from the boot disk ✓

   Correct. A custom image captures the full state of a disk (OS, installed software, configurations) and can be used as the source for new persistent disk creation when launching instances. Custom images are the standard way to create 'golden images' for instance templates.
3. Export the instance to Cloud Storage as a VM image file

   Incorrect. Exporting to Cloud Storage (as a .tar.gz) is used for migrating VMs from on-premises or other clouds (via VM Import). For GCP-native template creation, a custom image within GCP is the correct approach.
4. Take a snapshot of the boot disk

   Incorrect. Snapshots are incremental backups used for disaster recovery and disk restoration. While you can create a disk from a snapshot, snapshots are not the primary mechanism for creating launch templates. Custom images are purpose-built for the 'golden image' use case.

Custom images capture disk state for reuse as launch templates; snapshots are for backup and restoration of specific disk points in time.

5. The Google Cloud Ops Agent: What must be installed on the instances?

1. The Cloud Monitoring API client library in the application code

   Incorrect. The Cloud Monitoring client library allows applications to write custom metrics via code (for application-level metrics). However, it does not collect OS-level metrics like memory utilization or tail log files — those require the Ops Agent.
2. Enable the default VM monitoring in the Google Cloud Console — no agent is needed

   Incorrect. While Compute Engine provides some built-in metrics (CPU utilization, network I/O, disk I/O) without an agent, memory utilization is NOT included in the default built-in metrics. The Ops Agent must be installed to collect memory metrics.
3. The Google Cloud Ops Agent (formerly Stackdriver Agent) ✓

   Correct. The Ops Agent is the recommended unified agent for Compute Engine that collects system metrics (including memory, disk I/O beyond the built-in metrics) and logs from custom files. It replaces the older separate Monitoring Agent and Logging Agent.
4. Configure a Cloud Monitoring uptime check for each VM

   Incorrect. Uptime checks verify service availability (HTTP endpoint reachability), not OS-level resource metrics. They do not collect memory utilization data or application logs.

The Ops Agent must be installed on Compute Engine VMs to collect memory metrics and custom log files — these are not available by default.

6. Surge upgrades performing rolling node replacement: Which upgrade strategy should they use?

1. Enable Node Auto-Provisioning so it automatically upgrades the existing node pool to newer versions

   Incorrect. Node Auto-Provisioning creates and scales node pools based on workload resource requests; it does not perform the Kubernetes version upgrade process for an existing node pool.
2. Run kubectl drain on each node one by one and then manually upgrade the kubelet on every node

   Incorrect. Manual draining and kubelet upgrades apply to self-managed Kubernetes. GKE orchestrates node upgrades through its control plane, so this manual path bypasses GKE's upgrade automation and is not recommended.
3. Delete the entire node pool and then create a fresh replacement running the updated Kubernetes version

   Incorrect. Deleting and recreating a node pool evicts all Pods on those nodes simultaneously, causing downtime for workloads confined to that pool. This is a disruptive approach.
4. Surge upgrades performing rolling node replacement with configurable max-surge and max-unavailable ✓

   Correct. GKE Surge Upgrades control node replacement using max-surge (extra nodes created during the upgrade) and max-unavailable (nodes offline at once). Setting max-unavailable to 0 keeps a replacement ready before draining, giving zero downtime for workloads with Pod Disruption Budgets.

GKE Surge Upgrades allow rolling node pool upgrades with configurable max-surge and max-unavailable settings to achieve zero-downtime upgrades.

7. Create a log-based metric in Cloud Logging counting: How can they create an automated alert for this?

1. Create a log-based metric in Cloud Logging counting the matching audit entries, then alert on that metric with a Cloud Monitoring policy ✓

   Correct. Log-based metrics convert matching log entries into Cloud Monitoring metrics. A metric counting firewall-modification audit entries can then drive a Cloud Monitoring alerting policy that notifies via email, Slack, PagerDuty, and more.
2. Create a Cloud Monitoring alerting policy that reads the raw Cloud Audit Logs stream directly without any intermediate metric

   Incorrect. Cloud Monitoring alerting policies evaluate metrics, not raw log streams. To alert on log events you must first create a log-based metric and then alert on that metric.
3. Enable VPC Flow Logs on the network and configure them to notify the team whenever any firewall rule is changed later

   Incorrect. VPC Flow Logs capture network traffic metadata such as IPs, bytes, and packets. They do not record administrative configuration changes like firewall rule edits, which are captured by Cloud Audit Logs.
4. Configure a log sink exporting firewall modification entries to Cloud Pub/Sub and build a subscriber service that ultimately sends the alerts

   Incorrect. A Pub/Sub sink with a custom subscriber can alert on logs, but it requires writing and operating custom code. The log-based metric plus Cloud Monitoring alerting policy is the managed, purpose-built path.

Log-based metrics bridge Cloud Logging events to Cloud Monitoring metrics, enabling alert policies on specific log patterns like firewall modifications.

8. Cloud Trace: Which GCP service provides this capability?

1. Cloud Logging with structured logs

   Incorrect. Cloud Logging can correlate logs from multiple services using trace IDs, but it does not automatically generate distributed trace visualizations showing request flow and per-service latency breakdowns.
2. Cloud Monitoring latency dashboards

   Incorrect. Cloud Monitoring can display latency metrics per service, but it does not provide end-to-end request trace visualization showing how a single request flows through multiple services with per-hop timing.
3. Cloud Profiler

   Incorrect. Cloud Profiler collects CPU and heap memory profiles from running applications to identify slow functions and memory leaks within a single service. It does not trace requests across multiple services.
4. Cloud Trace ✓

   Correct. Cloud Trace is a distributed tracing system that collects latency data across services. It displays request traces as waterfall charts showing how requests flow through microservices, the time spent in each service, and where latency is introduced in the call chain.

Cloud Trace provides distributed request tracing with waterfall visualizations showing per-service latency across microservice call chains.

9. resource.type='cloud_run_revision': Which log filter correctly queries this?

1. resource.type='cloud_run_service' AND service_name='payment-service' AND level='ERROR' AND severity>=WARNING

   Incorrect. service_name and level are not valid Cloud Logging fields, and cloud_run_service is not the Cloud Run resource type. The correct fields are resource.labels.service_name and severity, with the type cloud_run_revision.
2. logName='payment-service' AND severity>='ERROR' AND resource.type='cloud_run_revision' AND timestamp>'-1h'

   Incorrect. The logName field must use the form projects/[PROJECT_ID]/logs/[LOG_ID], not the bare service name, so this filter would not match Cloud Run logs. Filter by resource.labels.service_name instead.
3. resource.type='cloud_run_revision' AND resource.labels.service_name='payment-service' AND severity >= ERROR ✓

   Correct. This uses valid query syntax: resource.type identifies Cloud Run revisions, resource.labels.service_name selects the service, and severity>=ERROR captures ERROR and higher levels such as CRITICAL and ALERT.
4. resource.type='gce_instance' AND resource.labels.service='payment-service' AND severity='ERROR' AND level>=WARN

   Incorrect. resource.type='gce_instance' targets Compute Engine VMs rather than Cloud Run, and the service label is wrong, so this filter returns no results for a Cloud Run service.

Cloud Logging queries use resource.type, resource.labels, and severity fields to filter logs by resource type, specific service name, and log severity.

10. Use Cloud SQL point-in-time recovery to clone the instance: What is the correct approach?

1. Access the instance's binary logs stored in Cloud Storage and then manually replay them up to 14:30 UTC to recreate the dropped table

   Incorrect. Cloud SQL binary logs are not directly accessible in Cloud Storage for manual replay. PITR applies the binary logs automatically; manual replay is not a standard Cloud SQL operation.
2. Use Cloud SQL point-in-time recovery (PITR) to clone the instance at the 14:30 UTC timestamp, then migrate the recovered data back ✓

   Correct. Cloud SQL PITR stores binary logs and restores to any point in the retention window by creating a clone of the instance at the chosen timestamp. The team then copies the recovered data back to production.
3. Export the current damaged instance to Cloud Storage as a SQL dump and then restore that export onto the production instance

   Incorrect. An export taken from the damaged instance would also be missing the dropped table, since the data is already gone. PITR instead restores from historical binary logs.
4. Restore the most recent automated nightly backup, which happened to be captured at some point before the 14:30 UTC table drop

   Incorrect. Restoring an automated backup returns the database to the exact moment the backup ran, for example midnight, losing many hours of later data. PITR is far more precise for near-real-time recovery.

Cloud SQL PITR uses binary logs to restore a database to any point within the retention window, minimizing data loss for accidental changes.

11. The service used 75% of its allowed failures in only 67%: What does this indicate, and what should the team do

1. 75% budget consumed is exactly what you would expect proportionally at 20 days into a rolling 30-day error-budget window, so the service is on pace

   Incorrect. Proportional consumption at 20 of 30 days would be about 66.7%, not 75%. Using 75% in 67% of the window means the error rate exceeds what the SLO allows and the budget is on track to run out early.
2. The service is performing well since 75% consumed still leaves a full 25% of the error budget available, so no investigation or action is needed

   Incorrect. Consuming 75% in only 67% of the window means the burn rate is about 1.12 times the allowable rate. If it continues, the budget is exhausted before the window ends, so early depletion needs investigation.
3. The 99.9% SLO is simply too strict for this particular service, so the team should relax the target to 99% to gain a larger error budget

   Incorrect. Loosening the SLO to hide a reliability problem is bad practice; the SLO reflects user expectations. The team should investigate and fix the underlying reliability issues instead.
4. The service used 75% of its allowed failures in only 67% of the window; the team should slow deployments and investigate the error sources now ✓

   Correct. A 99.9% SLO over 30 days allows a 0.1% error budget. Consuming 75% of it after 20 days (67% of the window) shows errors running above the allowed rate, so the team should reduce deployment velocity and fix reliability issues.

75% budget consumed in 67% of the window indicates an elevated error burn rate; the team should freeze deployments and fix reliability to protect the remaining budget.

12. Cloud Monitoring dashboards built from custom metric: Which service provides this capability?

1. Cloud Logging log-based views with saved query filters

   Incorrect. Cloud Logging offers log views and analysis and can create log-based metrics, but Cloud Monitoring is the service with full dashboard and charting capabilities for operational metrics.
2. Cloud Monitoring dashboards built from custom metric charts ✓

   Correct. Cloud Monitoring provides custom dashboards where you add charts for any metric (CPU, memory via Ops Agent, latency, and more), set time ranges, and share with the team, plus prebuilt dashboards for GCP services.
3. The default Google Cloud Console project overview summary page

   Incorrect. The Console project overview shows some basic metrics but cannot be built into a full operational dashboard combining multiple services' metrics in one view.
4. BigQuery paired with Looker Studio for analytics reports

   Incorrect. BigQuery and Looker Studio serve business intelligence and analytics dashboards. Although Cloud Monitoring can export metrics to BigQuery, the operational monitoring dashboard is native to Cloud Monitoring.

Cloud Monitoring dashboards provide customizable operational views with charts for any GCP metric, shareable across team members.

Other GCP ACE domains

• Deploying and implementing a cloud solution — 158 questions →
• Planning and configuring a cloud solution — 108 questions →
• Configuring access and security — 77 questions →
• Setting up a cloud solution environment — 61 questions →
• All 500 GCP ACE questions →