PCDOE Implementing service monitoring strategies Practice Test 3 — 15 Questions

Question 1

A DevOps engineer notices that some Compute Engine instances are not reporting metrics to Cloud Monitoring. Which two potential causes should they investigate? (Choose two.)

Accepted Answer

The instances have insufficient IAM permissions to write metrics.. Compute Engine instances require the appropriate IAM permissions (e.g., roles/monitoring.metricWriter) to write metrics to Cloud Monitoring. Without these permissions, the API calls to ingest metric data are denied, even if the Ops Agent is installed and running.

Answer

The instances are in a different region and Cloud Monitoring doesn't support cross-region.

Answer

The instances are preemptible and automatically stop reporting after 24 hours.

Answer

The instances are in a different project and not peered.

Question 2

An alerting policy for high CPU utilization on a VM is firing even when CPU is not high. The team suspects a misconfiguration. Which two possible issues should they check? (Choose two.)

Accepted Answer

The alert condition is using the average aggregation with a short alignment period.. Using a short alignment period with average aggregation can cause the alert to fire on brief spikes in CPU utilization that do not represent sustained high usage. If the alignment period is too short (e.g., 1 minute), the alerting policy may trigger on transient bursts, even when the overall CPU load is low. This is a common misconfiguration in Google Cloud Monitoring (formerly Stackdriver) where the alignment period and aggregator settings must match the expected workload pattern.

Answer

The threshold is set too low compared to actual CPU usage.

Answer

The alerting policy was created in a different project and not imported.

Answer

The VM is reporting metrics from a custom namespace instead of the standard agent.

Question 3

You are designing SLO monitoring for a high-traffic e-commerce platform. Which three best practices should you follow? (Choose three.)

Accepted Answer

Use multiple SLOs for different critical user journeys.. Using multiple SLOs for different critical user journeys (e.g., checkout, product search, login) allows you to tailor reliability targets to the specific performance and availability needs of each workflow. This granularity prevents a single, coarse SLO from masking issues that affect only a subset of users, enabling more precise monitoring and faster incident response.

Answer

Use a single global SLO for all customer segments.

Answer

Set the SLO to 100% to ensure maximum reliability.

Question 4

An SRE team created the above logs-based metric. They expect it to count the number of HTTP 500 errors per instance. However, the metric shows no data. What is the most likely cause?

Accepted Answer

The log entries might not have the 'status' field in jsonPayload; it could be in a different location or format.. The most likely reason for a logs-based metric showing no data is that the log entries do not contain the expected 'status' field in jsonPayload, or it is located in a different field (e.g., httpRequest.status) or formatted as a string instead of an integer. Cloud Logging metrics rely on exact field paths defined in the metric descriptor; if the field is missing or misnamed, no data points are generated.

Answer

The metric kind is DELTA but should be CUMULATIVE.

Answer

The metric name does not follow the required naming convention.

Answer

The labelExtractors must use regex instead of JSON path.

Question 5

A team notices that the 'cpu-high' alert fires frequently even for short bursts. The 'disk-full' alert never sends notifications. Based on the exhibit, what is the issue with each?

Accepted Answer

The cpu-high alert duration is too short; the disk-full alert has no notification channel.. The 'cpu-high' alert fires frequently for short bursts due to its duration being set too short, causing it to trigger on transient spikes. The 'disk-full' alert never sends notifications because it lacks a configured notification channel, so even when the condition is met, no alert is dispatched.

Answer

The cpu-high uses email which is unreliable; the disk-full condition is too low.

Answer

Both alerts have misconfigured durations.

Answer

The cpu-high threshold is too high; the disk-full duration is too long.

Question 6

The above MQL query is used in a Cloud Monitoring dashboard. What does it display?

Accepted Answer

The 99th percentile latency of each span_id, every minute.. The MQL query uses the `fetch` command to retrieve spans from the `my-service` service, then applies `percentile(99)` to the latency metric, and groups the result by `span_id` using the `into` clause. The `every 1m` parameter sets the alignment window to one minute. This produces a time series showing the 99th percentile latency for each distinct span_id, updated every minute.

Answer

The total number of spans in 'my-service' each minute.

Answer

The maximum latency of spans grouped by span_id.

Answer

The 99th percentile latency of all spans in the 'my-service' service, every minute.

Question 7

A team wants to monitor the latency of a microservice deployed on GKE. Which Google Cloud tool should they use to collect custom metrics?

Accepted Answer

Cloud Monitoring. Cloud Monitoring (formerly Stackdriver Monitoring) is the correct tool because it allows you to collect, visualize, and alert on custom metrics via the Monitoring API or the `custom.googleapis.com` metric namespace. For a microservice on GKE, you can instrument your application with the OpenTelemetry SDK or the Cloud Monitoring client library to push custom latency metrics directly into Cloud Monitoring, where they can be queried and used in dashboards or alerting policies.

Answer

Cloud Logging

Answer

Cloud Trace

Answer

Error Reporting

Question 8

A company has an application that experiences intermittent errors. They want to be notified immediately when the error rate exceeds 1% of total requests. What should they implement?

Accepted Answer

Create a log-based metric counting error logs and set an alerting policy in Cloud Monitoring. The requirement is to be notified when the error rate exceeds 1% of total requests, which requires a metric that counts error logs relative to total requests. A log-based metric in Cloud Logging can filter for error log entries (e.g., status codes 5xx), and an alerting policy in Cloud Monitoring can trigger when the ratio of error logs to total requests surpasses 1%. This directly addresses the intermittent error rate condition with precise threshold-based alerting.

