Try each one before opening the answer. Every option is explained, with the Google Cloud documentation page that proves it.
Question 1 · choose 2
Refer to the EHR Healthcare case study. EHR Healthcare wants centralized visibility into the performance of systems spread across many projects, and it wants to fix the problem that alerts are sent by email and often ignored. Which TWO actions should the architect take? (Choose TWO.)
AAdd the application projects to the metrics scope of one central monitoring project
BRaise the thresholds of the existing alerts so that fewer of them are sent
CCreate a log-based alert for each ERROR entry that the services write
DBuild a separate monitoring dashboard in each project for its own team
EAlert on the burn rate of service level objectives instead of on single error events
Show the answer and why
AAdd the application projects to the metrics scope of one central monitoring project
Correct
A metrics scope lets one scoping project chart and monitor time-series data from many projects in one place.
BRaise the thresholds of the existing alerts so that fewer of them are sent
Incorrect
Higher thresholds cut the volume by hiding problems, and the alerts still track raw values rather than the impact on users.
CCreate a log-based alert for each ERROR entry that the services write
Incorrect
Alerting on every error floods responders and repeats the alert fatigue problem.
DBuild a separate monitoring dashboard in each project for its own team
Incorrect
Per-project dashboards keep visibility fragmented instead of centralized.
EAlert on the burn rate of service level objectives instead of on single error events
Correct
Burn-rate alerts fire when the error budget is being spent fast enough to threaten the SLO, so there are fewer alerts and each one matters.
Centralized visibility comes from a shared metrics scope; alerts that people act on come from fewer, symptom-based alerts tied to the SLOs that users feel, instead of one alert per error.
A Go service on GKE uses far more CPU in production than in load tests, and the team cannot reproduce the behavior elsewhere. It wants to see which functions consume the CPU under real traffic, with low overhead. Which tool should the architect recommend?
ACloud Profiler, profiling the service continuously in production
BCloud Trace, sampling the requests that reach the service in production
CLog-based metrics that count the service's request logs
DUptime checks against the service's health endpoint
Show the answer and why
ACloud Profiler, profiling the service continuously in production
Correct
Continuous profiling of production systems shows where CPU and memory are consumed in the code, which test environments often fail to reproduce.
BCloud Trace, sampling the requests that reach the service in production
Incorrect
Tracing shows the latency of requests across services, not which functions use CPU.
CLog-based metrics that count the service's request logs
Incorrect
Counting log entries shows volume, not where CPU time goes in the code.
DUptime checks against the service's health endpoint
Incorrect
Uptime checks test availability, not resource use inside the code.
Profiling and benchmarking are part of observability in the guide. Cloud Profiler gives code-level resource usage from production with low overhead.
An application runs on Compute Engine VMs. The operations team can see CPU and network metrics in Cloud Monitoring but not memory or disk usage, and the application's log files never reach Cloud Logging. What should the architect recommend?
ATurn on VPC Flow Logs for the subnet where the application's VMs run
BInstall the Ops Agent on the VMs and configure its log receivers
CEnable Data Access audit logs for Compute Engine
DCreate uptime checks against each VM's IP address
Show the answer and why
ATurn on VPC Flow Logs for the subnet where the application's VMs run
Incorrect
Flow logs record network flows, not memory, disk or application logs.
BInstall the Ops Agent on the VMs and configure its log receivers
Correct
The Ops Agent collects logs, metrics and traces from Compute Engine instances in one process, including system metrics such as memory.
CEnable Data Access audit logs for Compute Engine
Incorrect
Audit logs record API calls about resources, not what happens inside the VMs.
DCreate uptime checks against each VM's IP address
Incorrect
Uptime checks test reachability from outside, not inside resource usage.
Monitoring and logging of VMs requires an agent for in-guest telemetry. The Ops Agent is Google's agent for that job.
Refer to the Altostrat Media case study. Altostrat monitors its GKE clusters and on-premises systems with open source Prometheus alongside Cloud Monitoring. It wants to keep its PromQL queries and Grafana dashboards but stop operating Prometheus servers at scale, and see metrics from all environments in one place. What should the architect recommend?
AGoogle Cloud Managed Service for Prometheus
BSelf-managed Prometheus federation on a VM
COps Agent on every node, with PromQL removed
DLog-based metrics built from container logs
Show the answer and why
AGoogle Cloud Managed Service for Prometheus
Correct
It is a managed, multi-cloud, cross-project Prometheus service that collects from exporters and lets teams keep querying with PromQL and Grafana.
BSelf-managed Prometheus federation on a VM
Incorrect
Federation still leaves Altostrat running and scaling Prometheus servers itself.
COps Agent on every node, with PromQL removed
Incorrect
Dropping PromQL breaks the dashboards and queries Altostrat wants to keep.
DLog-based metrics built from container logs
Incorrect
Turning logs into metrics loses the existing Prometheus metrics and queries.
Observability across hybrid environments is easier with a managed backend that speaks the tools teams already use, which here means Prometheus and PromQL.
A public website runs on Cloud Run behind a global load balancer. The team wants to know quickly when users anywhere in the world cannot reach the site, even if no request reaches the service at all. What should the architect configure?
AA log-based alert on HTTP 500 errors written to the service's request logs
BA Cloud Trace sampling rate of 100% on the Cloud Run service
CA public uptime check from several locations with an alerting policy
DAn alert on the Cloud Run service's container CPU utilization
Show the answer and why
AA log-based alert on HTTP 500 errors written to the service's request logs
Incorrect
If requests never arrive, no error logs are written, so this alert stays silent.
BA Cloud Trace sampling rate of 100% on the Cloud Run service
Incorrect
Tracing records requests that arrive; it does not test reachability from outside.
CA public uptime check from several locations with an alerting policy
Correct
Public uptime checks send periodic requests from locations around the world and can alert when the target stops responding.
DAn alert on the Cloud Run service's container CPU utilization
Incorrect
CPU use says nothing about whether users can reach the site.
Alerting strategies should include black-box checks from the user's side, since internal signals go quiet when traffic cannot reach the service.