PCDOE Implementing service monitoring strategies Practice Test 5 — 15 Questions

Question 1

Which THREE are recommended practices for setting up alerting on Google Cloud?

Accepted Answer

Set alert thresholds with a buffer (e.g., below SLO). Setting alert thresholds with a buffer below the SLO (e.g., alert at 99.9% when SLO is 99.99%) provides early warning before the SLO is breached. This proactive approach allows time for investigation and remediation, preventing actual SLO violations and ensuring service reliability targets are met.

Answer

Use multiple conditions with OR combiner to cover all scenarios

Answer

Use a single alerting policy for all services

Question 2

Which TWO metrics should be monitored to detect a potential memory leak in a Compute Engine VM?

Accepted Answer

Process count. A memory leak causes processes to consume increasing amounts of memory without releasing it, leading to a growing process count as new instances of the leaking process are spawned or existing processes remain active. Monitoring the process count helps detect abnormal growth that correlates with memory exhaustion. Option C is correct because memory usage percentage directly reflects how much of the VM's available RAM is consumed; a steady upward trend without a corresponding increase in workload indicates a leak.

Answer

CPU utilization

Answer

Disk read IOPS

Answer

Network bytes sent

Question 3

What is the effect of the 'timeshiftDuration' of '3600s' in the dashboard widget?

Accepted Answer

The chart compares current data to data from 1 hour ago. The 'timeshiftDuration' parameter in a dashboard widget shifts the time range of the comparison data relative to the primary time range. Setting 'timeshiftDuration' to '3600s' means the chart compares the current data (within the selected time range) against data from exactly 1 hour (3600 seconds) earlier. This is commonly used for offset comparisons, such as week-over-week or hour-over-hour analysis, and does not alter the primary data range or aggregation.

Answer

The chart shows data from the last 1 hour

Answer

The metric is aggregated over 1 hour

Answer

The dashboard updates every hour

Question 4

Which Cloud Monitoring feature can directly correlate this error with the associated trace and VM instance?

Accepted Answer

Error Reporting. Error Reporting in Google Cloud automatically groups errors from Cloud Logging and can directly correlate an error with the associated trace ID and VM instance metadata. This is because Error Reporting ingests structured log entries that contain the `@type` field set to `type.googleapis.com/google.devtools.clouderrorreporting.v1beta1.ReportedErrorEvent` and parses the `serviceContext` and `context` fields to link the error to the specific trace and resource (e.g., VM instance).

Answer

Log-based metrics

Answer

Metrics Explorer

Answer

Alerting policies

Question 5

Your company runs a multi-region application on GKE across us-east1 and europe-west1. The application serves a global user base with a strict SLO of 99.95% availability. Recently, the team noticed that during peak hours, some users in South America experience high latency and intermittent errors. The GKE clusters are monitored via Cloud Monitoring with custom dashboards and alerting policies. The team has set up a single alerting policy that triggers when the global error rate exceeds 0.1%. However, the alert fires only after the issue has persisted for 10 minutes, and by then the customer impact is already significant. You need to improve the detection and response time. Which action should you take first?

Accepted Answer

Create separate alerting policies per region with shorter evaluation periods, and set up a notification channel for the on-call team.. The current single global alerting policy with a 10-minute evaluation period introduces a significant delay in detecting regional issues. By creating separate alerting policies per region with shorter evaluation periods, you can detect and respond to regional anomalies (like high latency in South America) much faster, directly improving the detection time for the multi-region application and reducing customer impact.

Answer

Add a dashboard that shows latency by region and set up a log-based metric for error counting.

Answer

Reduce the alerting policy's duration to 1 minute and increase the threshold to 0.5% to reduce noise.

Answer

Implement a canary deployment strategy to roll back changes quickly.

Question 6

A team is using Cloud Monitoring to track the performance of a microservices application. They set up an uptime check for each service, but they notice that some checks are failing intermittently without actual service degradation. What is the most likely cause?

Accepted Answer

The timeout setting is too short for the service's typical latency.. The most likely cause is that the timeout setting is too short, causing false positives when the service response time temporarily exceeds the timeout. Other options are less plausible: uptime checks typically run from multiple regions; load balancer 503 errors would indicate a real issue; quota exceed would prevent checks from running.

