Google ACE Ensuring successful operation of a cloud solution Practice Test 2 — 15 Questions

Question 1

A team needs to export all Cloud Logging entries from a production GCP project to a BigQuery dataset for long-term analysis and compliance. The export must be near-real-time and include future log entries automatically. Which approach achieves this?

Accepted Answer

Create a log sink (Log Router) that routes all logs from the project to the BigQuery dataset. Option B is correct because a log sink (Log Router) in Cloud Logging can be configured to route log entries in near-real-time to a BigQuery dataset. This approach automatically includes all future log entries without requiring any scheduled jobs or manual intervention, making it ideal for long-term analysis and compliance.

Answer

Schedule a daily Cloud Function to query the Logging API and write results to BigQuery

Answer

Use BigQuery Data Transfer Service to pull logs from Cloud Logging on a schedule

Answer

Enable VPC Flow Logs and stream them directly to BigQuery

Question 2

A DevOps team monitors a Cloud SQL instance and notices its CPU is consistently above 85% for several hours. The instance handles a critical production database. What should be the team's immediate action?

Accepted Answer

Scale up the Cloud SQL instance machine type to add more vCPUs. Scaling up the Cloud SQL instance to a larger machine type with more vCPUs directly addresses sustained high CPU utilization by providing additional compute capacity. This is the immediate corrective action for a critical production database because it increases the instance's processing power without requiring architectural changes or downtime (if using a rolling update). Read replicas help with read-heavy workloads but do not reduce CPU load from write operations or complex queries on the primary instance.

Answer

Enable read replicas to distribute query load

Answer

Restart the Cloud SQL instance to clear CPU-intensive processes

Answer

Delete and recreate the instance with a larger machine type

Question 3

A Cloud Run service handles payment processing. A monitoring alert shows the service is experiencing 3-second P99 latency, up from its normal 200ms. The team wants to find the slowest individual requests in the last hour. Which tool provides per-request latency data?

Accepted Answer

Cloud Trace — sort traces by latency in the last hour. Cloud Trace is designed to capture end-to-end latency for individual requests, allowing you to sort and identify the slowest requests in a specific time range. The P99 latency increase indicates a tail-latency problem, and Trace provides per-request granularity to pinpoint the exact slow requests. This makes it the correct tool for finding the slowest individual requests in the last hour.

Answer

Cloud Monitoring — check the request_latencies metric distribution

Answer

Cloud Logging — filter for requests with duration > 3s

Answer

Cloud Profiler — view the slowest functions in the last hour

Question 4

A cost-conscious team notices their GKE cluster's node pools have consistently high memory utilization (>90%) while CPU remains at 30%. Pods are occasionally OOMKilled. What should they do to balance resource efficiency and stability?

Accepted Answer

Switch node pool machine type to a memory-optimized series (e.g., m2-ultramem) and ensure Pod memory requests are accurate. Option A is correct because the team has a memory-bound workload (high memory utilization, low CPU, OOMKills). Switching to a memory-optimized machine series (e.g., m2-ultramem) provides a higher memory-to-CPU ratio, directly addressing the memory pressure. Ensuring accurate Pod memory requests allows the scheduler to place Pods efficiently and prevents overcommitment, balancing resource efficiency with stability.

Answer

Increase CPU limits for all Pods to use the available CPU capacity

Answer

Enable vertical pod autoscaling (VPA) set to Recreate mode as the only change

Answer

Reduce the number of replica Pods to lower memory consumption

Question 5

A GKE node pool has an autoscaler configured with min=2, max=10 nodes. After a sustained traffic surge, the cluster scaled to 10 nodes. Traffic drops overnight to its normal level, but the cluster remains at 10 nodes after 4 hours. What is the most likely reason?

Accepted Answer

Pods have a PodDisruptionBudget preventing eviction, or nodes are still within the scale-down cooldown period. Option B is correct because the cluster autoscaler will not scale down nodes that are hosting pods protected by a PodDisruptionBudget (PDB) that prevents eviction, or if the nodes are still within the scale-down cooldown period (default 10 minutes after a scale-up). Since the cluster scaled up to 10 nodes during the traffic surge, the autoscaler must wait for the cooldown to expire and for all pods to be safely evictable before removing nodes. If any pods have a PDB that blocks eviction (e.g., requiring at least 3 replicas), the autoscaler cannot terminate the underlying nodes, keeping the cluster at 10 nodes even after traffic drops.

Answer

Cluster autoscaler only scales down once per day

Answer

