Google ACE Practice Question: Ensuring Successful Operation of a Cloud Solution

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Choose a time aggregation function (e.g., mean, max)

  Why this is correct

  Choosing a time aggregation function is essential because raw metric samples arrive at irregular intervals and need to be aligned to a fixed time step for a coherent time series. The aggregation function (e.g., mean, max, sum) reduces multiple points within each alignment window into a single value, which determines the chart's shape and sensitivity to spikes. Without this step, the dashboard may render unusable, too-dense data or fail to produce a meaningful trend. For CPU utilization, 'mean' is typical for overall usage, while 'max' can highlight peak behavior.

• ✓

  Select the resource type: 'gce_instance' and filter by the instance ID

  Why this is correct

  Selecting the resource type 'gce_instance' and applying an instance ID filter scopes the metric query to exactly one virtual machine. This step is necessary because a single metric descriptor can apply to many resources, and Cloud Monitoring needs to know which specific VM you want to visualize. The resource type tells the monitoring system to look at Compute Engine instances, and the filter isolates the instance's unique identifier (e.g., the instance ID, not the name). Omitting this could result in an aggregated chart across all instances or an error due to ambiguous resource selection.

• ✗

  Create a log-based metric for CPU utilization

  Why it's wrong here

  Creating a log-based metric for CPU utilization is unnecessary and technically wrong because Compute Engine already emits a standard metric, 'compute.googleapis.com/instance/cpu/utilization', directly from the underlying hypervisor. Log-based metrics are designed to extract custom measurements from log entries, such as application-level counters or error counts, not to duplicate infrastructure telemetry that already exists. Adding a log-based metric would involve parsing agent logs, introduce extra ingestion costs, and provide less accurate data than the native metric. This approach is a common misconception when the correct metric is readily available in the Cloud Monitoring metric catalog.

• ✓

  Select the metric: 'compute.googleapis.com/instance/cpu/utilization'

  Why this is correct

  Selecting the metric 'compute.googleapis.com/instance/cpu/utilization' is the core action that tells Cloud Monitoring which measured quantity to plot. This metric descriptor represents the fraction of allocated CPU time used by the VM, reported as a value between 0 and 1. It is a standard, agentless metric emitted directly by the Compute Engine infrastructure, so no additional configuration beyond selecting it is required. Choosing the correct metric string is mandatory because a dashboard chart cannot be built without a defined metric to query.

• ✗

  Set up a notification channel to send alerts

  Why it's wrong here

  Setting up a notification channel is unrelated to building a dashboard chart; notification channels (e.g., email, SMS, webhook) are used exclusively with alerting policies to notify users when a condition is met. A dashboard is a passive visualization tool that displays metric data in real time, and it does not require or support notification channels as a configuration step. While you could later create an alert on CPU utilization and attach a notification channel, that is a separate process outside the scope of constructing a dashboard. Including this step would be extraneous and confuses the distinction between monitoring and alerting.

Go deeper

Related to this question