Instiq
Chapter 4 · Ensuring successful operation of a cloud solution·v1.0.0·Updated 6/16/2026·~14 min

What's changed: Created Associate Cloud Engineer Chapter 4 (Domain 4 "Operating": operating compute/storage/networking = snapshots/images/GKE node pools-autoscaling/Cloud Run traffic splitting/object lifecycle/DB backup/subnet expansion/static IPs/Cloud DNS/Cloud NAT; monitoring and logging = Cloud Monitoring (metrics/alerts/custom metrics)/Ops Agent/Managed Service for Prometheus/Cloud Logging (log router/export)/audit logs).

4.2Monitoring and logging

Key points

Understand operational observability: metrics, alerts, and custom metrics with Cloud Monitoring; viewing/filtering logs, log buckets and log routers, and external export with Cloud Logging; deploying the Ops Agent and Managed Service for Prometheus; and audit logs and checking Google Cloud status.

Stable operations require observability—knowing "what is happening now." Google Cloud Observability centers on Cloud Monitoring (metrics) and Cloud Logging (logs).

4.2.1Cloud Monitoring

Cloud Monitoring monitors metrics like CPU, latency, and availability, and notifies via alerts when thresholds are crossed. App-specific metrics can be ingested as custom metrics. To collect detailed VM metrics and logs, deploy the Ops Agent; for Prometheus-style monitoring, use Managed Service for Prometheus. Map "monitor resource state numerically and notify = Cloud Monitoring (alerts)."

4.2.2Cloud Logging and audit logs

Cloud Logging collects and stores logs and lets you view and filter them in the console for investigation. Logs are stored in log buckets, routed by the log router, and can be exported to BigQuery, Cloud Storage, or Pub/Sub. Cloud Audit Logs record "who did what and when" for security investigation and compliance. During incidents: "detect anomalies via metrics (Monitoring) → trace causes via logs (Logging)," and "check Google Cloud status for broad outages."

Exam point

Common: requirement → service. E.g., "monitor metrics and alert at thresholds" = Cloud Monitoring (alerts); "app-specific metrics" = custom metrics; "collect detailed VM metrics/logs" = Ops Agent; "search logs to find causes" = Cloud Logging; "export logs to BigQuery, etc." = log router export; "who did what" = audit logs; "check broad outages" = Google Cloud status.

Warning

Watch the mix-ups: (1) separate Cloud Monitoring (metrics/alerts) from Cloud Logging (logs). (2) External log export goes via the log router. (3) Audit logs record actions (who did what)—different purpose from app debug logs.

Diagram: detect anomalies with Cloud Monitoring (metrics/alerts), then trace causes with Cloud Logging (logs/log router/audit logs).
From detection to root cause

4.2.3Section summary

  • Cloud Monitoring = metrics/alerts/custom metrics; collect via Ops Agent; Prometheus via Managed Service
  • Cloud Logging = view/filter, log buckets/router, export to BigQuery, etc.
  • Audit logs = who did what; incidents: detect via metrics → trace via logs; broad outages via Google Cloud status

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. To monitor metrics like CPU and latency and alert on threshold breaches, what do you use?

Q2. During an incident, to collect and search app logs to investigate causes, what do you use?

Q3. Which mechanism exports logs to external destinations like BigQuery or Cloud Storage?

Q4. Which records "who did what and when" for security investigation and compliance?

Q5. Which agent do you deploy to collect detailed metrics and logs from a VM?

Q6. When an entire service is unresponsive, what is appropriate to check first?

Check your understandingPractice questions for Chapter 4: Ensuring successful operation of a cloud solution

Keep track of your progress

The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.