Ensuring Successful Operation of a Cloud Solution
Observability stack
Cloud Monitoring handles metrics, dashboards, uptime checks, and alerting policies. Cloud Logging stores entries in log buckets. Error Reporting aggregates exceptions, Cloud Trace shows request latency, and Profiler shows CPU/heap for supported runtimes. Critically, default VM metrics cover only CPU, network, and disk I/O - memory, disk-space, and process metrics require the Ops Agent. That is a classic exam trap.
The logs pipeline
Entries flow from resources into log buckets (_Default, _Required) and can be routed by sinks. Aggregated sinks export to another project, BigQuery, Cloud Storage, or Pub/Sub; the destination must grant permission to the sink's writer identity. Exclusions drop entries before storage, while a sink with no filter exports everything - do not confuse the two. Log-based metrics turn log entries into counters or distributions you can alert on.
Audit logs
Admin Activity audit logs are always enabled and cannot be turned off. Data Access audit logs are disabled by default and, at volume, cost real money. Policy Denied logs record organization policy and VPC Service Controls denials.
Alerting and reliability
Alerting policies trigger on metric thresholds, absence of data, or log-based metrics, and route to notification channels (email, SMS, Pub/Sub, webhooks). Uptime checks probe HTTP/TCP from multiple regions. SLOs express reliability targets and can back burn-rate alerts.
Troubleshooting cues
403 = IAM or disabled API; 404 = wrong project or resource; quota errors = request an increase or redesign; SSH failures usually mean a missing firewall rule, no external IP, or IAP not configured.
Rule of thumb: for "why were we not alerted?" check three things in order - does the metric exist, does the policy condition match it, and is the notification channel wired to a human?