Operations, Observability, Reliability, and Cost

Google Cloud PCA — Section 9

Operations, Observability, Reliability, and Cost

Goal: recognize how Google Cloud monitors workloads, troubleshoots incidents, controls cost, manages quotas, and designs for reliable operations. For PCA, the angle is usually not “what button do I click?” It is “what should the architect recommend to meet reliability, cost, and operational requirements?”

Fast Decision Matrix

Service Deep Dives

Cloud Monitoring

Why an org uses it: Cloud Monitoring is the core metrics, dashboarding, uptime-check, and alerting service. It lets operations teams see whether applications and infrastructure are healthy across Google Cloud and, in many designs, external environments.

PCA trigger: Pick Cloud Monitoring when the scenario says metrics, dashboards, alerting, uptime checks, SLO monitoring, service health from a workload perspective, or operational visibility.

Common trap: Monitoring is not where you store and search raw application logs. That is Cloud Logging. Monitoring can alert on metrics and log-based metrics, but it is not the log archive by itself.

Cloud Logging

Why an org uses it: Cloud Logging centralizes platform, audit, application, and custom logs. Organizations use it to troubleshoot incidents, retain operational evidence, create log-based metrics, and route logs for analytics or compliance.

PCA trigger: Pick Cloud Logging when the requirement says collect/search logs, analyze logs, retain logs, route logs, create log-based alerts, or export logs to BigQuery, Cloud Storage, or Pub/Sub.

Common trap: Do not use Logging as a metrics dashboarding answer. For charts, uptime checks, and SLO alerts, use Cloud Monitoring.

Log sinks, log buckets, and log-based metrics

Why an org uses it: Log sinks and buckets give teams control over retention, destination, and compliance posture. Log-based metrics let teams turn specific log patterns into metrics that can drive alerts.

PCA trigger: Pick log sinks when the question says export logs to BigQuery for analysis, Cloud Storage for long-term retention, Pub/Sub/SIEM for real-time processing, or a centralized logging project.

Common trap: Do not keep every log forever in the default bucket. PCA questions often reward routing the right logs to the right destination for cost and retention.

Cloud Trace

Why an org uses it: Cloud Trace tracks request latency through distributed systems. It helps engineering teams understand which service, dependency, or network hop is causing slow requests.

PCA trigger: Pick Trace when the scenario says microservices latency, distributed request path, end-to-end request timing, or finding the slow service in a chain.

Common trap: Trace is not general logging. It is specifically about request timing and latency across services.

Cloud Profiler

Why an org uses it: Cloud Profiler continuously analyzes application CPU and memory usage so teams can find inefficient code paths. It is useful when applications are expensive or slow and the issue is inside the code rather than infrastructure.

PCA trigger: Pick Profiler when the scenario says identify functions consuming excessive CPU/memory, optimize code performance, or reduce application resource cost.

Common trap: If the question asks “which service is causing latency,” choose Trace. If it asks “which function in the code is burning CPU,” choose Profiler.

Error Reporting

Why an org uses it: Error Reporting groups application exceptions so teams do not drown in repeated stack traces. It helps prioritize crashes and understand whether an error is new, recurring, or increasing.

PCA trigger: Pick Error Reporting when the scenario says aggregate exceptions, group errors, track crashes, or identify recurring application failures.

Common trap: Error Reporting is not a replacement for full log search. It is a focused view for application errors derived from logs.

Managed Service for Prometheus

Why an org uses it: Managed Service for Prometheus lets teams use Prometheus-compatible monitoring without self-managing a large Prometheus backend. It is especially useful for GKE and Kubernetes teams that already rely on PromQL and exporters.

PCA trigger: Pick it when the requirement says Prometheus-compatible, PromQL, Kubernetes metrics, GKE metrics, or reduce the operational burden of running Prometheus.

Common trap: Do not choose self-managed Prometheus when the requirement favors managed operations, scale, and lower SRE overhead.

Cloud Audit Logs

Why an org uses it: Cloud Audit Logs records who did what, when, and against which resource. It supports security investigations, compliance evidence, change tracking, and forensic analysis.

PCA trigger: Pick Audit Logs when the scenario says admin activity, data access, system events, compliance evidence, or investigate changes to resources.

Common trap: Audit Logs are about control-plane and access events. They are not the same as application logs emitted by your code.

Cloud Service Health