Answer

The services are behind a load balancer that occasionally returns 503 during scaling.

Answer

Uptime checks are deployed in a single region, causing false positives.

Answer

The project's quota for uptime checks has been exceeded.

Question 7

A company wants to monitor custom application metrics in real-time and trigger alerts when a metric exceeds a threshold. Which Google Cloud service should they use?

Accepted Answer

Cloud Monitoring. Cloud Monitoring (formerly Stackdriver Monitoring) is the correct service because it is designed to ingest custom application metrics via the Monitoring API or OpenTelemetry, create dashboards for real-time visualization, and configure alerting policies that trigger notifications when a metric exceeds a defined threshold. This directly meets the requirement for real-time monitoring and threshold-based alerts.

Answer

Cloud Audit Logs

Answer

Cloud Logging

Answer

Cloud Error Reporting

Question 8

An organization is implementing SLO-based alerting for a critical service. They want to alert when the service has consumed 50% of its error budget over a 30-day window. Considering best practices for alert sensitivity and noise reduction, which alerting approach should they use?

Accepted Answer

Alert on the burn rate over a 1-hour window with a threshold of 10.. A burn rate of 10 over a 1-hour window indicates that the service is consuming error budget at a rate that would exhaust the entire 30-day budget in 3 days (30 days / 10 = 3 days). Therefore, 50% of the budget would be consumed in 1.5 days, not 1.5 hours. This approach balances sensitivity and noise reduction by using a sufficiently long window (1 hour) to smooth out transient spikes, while the high threshold ensures only significant sustained degradation triggers an alert, aligning with SRE best practices for multi-window, multi-burn-rate alerting.

Answer

Alert on the burn rate over a 5-minute window with a threshold of 0.5.

Answer

Alert on the error budget remaining with a threshold of 50%.

Answer

Alert on the SLI value directly with a threshold of 99.9%.

Question 9

A DevSecOps team is configuring Cloud Monitoring alerts for proactive incident response. Which two practices are recommended for effective alerting? (Choose two.)

Accepted Answer

Define clear escalation paths for different alert severities.. Recommended practices include defining clear escalation paths for different severities and creating separate alerts for different symptom classes to reduce noise and ensure proper routing.

Answer

Alert on every microsecond of latency increase.

Answer

Use a single high-level alert that covers all symptoms.

Answer

Set alert thresholds based on arbitrary guesses.

Question 10

A team is designing a dashboard for their production environment using Cloud Monitoring. Which three types of information should be included on the dashboard to support incident response? (Choose three.)

Accepted Answer

Resource utilization trends. Resource utilization trends (A) are essential for incident response because they provide historical context, enabling responders to identify anomalies, correlate changes with incidents, and predict capacity issues. Cloud Monitoring's Metrics Explorer and dashboards allow you to plot trends over time, which is critical for root cause analysis during an active incident.

Answer

Real-time user feedback

Answer

Security audit logs

Question 11

Your company runs a stateless web application on Google Kubernetes Engine (GKE). You have configured Cloud Monitoring to track request latency and set up an alert when p95 latency exceeds 500ms for 5 minutes. Recently, the alert has been firing frequently during peak hours. You examine the metrics and see that p95 latency spikes to 600ms for short periods. The application's SLO is 99.9% availability with a latency threshold of 1 second. What should you do to reduce alert noise without compromising the SLO?

Accepted Answer

Implement a multi-window burn-rate alerting approach.. The best approach is to implement a multi-window burn-rate alerting strategy, which is less sensitive to short spikes and directly tracks error budget consumption, aligning with the SLO.

Answer

Disable the alert during peak hours.

Answer

Increase the alert threshold to 1 second to match the SLO.

Answer

Change the alert to use a longer evaluation window, e.g., 30 minutes.

Question 12

Your organization is migrating a monolithic application to microservices on Cloud Run. You need to monitor the health of each microservice and aggregate logs and metrics in a central dashboard. You have set up Cloud Monitoring custom dashboards and logs-based metrics. After the initial deployment, you notice that the dashboards show data only for some services, while others appear to have no metrics. You verify that all services are running and emitting logs. What is the most likely cause?

