13.4 Diagnostics, Ops Agent, Managed Service for Prometheus & Audit Logs

Why This Topic Matters on the Exam

This section closes out Domain 4's monitoring-and-logging cluster with the remaining official bullets: using cloud diagnostics to research an application issue, checking Google Cloud's own status, deploying the Ops Agent, deploying Managed Service for Prometheus, and configuring audit logs. These are the "which tool do I reach for" questions — the exam wants you to know which of several overlapping-sounding tools applies to a described troubleshooting or configuration task.

Cloud Diagnostics: The Full Toolkit

When an application issue is reported, ACE expects you to know which observability tool answers which question, together forming what Google calls the Cloud Operations Suite (the modern name for the former "Stackdriver" umbrella):

A realistic diagnostic workflow: an alert fires (Cloud Monitoring) → the engineer opens Logs Explorer to find matching error entries → Error Reporting shows the same exception has spiked across 40 instances in the last hour → Cloud Trace reveals the slow calls are all waiting on one downstream service → Cloud Profiler confirms that downstream service is CPU-bound on a specific function. Exam questions rarely require you to use all five in one scenario, but they do expect you to pick the one correct tool for a specific symptom (e.g., "recurring exceptions grouped automatically" → Error Reporting, not raw Logs Explorer).

Viewing Google Cloud Status

Before spending time debugging your own configuration, the exam expects you to know that status.cloud.google.com (the Google Cloud Status Dashboard) shows current and historical incidents, broken down by product and by region. A described scenario like "multiple teams across different projects report the same GKE control-plane symptom starting at the same time in the same region" is testing whether you'd check the status dashboard first, before assuming it's a misconfiguration in your own project.

Ops Agent

The Ops Agent is the modern, unified agent for Compute Engine VMs (and other environments, including on-premises and other clouds), replacing the older, separate Monitoring agent and Logging agent combination. Installing one Ops Agent per VM gets you:

• Metrics — system metrics (CPU, memory, disk, network) plus application metrics, including scraping Prometheus-format exporters running on the VM.
• Logs — application and system log collection, forwarded into Cloud Logging.
• Process metrics — per-process resource usage.

Configuration is a single YAML file (config.yaml) defining receivers (where data comes from), processors (transformations), and pipelines (wiring receivers to destinations) — one pipeline structure for logging, one for metrics. Deployment options scale from a manual install, to a VM startup script, to an Ops Agent policy applied fleet-wide across many VMs at once (the preferred approach for managing dozens or hundreds of VMs consistently).

Managed Service for Prometheus

Google Cloud Managed Service for Prometheus is a fully managed, Prometheus-compatible metrics service built on Monarch, the same globally scalable backend that powers Cloud Monitoring. This means Prometheus-collected metrics and Cloud Monitoring's own ~6,500+ built-in metrics can be queried together with PromQL, across projects, without running and scaling your own Prometheus servers.

Two collection modes matter for the exam:

• Managed collection — recommended for GKE: a Kubernetes operator automatically deploys, scales, and manages the collectors for you.
• Self-deployed collection — you run the Managed Service for Prometheus binary yourself as a drop-in Prometheus replacement, useful when you need full control over the deployment (e.g., non-GKE compute) or are migrating an existing self-managed Prometheus setup.

The Ops Agent (on Compute Engine VMs) and the OpenTelemetry Collector (vendor-neutral, cross-cloud) are the two additional supported collection paths, rounding out four total ways to feed Managed Service for Prometheus.

Exam distinction: if a scenario describes "collecting Prometheus metrics from a GKE cluster with minimal operational overhead," the answer is managed collection via the Kubernetes operator — not manually deploying the Ops Agent (which targets Compute Engine VMs, not GKE Pods) and not standing up a self-managed Prometheus server.

Configuring Audit Logs

Audit logs were introduced from a security framing in Domain 5, but configuring them is itself an operational task tested here. Recall the four audit log types:

Configuring audit logs operationally means enabling Data Access logs where needed, via the IAM Audit Config — set at the organization, folder, or project level, or scoped to individual services, and further scoped by permission type (ADMIN_READ, DATA_READ, DATA_WRITE), with the option to exempt specific principals from generating entries.

Critical exam trap: Data Access logs are not retroactive. If a compliance investigation needs to know who read the contents of a specific Cloud Storage object last week, and Data Access logging was never enabled for Cloud Storage, that read history cannot be recovered after the fact — the audit config must have been turned on before the events occurred. This is one of the most commonly tested "gotcha" points connecting Domain 4's operational configuration to Domain 5's security requirements.

Section Takeaways

• Cloud Monitoring, Logging, Error Reporting, Trace, and Profiler each answer a different diagnostic question — match the described symptom to the right tool.
• Check status.cloud.google.com before assuming a widespread symptom is a misconfiguration in your own project.
• The Ops Agent unifies metrics (including Prometheus scraping) and log collection on Compute Engine VMs in one agent, configured via a single YAML file, and is best deployed fleet-wide via an Ops Agent policy.
• Managed Service for Prometheus runs on Monarch and supports PromQL across Prometheus and native Cloud Monitoring metrics; use managed collection for GKE and self-deployed collection when you need full control or are migrating existing Prometheus setups.
• Admin Activity, System Event, and Policy Denied audit logs are always on; Data Access logs are opt-in (except BigQuery) and are never retroactive — enabling them after an incident cannot recover missing history.