Implementing service monitoring strategies practice questions

The Cloud Monitoring agent is not installed or not reporting on the instance, so the memory metric is missing.

Why wrong: This is incorrect. If the Cloud Monitoring agent were not installed, memory metrics would also be unavailable, so the memory alert would not fire either. The fact that memory alert fired indicates the agent is present.

The memory alert has a higher threshold value, making it easier to trigger.

Why wrong: Incorrect. A higher threshold makes triggering less likely, not more. The memory alert having a higher threshold would make it harder to trigger, but it fired, so this is not the reason.

The CPU metric is not available because the instance does not have the Cloud Monitoring agent installed.

Why wrong: Incorrect. As with option A, if the CPU metric were unavailable due to agent issues, memory metrics would also be missing. The memory alert firing indicates the agent is working.

The alert fires after 300 seconds of sustained CPU utilization above 80% with a count of 1.

Why wrong: The count of 1 means one time series must satisfy, but duration is the continuous time. This is partially correct but misleading.

The alert fires if CPU utilization averaged over 5 minutes exceeds 80%.

Why wrong: The alignment period is 60s, but duration is a separate continuous check, not an average.

The alert fires if CPU utilization is above 80% for any 5-minute window in the last hour.

Why wrong: Duration does not define a sliding window; it is a fixed period during which condition must hold continuously.

The pods are crashing and restarting frequently.

Why wrong: Restarts would cause 503s but less likely than readiness probe failures.

The Prometheus scrape interval is too long, causing missed metrics.

Why wrong: Prometheus scraping does not affect pod availability.

The container resource limits are set too low, causing out-of-memory errors.

Why wrong: OOM errors cause restarts, not directly 503s.

Use a gauge metric with the max alignment function in a Metrics Explorer chart.

Why wrong: Gauge metrics do not support percentiles.

Use an uptime check metric and configure the latency percentile in the chart.

Why wrong: Uptime checks measure availability, not service latency.

Create a logs-based metric from application logs and use the count alignment.

Why wrong: Logs-based metrics are for counts, not latency percentiles.

VPC flow logs

Why wrong: VPC flow logs show packet-level traffic, not health check results.

Cloud Audit Logs (Admin Activity)

Why wrong: Audit logs track administrative actions, not health checks.

Instance serial port output logs

Why wrong: Serial port logs show OS-level boot and console messages.

Create a log-based metric for errors and use a condition with a threshold, then set the alert policy to only run during business hours using the 'condition' schedule.

Why wrong: Alert policies do not have a built-in schedule for conditions.

Create two separate alert policies, one for business hours and one for off-hours, each with different thresholds.

Why wrong: This would require manual management and not a single policy.

Use Cloud Scheduler to enable and disable the alerting policy at the start and end of business hours.

Why wrong: Cloud Scheduler cannot enable/disable alert policies directly.

The health check is configured to use port 80 instead of port 8080.

Why wrong: The question says port 8080 is configured.

The instance's DNS resolution is failing, causing the health check to use the wrong IP.

Why wrong: Health checks use the internal IP, not DNS.

The health check response timeout is set too low (e.g., 1 second).

Why wrong: Default timeout is 5 seconds, usually enough.

Set static alert thresholds without considering historical baselines.

Why wrong: Thresholds should be based on baselines, not static values.

Use the USE method (Utilization, Saturation, Errors) for service-level monitoring.

Why wrong: USE is for resource monitoring, not services.

Alert on cause-based metrics (e.g., CPU utilization) rather than symptom-based metrics (e.g., latency).

Why wrong: Alert on symptoms, not causes.

Use the built-in JMX plugin in the Cloud Monitoring agent to collect Java application metrics.

Why wrong: Cloud Monitoring agent does not have a JMX plugin.

The instance's disk is full, causing write errors.

Why wrong: No disk-related message is present.

The instance failed to authenticate with the metadata server.

Why wrong: The log shows a connection timeout, not an authentication failure.

A health check probe failed to reach the instance.

Why wrong: Health check failures are logged in load balancer logs, not as instance logs.

The kubernetes_sd_configs role is set to 'pod' but should be 'endpoints'.

Why wrong: Role 'pod' is correct for scraping pods directly.

Prometheus needs to be configured to listen on port 9090 for scraping.

Why wrong: Prometheus listens on 9090 for its UI, not for scraping; scraping uses the target port.

The keep action for the label 'my-app' is filtering out all pods.

Why wrong: If the label is correct, pods are kept.

Service Monitoring to create a custom dashboard

Why wrong: Service Monitoring focuses on SLOs and service-level dashboards, not log-level root cause analysis.