Accepted Answer

The services are running in different GCP projects and you are viewing only one project.. Cloud Monitoring dashboards and logs-based metrics are scoped to a single GCP project. If microservices are deployed across multiple projects, metrics from services in other projects will not appear unless the dashboard is configured to aggregate data from all relevant projects. Since the question states that some services have no metrics while all are running and emitting logs, the most likely cause is that those services reside in different projects.

Answer

The services are not exporting metrics to Cloud Monitoring via the Monitoring API.

Answer

The logs-based metrics are not configured to parse logs from all services.

Answer

The Cloud Monitoring agent is not installed on the Cloud Run instances.

Question 13

You are the DevOps engineer for a large gaming company. Your game backend runs on Compute Engine instances behind a global HTTP(S) Load Balancer. You have set up Cloud Monitoring with an uptime check for the load balancer's IP address, and you are using logging to capture 404 errors. Recently, a new game update caused a surge in traffic, and you started receiving many alerts from your uptime check indicating that the site is down. However, you verify that the backend instances are healthy and the load balancer is responding correctly, though some requests are timing out due to the increased load. Your alerting policy currently triggers when 2 consecutive checks fail. What is the most likely reason for the false positive alerts?

Accepted Answer

The uptime check's timeout is too short for the current response times.. The uptime check's timeout is too short for the current response times. When a surge in traffic causes some requests to time out, the load balancer may still respond correctly to most requests, but the uptime check—which has a fixed timeout (default 10 seconds)—fails if the response does not arrive within that window. Since the alert triggers after 2 consecutive failures, the check falsely reports the site as down even though the backend and load balancer are healthy.

Answer

The global load balancer's health check is failing due to the surge.

Answer

The monitoring project has reached its limit for concurrent uptime checks.

Answer

The uptime check is configured to check a specific URL that is returning a 503 status code.

Question 14

A small startup uses Cloud Functions for their backend and wants to monitor function execution times and error rates. They have enabled Cloud Monitoring and are viewing metrics in the Cloud Console. They notice that the execution time metric for a particular function shows an average of 200ms, but occasionally there are spikes to 5 seconds, which correspond to user-reported slow responses. They want to be alerted when the function exceeds 1 second for any invocation. What is the simplest way to achieve this?

Accepted Answer

Use the built-in Cloud Functions latency metric and create a metric threshold alert for the max value over 1 minute.. Cloud Functions automatically emits a built-in `execution_time` metric (measured in milliseconds) to Cloud Monitoring. By creating a metric threshold alert on the `max` value of this metric over a 1-minute window, you can trigger an alert whenever any single invocation exceeds 1 second, directly matching the requirement to be alerted per invocation spike.

Answer

Create a log-based metric for function duration and set a threshold alert.

Answer

Configure a Cloud Monitoring uptime check for the function URL.

Answer

Use Cloud Error Reporting to capture slow responses.

Question 15

Your company runs a multi-region application on Google Kubernetes Engine. You have implemented Cloud Monitoring dashboards to track cluster resource utilization and application SLIs. After a recent upgrade, you notice that the dashboard shows a sudden drop in CPU utilization for all nodes in one zone, but the application is still serving traffic normally. You suspect a monitoring issue. What should you investigate first?

Accepted Answer

Check if the Kubernetes Metrics Server is running correctly in that zone.. The Kubernetes Metrics Server is responsible for collecting resource metrics from Kubelets and exposing them via the Metrics API, which Cloud Monitoring uses to display CPU utilization. A sudden drop in CPU utilization across all nodes in a single zone, while the application continues to serve traffic normally, strongly indicates that the Metrics Server in that zone has failed or is not reporting metrics, rather than an actual change in workload. Investigating the Metrics Server's health and logs is the correct first step to confirm whether the monitoring pipeline is broken.

Answer

Check if the nodes in that zone have been cordoned.

Answer

Check if the application's resource requests and limits have changed.

Answer

Check if the Cloud Monitoring agent has been updated incorrectly.