Operational Excellence — GCP Professional Cloud Architect (PCA)
Signal Type Determines the Correct Observability Tool
Architecture requirement: identify the root cause of an operational issue. Competing choices: Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler. The deciding constraint is the telemetry type the symptom produces. Cross-service request latency resolves to Cloud Trace. CPU or memory hot paths within a single process resolve to Cloud Profiler. Structured log search and export resolve to Cloud Logging. Infrastructure metrics and alert policies resolve to Cloud Monitoring. Error Reporting groups unhandled exceptions. No single tool covers all signal types — the scenario's symptom description is the selector.
What This Pattern Tests
The exam describes an operational challenge and tests whether you apply automation over manual intervention. Infrastructure as code (CloudFormation, CDK) makes deployments repeatable and auditable. Systems Manager provides patch management, parameter store, and runbook automation across EC2 fleets. CloudWatch composite alarms combine multiple metrics into single operational alerts. The trap is recommending manual processes — SSH into servers to check logs, manually apply patches, hand-edit configuration files. The exam rewards automated, auditable, repeatable operations.
Decision Axis
Reactive manual intervention vs. proactive automation. The exam always prefers automation that is auditable and repeatable.
Associated Traps
More Top Traps on This Exam
Decision Rules
When inter-service p99 latency spikes with no error rate change, the correct observability layer is distributed trace correlation (Cloud Trace) not structured log search (Cloud Logging), because only trace span data reconstructs the full call graph and exposes the slowest hop automatically.
When a p99 latency regression spans a multi-service call chain with no corresponding error rate change, the architect must select Cloud Trace — which correlates distributed spans across all six service boundaries and ranks hops by latency contribution — rather than Cloud Logging, which cannot reconstruct the cross-service timing graph without manual trace-header joins and yields no ranked latency breakdown by hop.
When the diagnostic question is 'which code path within a single service is consuming excess CPU,' Cloud Profiler is required because it provides flame-graph attribution at the function level; Cloud Monitoring can confirm that CPU is elevated but cannot attribute utilization to a specific call site, making it the wrong tool for causal, code-scoped root-cause analysis.
Domain Coverage
Difficulty Breakdown