Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Cloud Logging log-based alerts that detect 5xx errors in application logs.

  Why it's wrong here

  Cloud Logging log-based alerts that trigger on 5xx errors in application logs only detect failures after a request reaches your application backend and wrote a log entry. If the failure occurs before application code runs—such as DNS resolution failure, an unreachable network path, a downed load balancer, or a misconfigured CDN—no 5xx log will be produced, so the alert will never fire. Log-based alerts also depend on the logging pipeline itself, which may be unavailable or delayed, and they lack the external, synthetic perspective needed to confirm whether your endpoint is truly accessible to users.

• ✓

  Cloud Monitoring uptime checks that probe endpoints from global locations with alerting on failure.

  Why this is correct

  Cloud Monitoring uptime checks are a managed, synthetic monitoring solution that sends HTTP, HTTPS, or TCP probe requests to your endpoints from multiple global points of presence (PoPs) at configurable intervals. Alerting policies can be triggered when a configurable number of locations report failure, which verifies external availability from the user's perspective, not just internal health. This is the correct choice because it is a deliberately designed, low-maintenance service for exactly this use case, requiring no custom infrastructure and providing global coverage by default.

• ✗

  Cloud Trace that records response times for each user request.

  Why it's wrong here

  Cloud Trace is a distributed tracing service that captures latency data from real user requests as they travel through services, allowing analysis of per-request response times and bottlenecks. It is not a synthetic monitoring tool: if there are no real users, it records nothing, so it cannot proactively detect outages or degradation before users are impacted. Moreover, its focus is on performance profiling and debugging request paths, not on verifying endpoint accessibility or triggering availability alerts based on external probe failures.

• ✗

  Custom scripts on Compute Engine VMs that ping endpoints every minute.

  Why it's wrong here

  Running custom scripts on Compute Engine VMs to ping endpoints every minute creates a single-point-of-failure monitoring system: the monitoring VM itself can crash, be restarted, or be disconnected, and you will not know. It also offers no global vantage points, so you miss region-specific routing problems, and it requires ongoing maintenance for updates and lifecycle management. Furthermore, raw ICMP pings merely test network reachability, not the actual application response (e.g., HTTP status, content), and integrating alerting requires building custom Cloud Monitoring metric ingestion rather than using the native alerting policies.

Go deeper

Related to this question