PCD Managing application performance monitoring Practice Test 2 — 15 Questions

Question 1

A development team is using Cloud Monitoring to set up an alerting policy for a Compute Engine instance. They want to be notified when the instance's CPU utilization exceeds 80% for at least 5 minutes. Which alerting policy configuration should they use?

Accepted Answer

Condition type: Metric Threshold, Trigger: For 5 minutes, Threshold: 80%. Option A is correct because Cloud Monitoring alerting policies use a Metric Threshold condition type to evaluate a metric against a static threshold. Setting the trigger to 'For 5 minutes' ensures the condition is met only when the CPU utilization exceeds 80% consistently over the specified duration, preventing false alarms from transient spikes.

Answer

Condition type: Metric Threshold, Trigger: For most recent value, Threshold: 80%

Answer

Condition type: Change Rate, Trigger: For 5 minutes, Threshold: 80%

Answer

Condition type: Metric Absence, Duration: 5 minutes

Question 2

Based on the Cloud Trace exhibit, which service is the primary contributor to the overall request latency?

Accepted Answer

The auth service. The Cloud Trace exhibit shows that the auth service accounts for the largest segment of the overall request latency, as indicated by the longest span duration in the trace waterfall. In Google Cloud Trace, each span represents a service's contribution to the total latency, and the service with the highest cumulative span time is the primary contributor. Since the auth service span is the longest, it is the correct answer.

Answer

The productcatalog service

Answer

The frontend service itself

Answer

The recommendations service

Question 3

You are configuring a Cloud Monitoring alerting policy for a Cloud Run service. The service has a maximum of 10 concurrent requests per instance. You want to be alerted when the average number of concurrent requests per instance exceeds 8 for at least 1 minute. Which metric and condition type should you use?

Accepted Answer

Metric: run.googleapis.com/request_count, Condition type: Metric Threshold, Threshold: >8. Option A is correct because the `run.googleapis.com/request_count` metric tracks the number of concurrent requests per instance, which directly matches the requirement. A Metric Threshold condition with a threshold of >8 triggers an alert when the average exceeds 8 for at least 1 minute, aligning with the specified criteria.

Answer

Metric: run.googleapis.com/request_count, Condition type: Metric Absence, Duration: 1 min

Answer

Metric: resource/container/cpu/utilization, Condition type: Metric Threshold, Threshold: >80%

Answer

Metric: run.googleapis.com/request_count, Condition type: Change Rate, Threshold: >0.5

Question 4

You are designing a monitoring strategy for a microservices architecture running on GKE. Each service emits custom business metrics (e.g., order processing time). You want to create a dashboard that shows the 99th percentile latency for each service over the last 7 days. Which approach should you take?

Accepted Answer

Write custom metrics to Cloud Monitoring and create a dashboard with the 99th percentile aligner.. Option B is correct because Cloud Monitoring supports custom metrics and provides built-in aligners, including a 99th percentile aligner, which can be applied directly in a dashboard chart. This allows you to compute the 99th percentile latency for each service over the last 7 days without manual calculation or exporting logs. Custom metrics are the appropriate mechanism for business metrics like order processing time, as they are designed for numeric time-series data.

Answer

Export logs to Cloud Logging and use Log Analytics to compute percentiles.

Answer

Use Metrics Explorer to view the metrics and manually compute percentiles.

Answer

Use Prometheus monitoring built into GKE and query the avg() function.

Question 5

Which TWO actions are best practices for managing application performance monitoring in Google Cloud?

Accepted Answer

Set appropriate sampling rates for Cloud Trace to balance cost and insight.. Option A is correct because Cloud Trace charges based on the number of spans ingested and retained. Setting an appropriate sampling rate (e.g., 1 in 10 requests for high-traffic services) reduces cost while still providing statistically significant latency data for performance analysis. This balances the need for actionable insights against budget constraints.

Answer

Enable debug logging in production to capture detailed errors.

Answer

Log all application activity at INFO level for complete visibility.

Answer

Configure alerts to send emails to the entire development team.

Question 6

Which THREE components are essential for a complete application performance monitoring (APM) solution on Google Cloud?

Accepted Answer

Cloud Monitoring for metrics and alerting.. Cloud Monitoring is essential for an APM solution because it provides metrics, dashboards, and alerting policies to track application health and performance. It integrates with other services like Cloud Trace and Cloud Logging to offer a unified observability platform, enabling proactive detection of issues such as latency spikes or error rate increases.

Answer

Cloud Scheduler for job scheduling.

Answer

Cloud CDN for content caching.

Question 7

Your Cloud Run service is experiencing 5xx errors. You have enabled Cloud Logging and Cloud Error Reporting. How can you quickly identify the most common error type?

Accepted Answer

Open Cloud Error Reporting to see grouped error counts.. Cloud Error Reporting automatically groups similar errors (e.g., same stack trace or error message) and shows a count for each group, making it the fastest way to identify the most common 5xx error type without manual log inspection. It is purpose-built for this exact use case, aggregating errors from Cloud Logging and presenting them in a dashboard sorted by frequency.

Answer

Use Cloud Trace to analyze the traces of failing requests.

Answer

View the logs in Cloud Logging and manually count error messages.

Answer

Create a Cloud Monitoring alert on 5xx response codes.

Question 8