The max node count prevents scale-down — setting max=10 locks the cluster at 10 nodes

Answer

Cloud Monitoring alerts are pausing the autoscaler to investigate the traffic drop

Question 6

A team's GCP project is approaching its monthly budget. They want to receive an email alert when spending reaches 80% and 100% of the $500 monthly budget. Which GCP feature sends these budget alerts?

Accepted Answer

Cloud Billing budget with alert thresholds set at 80% and 100%. Option C is correct because Cloud Billing budgets are the native GCP feature designed to monitor spending against a budget and send email alerts when actual or forecasted costs exceed user-defined thresholds (e.g., 80% and 100% of $500). This feature is configured directly in the Cloud Console or via the Billing API and automatically triggers notifications without requiring custom code or additional services.

Answer

Cloud Monitoring alerting policy on the billing/cost metric

Answer

A Cloud Scheduler job that queries the Billing API and sends an email when cost exceeds thresholds

Answer

Cloud Logging alert on billing cost log entries

Question 7

A team's application emits a custom business metric (orders per minute) via its code. They want to display this metric on a Cloud Monitoring dashboard and alert when it drops below 50 orders per minute. What must be done first?

Accepted Answer

Instrument the application to write the metric to the Cloud Monitoring API using a client library or OpenTelemetry. Option B is correct because Cloud Monitoring requires metrics to be explicitly ingested via its API or through OpenTelemetry. Custom metrics are not automatically available; the application must be instrumented to write the metric data (e.g., using the `cloud.google.com/go/monitoring` client library or OpenTelemetry exporter) to the Cloud Monitoring API. Without this step, the metric does not exist in Cloud Monitoring for dashboards or alerts.

Answer

Enable the Custom Metrics feature flag in the GCP Console under Cloud Monitoring settings

Answer

Create a log-based metric that extracts the orders value from application logs

Answer

Custom metrics require BigQuery — store values in BigQuery and link it to Cloud Monitoring

Question 8

An operations team wants to count how many times the string 'PaymentFailure' appears in application logs per minute and alert when it exceeds 10 occurrences. Cloud Monitoring doesn't have a native metric for this log pattern. What is the correct approach?

Accepted Answer

Create a log-based metric in Cloud Logging with a filter matching 'PaymentFailure', then alert on it in Cloud Monitoring. Option B is correct because Cloud Logging log-based metrics allow you to define a filter (e.g., `textPayload:"PaymentFailure"`) that counts matching log entries in real time, and Cloud Monitoring can directly create an alerting policy on that metric with a threshold of 10 occurrences per minute. This approach avoids custom code, external exports, or additional services, and it leverages the native integration between Cloud Logging and Cloud Monitoring.

Answer

Create a Cloud Monitoring custom metric and write values via the application's exception handler

Answer

Export logs to BigQuery and run a scheduled query counting PaymentFailure entries

Answer

Enable Cloud Trace and look for PaymentFailure in trace annotations

Question 9

A platform team wants to define a formal service level objective (SLO) for their API: 99.9% of requests must succeed (HTTP 2xx) over a 30-day rolling window. Which Cloud Monitoring feature tracks this?

Accepted Answer

Define a Cloud Monitoring SLO with a 99.9% availability target over a 30-day rolling window. Option B is correct because Cloud Monitoring's SLO feature is specifically designed to track compliance with a formal service level objective, such as 99.9% of requests succeeding over a 30-day rolling window. It automatically calculates the success rate from the selected metric (e.g., request count or latency) and reports the SLO's performance over the defined period, including error budgets and burn rates.

Answer

Create an alerting policy with a 99.9% threshold on the request success metric

Answer

Build a BigQuery dashboard showing 30-day average success rates from exported logs

Answer

Set an uptime check target of 99.9% in Cloud Monitoring

Question 10

A GKE cluster running Kubernetes 1.27 needs to be upgraded to 1.29. The cluster has a stateful workload with a PodDisruptionBudget requiring at least 2 out of 3 replicas running at all times. What is the correct upgrade sequence?

Accepted Answer

Upgrade the control plane to 1.28 first, then 1.29; then upgrade node pools incrementally, respecting the PDB. Option B is correct because Kubernetes requires that the control plane be upgraded one minor version at a time (e.g., 1.27 → 1.28 → 1.29) to maintain API compatibility and stability. After the control plane is upgraded, node pools can be upgraded incrementally, and the PodDisruptionBudget (PDB) ensures that during node upgrades, at least 2 out of 3 replicas remain available, preventing workload disruption.