Answer

Create an uptime check pointing to the application endpoint

Answer

Use Cloud Trace to analyze latency and set an alert on trace spans

Answer

Create a dashboard showing error count over time

Question 9

A DevOps team is setting up SLOs for a service with two critical metrics: availability and latency. They want to measure over a 30-day window. Which approach correctly defines an SLO?

Accepted Answer

Use Cloud Monitoring to create a custom SLI based on request latency metrics and set an SLO with a 30-day rolling window. It uses Cloud Monitoring to create a custom SLI based on request latency metrics, which is a valid SLI type, and sets an SLO with a 30-day rolling window, matching the requirement. Cloud Monitoring's SLO feature natively supports rolling windows, and latency is a standard metric for defining service-level objectives.

Answer

Use Cloud Monitoring to create a custom SLI based on logs and set an SLO with a 7-day rolling window

Answer

Use Cloud Tasks to schedule a cron job that calculates availability

Answer

Use Stackdriver Monitoring (deprecated) to set an SLO with a fixed 30-day window

Question 10

You need to monitor the health of an external HTTP endpoint. Which resource should you create?

Accepted Answer

Uptime check in Cloud Monitoring. To monitor the health of an external HTTP endpoint, you need a service that can reach the endpoint from outside your VPC and provide alerting and visibility. Cloud Monitoring's Uptime Check is specifically designed for this purpose: it verifies that an external HTTP(S) endpoint is reachable and responsive, and can trigger alerting policies based on the results. This is the correct resource because it operates from Google's infrastructure, not from within your project, and directly supports external endpoint monitoring.

Answer

Load balancer with a health probe

Answer

Internal health check in Compute Engine

Answer

Cloud Logging log-based metric

Question 11

Your team wants to create a dashboard that shows request latency broken down by API version. Which approach is most efficient?

Accepted Answer

Use Cloud Monitoring Metrics Explorer to query the latency metric, group by API version, and save the chart as a dashboard. Cloud Monitoring Metrics Explorer allows you to directly query the latency metric (e.g., `request_latencies`) and group by the `version` label, then save the resulting chart as a dashboard widget. This is the most efficient approach because it requires no data export, no custom code, and no additional services — the metric is already available in Cloud Monitoring if your API is instrumented with the appropriate label.

Answer

Write a custom application to output metrics to a file and send to Cloud Monitoring

Answer

Export Cloud Logging logs to BigQuery and create a dashboard in Data Studio

Answer

Enable Cloud Trace and create a dashboard based on trace data

Question 12

A service is deployed on Cloud Run. You need to monitor memory usage per revision. How can you create an alert?

Accepted Answer

Configure Cloud Run to send metrics to Cloud Monitoring and create an alert in Cloud Monitoring. Cloud Run automatically exports built-in metrics, including memory usage per revision, to Cloud Monitoring without any additional configuration. By creating an alerting policy in Cloud Monitoring based on the `run.googleapis.com/container/memory/utilizations` metric, you can monitor memory usage per revision directly. Option B correctly identifies this native integration, making it the most efficient and reliable approach.

Answer

Deploy a sidecar container that collects memory metrics and pushes to Cloud Monitoring

Answer

Use Cloud Console and navigate to Cloud Run services to set an alert directly

Answer

Use Cloud Logging to parse container logs for memory usage

Question 13

Which service provides built-in dashboards for Google Cloud services?

Accepted Answer

Cloud Monitoring. Cloud Monitoring (option D) provides built-in dashboards for Google Cloud services, offering pre-configured visualizations of metrics, logs, and alerts without requiring manual setup. These dashboards aggregate data from services like Compute Engine, Cloud SQL, and Kubernetes Engine, enabling real-time monitoring of resource utilization and performance. This aligns with the PCDOE domain of implementing service monitoring strategies by providing out-of-the-box observability.

Answer

Cloud Shell

Answer

Cloud Console

Answer

Cloud Logging

Question 14

You want to send alerts to a Slack channel when a critical error occurs. What should you do?

Accepted Answer

Configure a Slack webhook notification channel in Cloud Monitoring and associate it with an alerting policy. Cloud Monitoring alerting policies can directly send notifications to Slack via a configured webhook notification channel. When a critical error triggers the alerting policy, Cloud Monitoring sends an HTTP POST request to the Slack webhook URL, delivering the alert message to the specified Slack channel. This is the native, event-driven approach without requiring custom code or intermediate services.

Answer

Set up a webhook in Cloud Logging and point it to Slack

Answer

Use Cloud Tasks to schedule a job that queries logs and sends Slack messages

Answer

Create a Cloud Logging export to Pub/Sub and subscribe using a Cloud Function that sends to Slack

Question 15

A team wants to implement multi-cluster monitoring for GKE using Managed Service for Prometheus. Which configuration is required?

Accepted Answer

Enable Managed Service for Prometheus in each cluster and configure a single Cloud Monitoring workspace to collect metrics from all clusters. Managed Service for Prometheus is a Google Cloud-managed, multi-cluster monitoring solution. To collect metrics from multiple GKE clusters, you must enable the service in each cluster individually and then configure a single Cloud Monitoring workspace to aggregate the data. This ensures each cluster runs its own collection pipeline, while the workspace provides a unified view across all clusters.

Answer

Enable Managed Service for Prometheus in one cluster and have other clusters forward metrics to it

Answer

Use Cloud Monitoring agent on nodes in each cluster

Answer

Set up a separate workspace per cluster