You are managing a microservices application deployed on Google Kubernetes Engine (GKE) that uses Cloud Monitoring and Cloud Logging. Recently, users have reported intermittent slow response times, especially during peak hours. You have enabled the Ops Agent on GKE nodes and configured custom metrics for your services. The application consists of a frontend service, a backend API service, and a database service. The frontend calls the backend, which in turn queries the database. You notice that when the response time spikes, the frontend service's CPU utilization remains low, but the backend service's CPU utilization increases. The database service shows normal latency and no errors. You have examined the logs and found no application errors. The GKE cluster has three node pools: one for each service, with autoscaling enabled. The backend service is configured with a HorizontalPodAutoscaler (HPA) based on CPU utilization, but the HPA does not seem to scale up quickly enough during traffic spikes. You want to identify the root cause of the performance degradation. Which course of action should you take first?

Accepted Answer

Analyze the backend service's request latency distribution using Cloud Monitoring metrics to identify whether the issue is due to increased request volume or slow request processing.. Option B is correct because the intermittent slow response times during peak hours, combined with low frontend CPU but high backend CPU and normal database latency, strongly suggest the backend service is struggling to process requests quickly under load. Analyzing the backend's request latency distribution using Cloud Monitoring metrics (e.g., 99th percentile latency) will reveal whether the issue stems from increased request volume (which would show a shift in latency distribution) or from individual requests taking longer to process (e.g., due to inefficient code or resource contention). This diagnostic step directly addresses the symptom without making assumptions about scaling or network issues.

Answer

Check the network latency between the frontend and backend services using Cloud Monitoring's network metrics.

Answer

Configure the backend service's HPA to use custom metrics based on request latency instead of CPU utilization.

Answer

Increase the minimum number of replicas for the backend service to handle peak traffic.

Question 9

A company is running a microservices application on Google Kubernetes Engine (GKE). They have implemented Cloud Monitoring and Cloud Logging, but recently they noticed that the Istio-proxy sidecar logs are missing from Cloud Logging. The application pods are running correctly and the sidecar containers are present. What is the most likely cause of the missing logs?

Accepted Answer

The cluster was not created with the Istio on GKE add-on enabled, so proxy logs are not automatically collected.. Option B is correct because when using Istio on GKE, the Istio-proxy sidecar logs are automatically collected and sent to Cloud Logging only if the cluster was created with the 'Istio on GKE' add-on enabled. Without this add-on, the sidecar logs are not automatically forwarded, even though the sidecar containers are present and the application pods are running correctly. The add-on configures the necessary logging pipeline for Istio telemetry and logs.

Answer

The Istio-proxy logs are being sent to Stackdriver but are filtered by a log sink exclusion.

Answer

The Cloud Logging agent is not installed on the cluster nodes.

Answer

The sidecar container is not configured to output logs to stdout/stderr.

Question 10

A DevOps team wants to set up custom metrics for a serverless application running on Cloud Run. The application emits metrics using OpenTelemetry. They need to collect these metrics and create an alerting policy that triggers when the 99th percentile latency exceeds 500ms for 5 minutes. Which TWO actions must they take? (Choose two.)

Accepted Answer

Create a custom distribution metric for the latency data and set up a metric threshold alert using the 99th percentile value.. Option A is correct because to alert on the 99th percentile of latency, you must create a custom distribution metric, which stores a histogram of values and allows percentile calculations. A metric-threshold alert policy can then be configured to evaluate the 99th percentile value against the 500ms threshold over a 5-minute window.

Answer

Install the Cloud Monitoring agent on the Cloud Run instance to collect custom metrics.

Answer

Define a log-based metric from the application logs that captures latency entries.

Answer

Configure the Cloud Monitoring dashboard to query the metrics using PromQL.

Question 11

Your company runs a production App Engine standard environment service (module 'frontend', version 'v2') that handles e-commerce checkout requests. You have set up an alerting policy on a custom metric 'request_latency' that fires when latency exceeds 500ms for 1 minute. Recently, customers have complained about slow checkout times, but no alert has fired. You examine the exhibit: the log entry shows a latency of 0.452s (452ms) for a request to '/api/checkout'. The custom metric is defined from OpenTelemetry instrumentation. What is the most likely reason the alert did not fire?

Accepted Answer

The alert threshold is 500ms, and the exhibited request latency is 452ms, which is below the threshold. Individual requests may be below the threshold, so the alert does not fire.. Option C is correct because the alerting policy is configured to fire when the custom metric 'request_latency' exceeds 500ms for 1 minute. The exhibited log entry shows a latency of 452ms, which is below the 500ms threshold. The alert condition is based on a metric threshold, not individual log entries, and since the metric value remains below the threshold, the alert does not trigger.

Answer

The alert condition uses a threshold on a metric that is not being written because the OpenTelemetry exporter is not configured for the 'frontend' module.

Answer

The log entry does not contain the required custom metric data because the httpRequest field is not parsed by Cloud Monitoring.

Answer

The custom metric is only emitted for version 'v1', and the current version is 'v2', so no metric data is available for the alert.

Question 12

Drag and drop the steps to configure a Cloud Storage bucket with uniform bucket-level access in the correct order.

Question 13

Drag and drop the steps to grant a service account access to a Cloud Storage bucket in the correct order.

Question 14

Match each Cloud Logging and Monitoring concept to its definition.

Question 15

Match each error code to its meaning in Google Cloud.