Answer

Upgrade node pools first, then upgrade the control plane

Answer

Delete and recreate the cluster at version 1.29 to skip incremental upgrades

Answer

Upgrade control plane directly from 1.27 to 1.29, then upgrade node pools

Question 11

A team wants to create a consistent backup of a Compute Engine VM's boot disk before applying a major OS patch. The backup should be usable to restore the disk to a new VM if the patch fails. What is the recommended approach?

Accepted Answer

Create a persistent disk snapshot using `gcloud compute disks snapshot`. Option B is correct because a persistent disk snapshot captures a point-in-time, crash-consistent backup of the disk, including the boot disk, without requiring the VM to be stopped. Snapshots are the recommended method for backing up persistent disks because they support incremental backups, can be used to create new disks, and are optimized for restore operations to a new VM. This approach ensures the backup is usable for disaster recovery if the OS patch fails.

Answer

Create a custom VM image from the running instance using `gcloud compute images create`

Answer

Copy all files to a Cloud Storage bucket using gsutil rsync

Answer

Enable live migration for the VM — it automatically backs up state before migrations

Question 12

A team stores application log archives in a Cloud Storage bucket. Logs older than 90 days should automatically move to Coldline storage, and logs older than 365 days should be deleted. Which feature automates this?

Accepted Answer

Cloud Storage Object Lifecycle Management rules on the bucket. Option B is correct because Cloud Storage Object Lifecycle Management rules allow you to automatically transition objects to Coldline storage after 90 days and delete them after 365 days based on object age conditions. This is a native, serverless feature that requires no external compute or scheduling, making it the most efficient and reliable approach for automating tiering and deletion of log archives.

Answer

Cloud Scheduler jobs that run gsutil rewrite and gsutil rm commands nightly

Answer

Cloud Pub/Sub notifications triggering a Cloud Function on each object creation

Answer

Retention policies that lock objects in Coldline after 90 days

Question 13

A BigQuery table in a data pipeline receives daily data loads. To control storage costs, the team wants table data older than 180 days to be automatically deleted at the table level, not the dataset level. How should this be configured?

Accepted Answer

Configure partition expiration on a date-partitioned table to expire partitions after 180 days. Option C is correct because BigQuery's partition expiration feature allows you to automatically delete entire partitions from a date-partitioned table after a specified number of days. By setting the partition expiration to 180 days, all data in partitions older than 180 days is dropped at the table level, meeting the requirement without affecting other tables in the dataset.

Answer

Set a dataset-level default table expiration of 180 days in the dataset properties

Answer

Use a Cloud Scheduler job to run a DELETE statement on rows older than 180 days nightly

Answer

Set a table-level TTL using BigQuery's TTL API with a 180-day value

Question 14

A monitoring alert fires at 3 AM — the team's GKE Pods are being evicted. Investigation shows node memory is at 98%. Pods without resource requests are being evicted first. What is the long-term fix to prevent evictions?

Accepted Answer

Add explicit memory requests (and optionally limits) to all Pod specs. B is correct because setting explicit memory requests ensures the Kubernetes scheduler can accurately place Pods on nodes with sufficient resources, preventing the node from being overcommitted. Without requests, Pods are treated as burstable or best-effort, making them the first candidates for eviction under the kubelet's Quality of Service (QoS) classes when node memory pressure hits 98%. This is a long-term fix because it enforces proper resource governance at the scheduling level, not just a reactive measure.

Answer

Set higher memory limits on the Pods being evicted

Answer

Disable node-level eviction by modifying kubelet configuration

Answer

Add more nodes to the cluster to increase available memory

Question 15

A team needs a database backup job to run every day at 2 AM UTC. The job calls an HTTP endpoint to trigger the backup. The endpoint requires no complex orchestration — just a timed HTTP call. Which GCP service handles this most simply?

Accepted Answer

Cloud Scheduler with an HTTP target pointing to the backup endpoint. Cloud Scheduler is the simplest GCP service for a recurring HTTP call because it is a fully managed cron job service that directly supports HTTP targets. You configure a schedule (e.g., '0 2 * * *' for daily at 2 AM UTC) and point it to the backup endpoint URL. No additional code, queue, or orchestration is needed, making it the most straightforward solution for this use case.

Answer

Cloud Tasks with a daily task enqueued by a Cloud Function

Answer

Cloud Composer DAG running at 2 AM UTC

Answer

Cloud Run Jobs triggered by a Cloud Monitoring alert at 2 AM