Why an org uses it: Cloud Service Health helps organizations understand Google Cloud service incidents and whether known provider events may affect their projects or regions.

PCA trigger: Pick Service Health when the question is about Google Cloud service incidents, disruptions, personalized service-impact visibility, or confirming whether an outage is provider-side.

Common trap: Service Health does not monitor your application’s custom health. Use Monitoring, uptime checks, and SLOs for your workload.

Recommender and Active Assist

Why an org uses it: Recommender and Active Assist analyze resource usage and configuration to produce optimization recommendations. Organizations use them for cost savings, rightsizing, security hardening, reliability improvements, and operational hygiene.

PCA trigger: Pick Recommender/Active Assist when the scenario says identify idle resources, rightsizing, cost optimization recommendations, security recommendations, performance recommendations, or automated optimization insights.

Common trap: Recommendations still need review. The PCA answer is rarely “blindly auto-apply everything”; it is usually evaluate recommendations against business context and change control.

Cloud Billing

Why an org uses it: Cloud Billing helps teams track spend, allocate costs, view reports, export billing data, and understand cost trends across projects and billing accounts.

PCA trigger: Pick Cloud Billing when the scenario says cost visibility, billing reports, spend allocation, chargeback/showback, billing export, or understand cost trends.

Common trap: Billing reports explain and allocate spend; budgets alert on thresholds; Recommender suggests optimizations. They are related but not the same answer.

Budgets and alerts

Why an org uses it: Budgets and alerts notify teams when spend approaches or exceeds expected amounts. With Pub/Sub notifications, organizations can automate cost-control workflows.

PCA trigger: Pick budgets when the requirement says alert when costs exceed threshold, notify finance, trigger Pub/Sub on budget event, or prevent surprise spend.

Common trap: Budgets are not hard service limits by default. Disabling billing can stop resources, but that is a blunt action and often not the best enterprise control.

Pricing Calculator

Why an org uses it: The Pricing Calculator helps architects estimate cost before deployment, migration, or major architecture changes. It is useful for comparing designs and communicating expected spend to stakeholders.

PCA trigger: Pick Pricing Calculator when the scenario says estimate monthly cost, compare architecture options, or build a migration business case.

Common trap: It is an estimate, not a live cost-control or optimization service. For live spend, use Cloud Billing and budgets.

Cloud Quotas

Why an org uses it: Cloud Quotas helps teams monitor service limits, request increases, and prevent capacity failures. Quotas protect shared infrastructure but can block scaling if not planned.

PCA trigger: Pick Cloud Quotas when the scenario says deployment fails due to limits, plan for traffic growth, increase regional capacity, monitor quota usage, or avoid quota exhaustion.

Common trap: Quotas are not security permissions. IAM controls who can use resources; quotas control how much of a resource/API can be used.

Gemini Cloud Assist

Why an org uses it: Gemini Cloud Assist provides AI-assisted help for cloud operations, troubleshooting, optimization, and recommendations in Google Cloud. It is likely to appear as a newer operations-assistance topic rather than a core monitoring replacement.

PCA trigger: Know it when scenarios mention AI-assisted cloud operations, troubleshooting support, guided recommendations, or accelerating operational workflows.

Common trap: Do not replace core monitoring, logging, alerting, and SRE practices with Gemini Cloud Assist. Think of it as assistance layered on top of operational data.

SLOs, SLIs, and alerting strategy

Why an org uses it: SLOs turn reliability into measurable targets and help teams alert on user-impacting symptoms rather than every low-level signal. SLIs measure the service behavior, and error budgets help balance reliability work against feature velocity.

PCA trigger: Pick SLO/SLI design when the scenario says reliability target, error budget, user-facing availability/latency, alert fatigue, or measure whether a service is healthy.

Common trap: Do not alert on everything. PCA favors alerts tied to user impact, SLO burn, and actionable events.

Backup, recovery, and disaster recovery design

Why an org uses it: Backup and DR planning protects the organization from data loss, regional failure, accidental deletion, and business interruption. Architects use RTO and RPO to choose the right redundancy and recovery design.

PCA trigger: Pick DR/recovery design when the scenario says RTO, RPO, business continuity, regional outage, data loss, restore testing, or failover planning.

Common trap: High availability is not the same thing as backup. Multi-zone redundancy might keep a service running, but it may not protect against data corruption or accidental deletion.

Testing, benchmarking, and operational validation