Error Reporting to automatically group error occurrences

Why wrong: Error Reporting summarizes errors but may not provide the granularity of gRPC status codes.

Metrics Explorer to view error rate and latency charts

Why wrong: Metrics Explorer shows aggregated metrics, not individual log entries needed for detailed error analysis.

Use Cloud Logging to search for deployment logs and manually compare with latency metrics

Why wrong: Manual comparison is time-consuming and error-prone; a dashboard provides a unified view.

Use Cloud Trace to analyze latency distributions for each deployment version

Why wrong: Cloud Trace is for distributed tracing, not for correlating deployments with latency trends over time.

Configure Error Reporting to alert on latency threshold breaches

Why wrong: Error Reporting handles application errors, not latency metrics.

Alert on CPU utilization greater than 80% for the instance running the job

Why wrong: CPU utilization may be high even after the job completes, or low during the job, leading to false negatives.

Use a heartbeat metric that reports every 5 minutes; alert if no heartbeat for 90 minutes

Why wrong: No heartbeat for 90 minutes indicates a failure, not that the job is still running.

Set up a log-based metric that counts job completion log entries; alert if the count is zero after 90 minutes

Why wrong: A log-based metric counting completion entries cannot detect a running job because it only evaluates log data after the job finishes; if the count is zero after 90 minutes, the job may still be running or may have failed without logging completion. This option is tempting because it directly monitors job completion events, which would be correct if the requirement were to verify that the job finished at all, rather than to detect ongoing execution within a time window.

Disk read IOPS per pod

Why wrong: Disk IOPS is important for stateful workloads but not a general performance indicator for all workloads.

Number of nodes in the cluster

Why wrong: Node count is an infrastructure metric; it doesn't directly measure workload performance.

Network bytes received per second

Why wrong: Network throughput is not a direct measure of performance degradation; it may vary with traffic.

Use Cloud Trace to analyze distributed traces for the checkout service and look for retry spans

Why wrong: Trace analysis can confirm retries but is more time-consuming than using metrics.

Check the 'Services' dashboard in Cloud Monitoring, which shows a pre-built latency chart for all services

Why wrong: The default dashboard may not include retry metrics, so it won't confirm the hypothesis.

Use Logs Explorer to search for logs containing 'retry' in the checkout service namespace

Why wrong: Retry logs may not be generated by default; they require explicit Istio logging configuration.

Increase the max instances per revision in Cloud Run to handle more concurrent requests

Why wrong: Increasing Cloud Run instances could increase load on the already stressed database, worsening the issue.

Reduce the min instances of Cloud Run to decrease load on the database

Why wrong: Reducing instances may cause cold starts and does not address the root cause of database overload.

Add a Cloud SQL read replica and route read queries to it

Why wrong: The endpoint causing 503 errors likely involves writes; read replicas won't reduce write load.

Set up a log-based metric for 5xx responses and create an alert on the metric.

Why wrong: Log-based metrics have ingestion latency, often exceeding 1 minute, and may not meet the sub-minute alert requirement.

Create a Cloud Logging sink to a Pub/Sub topic and trigger a Cloud Function that sends notifications.

Why wrong: This approach relies on Cloud Logging's export latency, which can be several minutes, and does not provide a rate-based condition.

Use Cloud Monitoring's log-based alerting to trigger on every 5xx log entry.

Why wrong: Alerting on every log entry can cause alert fatigue and does not allow for a rate condition like exceeding 1%.

Rely solely on synthetic monitoring to measure user experience.

Why wrong: Synthetic monitoring does not capture real user behavior and should be combined with real user monitoring.

Use multiple monitoring tools to cover all aspects of the system.

Why wrong: Consolidating monitoring into a single tool reduces complexity and improves consistency.

Manually analyze logs and metrics to identify issues.

Why wrong: Manual analysis is inefficient; automation is key in cloud monitoring.

Create VPC networks in both projects, then create peering from A to B, then create peering from B to A, then configure firewall rules, then verify.

Why wrong: This is incorrect because firewall rules should be configured before peering is created to allow initial traffic; otherwise, the peering may be established but traffic could be blocked.

Create VPC networks in both projects, then create peering from A to B, then configure firewall rules, then verify.

Why wrong: This is incorrect because it omits creating the reverse peering from Project B to Project A, which is required for bidirectional communication.

Configure firewall rules, then create VPC networks in both projects, then create peering from A to B, then create peering from B to A, then verify.

Why wrong: This is incorrect because VPC networks must exist before firewall rules can be applied; you cannot configure firewall rules for networks that do not exist.