Google ACE Ensuring successful operation of a cloud solution — Timed 15 Questions

Question 1

A team wants to receive an email alert when the average CPU utilization of VMs in a managed instance group exceeds 80% for more than 5 minutes. What should they create in Cloud Monitoring?

Accepted Answer

An alerting policy with a CPU utilization threshold condition. B is correct because Cloud Monitoring alerting policies allow you to define conditions based on metric thresholds, such as average CPU utilization exceeding 80% for a specified duration (5 minutes). This directly meets the requirement to trigger an email alert when the condition is met.

Answer

A dashboard with a CPU utilization chart

Answer

A log-based metric filter for high-CPU events

Answer

An uptime check targeting the managed instance group

Question 2

A team wants logs from their Python application running on a Compute Engine VM to appear in Cloud Logging. What must be installed on the VM?

Accepted Answer

Ops Agent (Google Cloud's combined logging and monitoring agent). The Ops Agent is Google Cloud's unified agent for both logging and monitoring, and it is required to stream custom application logs from a Compute Engine VM to Cloud Logging. While the VM itself sends basic platform logs (e.g., serial console output), application-level logs (e.g., from a Python app) require the Ops Agent to collect, parse, and forward them to the Cloud Logging API.

Answer

Cloud Trace SDK for the Python application

Answer

Cloud Monitoring agent only

Answer

No installation needed — GCE VMs automatically stream logs to Cloud Logging

Question 3

A security analyst needs to retrieve all Cloud Logging entries with severity ERROR or higher across all resource types in the current project. Which log query correctly filters these entries?

Accepted Answer

severity >= "ERROR". Option C is correct because Cloud Logging's query language supports comparison operators like `>=` for severity levels, where `ERROR` is a recognized severity level. The query `severity >= "ERROR"` retrieves all entries with severity ERROR, CRITICAL, ALERT, or EMERGENCY, as these are considered higher severity than ERROR. This matches the requirement to filter for severity ERROR or higher across all resource types without restricting the time range or resource type.

Answer

severity >= ERROR AND timestamp > now() - 24h

Answer

severity="ERROR" AND resource.type="gce_instance"

Answer

logName="projects/my-project/logs/stderr" AND severity > "WARNING"

Question 4

A managed instance group (MIG) is running 4 VMs with a CPU autoscaling target of 60%. A traffic spike drives average CPU to 90%. How does the autoscaler respond?

Accepted Answer

The autoscaler adds VMs until average CPU across the group drops to approximately 60%. The autoscaler for a managed instance group (MIG) uses a target utilization metric—here, CPU at 60%. When average CPU exceeds that target (90%), the autoscaler calculates the desired number of VMs to bring utilization back to 60% (e.g., 4 VMs * 90% / 60% = 6 VMs) and adds instances accordingly. It does not terminate, migrate, or restart VMs; it scales out horizontally.

Answer

The MIG terminates the 2 least-used VMs to trigger a restart with higher performance settings

Answer

The MIG live-migrates instances to larger machine types automatically

Answer

The MIG restarts all existing VMs to clear cached load

Question 5

A load balancer is routing traffic to a VM where the application process has crashed, but the VM itself is still running. What prevents the load balancer from continuing to send traffic to this instance?

Accepted Answer

An HTTP health check configured on the backend service. The load balancer uses an HTTP health check to periodically probe the application on the VM. When the application process crashes, the health check fails (e.g., returns a non-2xx status code or times out), and the load balancer automatically stops routing new traffic to that unhealthy instance. This is the standard mechanism in Google Cloud for detecting application-level failures, as opposed to infrastructure-level failures.

Answer

A VPC firewall rule blocking traffic to the VM

Answer

A Cloud Armor security policy blocking the crashed instance's IP

Answer

The instance group autoscaling policy detecting the failure

Question 6

A microservices application has intermittent high latency. The team wants to identify which specific service-to-service call in the request chain is causing the slowdown. Which Cloud Operations tool is designed for this?

Accepted Answer

Cloud Trace. Cloud Trace is designed to capture latency data for individual service-to-service calls in a distributed request chain. It provides end-to-end tracing by collecting trace spans from each microservice, allowing you to pinpoint which specific call is causing the slowdown. This makes it the correct tool for identifying the exact service-to-service latency bottleneck.

Answer

Cloud Monitoring Metrics Explorer

Answer

Cloud Logging log viewer

Answer

Cloud Profiler

Question 7

A Go service is consuming significantly more CPU than expected. The team suspects an inefficient function but doesn't know which one. Which Cloud Operations tool identifies CPU hotspots in production code?

Accepted Answer

Cloud Profiler. Cloud Profiler is the correct tool because it continuously gathers CPU and heap usage data from production services using statistical sampling, then presents a flame graph or call tree that pinpoints which functions consume the most CPU. Unlike debugging or tracing tools, Profiler is designed specifically for identifying performance bottlenecks like CPU hotspots with minimal overhead, making it ideal for diagnosing an inefficient function in a Go service running in production.

Answer

Cloud Debugger

Answer

Cloud Trace

Answer

Cloud Monitoring custom dashboards

Question 8

A team wants proactive alerting if their public HTTPS endpoint returns a non-2xx HTTP status code or becomes unreachable — before users report it. Which Cloud Monitoring capability provides this?

Accepted Answer

An uptime check with an HTTP status code condition. An uptime check with an HTTP status code condition is the correct choice because Cloud Monitoring’s uptime checks are specifically designed to proactively verify that a public HTTPS endpoint is reachable and returns a successful HTTP status (e.g., 2xx). When the check detects a non-2xx status or a timeout/unreachable condition, it can trigger an alert before users are impacted. This is the only option that directly monitors endpoint availability and HTTP response codes from an external perspective.

Answer

A log-based alert on 5xx error log entries

Answer

A Cloud Armor rule blocking 5xx responses

Answer

A metric alert on instance CPU exceeding 90%

Question 9

A company runs a stable production workload on 20 n2-standard-8 VMs that run continuously year-round. Which pricing commitment maximizes cost savings on these VMs?

Accepted Answer

3-year committed use discount (CUD). The 3-year committed use discount (CUD) offers the highest discount rate (up to 57% for compute-optimized machine types) compared to 1-year CUDs (up to 20%) or sustained use discounts (up to 30% for running a VM the entire month). Since the workload runs 20 n2-standard-8 VMs continuously year-round, a 3-year CUD locks in the maximum savings for this predictable, steady-state usage.

Answer

Sustained use discounts (automatically applied)

Answer

1-year committed use discount (CUD)

Answer

Switching to Spot VMs

Question 10

A GKE Deployment must be updated to a new container image version with zero downtime — old Pods should be replaced gradually, not all at once. Which update strategy should be configured?

Accepted Answer

RollingUpdate strategy. The RollingUpdate strategy is correct because it gradually replaces old Pods with new ones while keeping the Deployment available, ensuring zero downtime. By default, it uses a `maxSurge` of 25% and `maxUnavailable` of 25%, allowing a controlled, incremental rollout that matches the requirement of replacing Pods gradually rather than all at once.

Answer

Recreate strategy

Answer

Blue-green deployment using a separate Deployment and Service selector swap

Answer

Canary deployment with a traffic-splitting ingress

Question 11

A Cloud Run service has been running for weeks. A sudden spike in 5xx errors appears in Cloud Monitoring. The team wants to view the actual request logs to identify which endpoint is failing. Where should they look?

Accepted Answer

Cloud Logging Logs Explorer — filter by resource type 'cloud_run_revision'. Cloud Logging's Logs Explorer is the correct place to view actual request logs for a Cloud Run service. It allows filtering by resource type 'cloud_run_revision' and by HTTP status codes (e.g., 5xx) to identify which specific endpoint is failing. Cloud Monitoring Metrics Explorer shows aggregated metrics, not individual log entries, so it cannot pinpoint the exact endpoint.

Answer

Cloud Monitoring Metrics Explorer — filter by request_count metric with error status

Answer

Cloud Trace — filter by 5xx response code

Answer

Cloud Debugger — set a snapshot at the error handler

Question 12

A managed instance group serves production traffic. During a rolling update to a new VM template, 30% of instances become unhealthy (failing health checks). The update has not completed yet. What should the team do to immediately restore service?

Accepted Answer

Pause the rolling update, then roll back using `gcloud compute instance-groups managed rolling-action rollback`. Option B is correct because the `gcloud compute instance-groups managed rolling-action rollback` command immediately reverts all instances in the managed instance group (MIG) to the previous template, restoring the known-good configuration. Pausing the update first stops the rollout from continuing to affect more instances, and the rollback command then replaces the unhealthy instances with the old template, allowing health checks to pass again.

Answer

Delete all unhealthy instances manually; the MIG will recreate them with the old template

Answer

Increase the target size of the MIG to dilute the unhealthy instances

Answer

Disable autohealing temporarily to prevent the MIG from restarting instances

Question 13

A team wants to automatically restart any GKE Pod that fails a liveness probe three consecutive times. The probe should check HTTP GET /healthz on port 8080, starting after 30 seconds and checking every 10 seconds. Which Pod spec configuration implements this?

Accepted Answer

livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3. Option B is correct because a livenessProbe with an HTTP GET on /healthz at port 8080, configured with initialDelaySeconds: 30, periodSeconds: 10, and failureThreshold: 3, will cause the kubelet to restart the Pod after three consecutive failed checks. This directly matches the requirement to restart on liveness probe failures, as liveness probes are specifically designed to determine if a container should be restarted.

Answer

readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3

Answer

startupProbe: httpGet: path: /healthz port: 8080 failureThreshold: 3

Answer

lifecycle: postStart: httpGet: path: /healthz port: 8080

Question 14

A production GKE cluster is running low on node resources. Pods are in Pending state because no node has sufficient CPU or memory. Without deleting existing Pods, what is the fastest way to resolve this?

Accepted Answer

Resize the node pool to add more nodes: `gcloud container clusters resize`. Option A is correct because resizing the node pool with `gcloud container clusters resize` immediately adds more nodes to the cluster, providing additional CPU and memory capacity. This allows the scheduler to place pending Pods without modifying or deleting existing workloads, making it the fastest solution that preserves running Pods.

Answer

Delete existing Pods to free resources for the Pending Pods

Answer

Change the Pending Pods' resource requests to zero

Answer

Upgrade the Kubernetes control plane version

Question 15

A billing report shows a Compute Engine VM has been running unused for 3 months. The team wants to stop it to save costs but needs the VM's disk data preserved for potential future use. What should they do?

Accepted Answer

Stop (shut down) the VM — compute charges stop but disk storage charges continue. Option B is correct because stopping (shutting down) a Compute Engine VM immediately halts all compute charges (vCPU, memory, GPU) while preserving the persistent disk and its data. The disk continues to incur storage costs, which is acceptable since the team wants to retain the data for potential future use. This is the most cost-effective approach that meets the requirement of preserving disk data without paying for idle compute resources.

Answer

Delete the VM to avoid all compute charges

Answer

Snapshot the VM disk and delete the VM

Answer

Set the VM to a smaller machine type to reduce costs