Why an org uses it: Load testing, performance benchmarking, failure testing, chaos engineering, recovery testing, and penetration testing validate that architecture assumptions are true before production incidents prove them false.

PCA trigger: Pick testing/validation when the scenario asks how to prove scale, validate failover, confirm recovery procedures, test security posture, or prepare for launch.

Common trap: Do not assume managed services remove the need to test. PCA often rewards validating the design under realistic failure and load conditions.

Well-Architected operational excellence

Why an org uses it: Operational excellence is about deploying, operating, monitoring, managing, and continuously improving workloads. It ties together observability, release discipline, incident response, postmortems, runbooks, and automation.

PCA trigger: Pick operational excellence concepts when the scenario asks for process improvement, reduce operational toil, improve incident response, standardize runbooks, automate operations, or mature cloud operations.

Common trap: Do not solve every operations problem with a product. Sometimes the PCA answer is process: SLOs, runbooks, postmortems, release controls, and stakeholder alignment.

Common PCA Comparison Patterns

Architecture Patterns to Recognize

• Centralized logging: use aggregated sinks from project/folder/org level to route logs into a security or operations project.

• Compliance retention: route selected logs to Cloud Storage or long-retention log buckets instead of keeping everything in default retention.

• Real-time security/event processing: route logs to Pub/Sub so a SIEM, SOAR, or custom pipeline can consume them.

• SLO-based alerting: define SLIs for availability, latency, and error rate; alert on burn rate or user impact instead of noisy host metrics alone.

• Kubernetes observability: use Cloud Monitoring/Logging plus Managed Service for Prometheus when teams need PromQL and exporter-based metrics.

• Cost governance: combine billing exports/reports, budgets, labels/tags, Recommender, and FinOps processes for showback/chargeback.

• Capacity planning: check quotas and request increases before a major launch, migration, or regional scale-up.

• Reliable operations: define runbooks, incident response, postmortems, rollback plans, and regular recovery testing.

Common PCA Traps

• Choosing Cloud Logging when the actual requirement is metrics, dashboards, alerting, or SLO monitoring.

• Choosing Cloud Monitoring when the requirement is long-term log retention or exporting logs to BigQuery, Cloud Storage, Pub/Sub, or a SIEM.

• Treating Cloud Service Health as application monitoring. It is about Google Cloud service-impact events, not your app’s custom health checks.

• Thinking budgets are hard spend limits. They are primarily alerts and notifications unless you build automation around them.

• Ignoring quota planning before a launch or migration. Quota exhaustion can look like an architecture failure even when the design is otherwise fine.

• Confusing high availability with backup or disaster recovery. They solve different failure modes.

• Alerting on every technical signal instead of user-impacting symptoms and SLO burn. PCA favors actionable alerts.

• Skipping operational validation. Load tests, failover tests, restore tests, and postmortems are part of architecture quality.

Cram Summary

• Cloud Monitoring = metrics, dashboards, uptime checks, SLOs, and alerting.

• Cloud Logging = logs, retention, search, log-based metrics, and routing/export.

• Cloud Trace = distributed request latency.

• Cloud Profiler = code-level CPU/memory hotspots.

• Error Reporting = grouped application exceptions.

• Managed Service for Prometheus = managed Prometheus-compatible metrics for Kubernetes/GKE teams.

• Cloud Audit Logs = who did what, when, and where.

• Cloud Service Health = Google Cloud provider/service incidents and impact visibility.

• Recommender / Active Assist = automated optimization insights across cost, security, performance, reliability, and management.

• Cloud Billing = live spend reporting and cost allocation. Budgets = threshold alerts. Pricing Calculator = estimates.

• Cloud Quotas = resource/API limits and scaling guardrails.

• SLOs/SLIs = measurable reliability targets; alert on user impact and error-budget burn.

• Backup, HA, and DR are related but not interchangeable.

• Operational excellence is not just tooling. It includes runbooks, automation, incident response, testing, postmortems, and continuous improvement.

Sources Checked

Google Professional Cloud Architect exam guidance; Google Cloud Observability docs for Monitoring, Logging, Trace, Profiler, Error Reporting, and Managed Service for Prometheus; Cloud Billing, Budgets, Recommender/Active Assist, Cloud Quotas, Service Health, Gemini Cloud Assist, and Well-Architected Framework reliability/operational excellence guidance.