PCA - Professional Cloud Architect Cheat Sheet

The Google Cloud Professional Cloud Architect (PCA) exam validates your ability to design, develop, and manage robust, secure, scalable, and cost-effective solutions on Google Cloud that drive business objectives. It is a scenario-heavy exam organized around six areas, weighted from solution design and planning (the largest, at roughly 25%) through provisioning, security and compliance, process optimization, implementation, and operations excellence. Unlike a pure product-recall test, it grades architectural judgment: given a business and technical context, you must choose the trade-off Google's Well-Architected Framework would endorse, not merely an option that works. This sheet maps every exam area to the concrete Google Cloud services, patterns, and decision cues you need to reason like an architect under exam conditions.

What This Cheat Sheet Covers

This topic spans 41 focused tables and 470 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Business Requirements and Solution StrategyTable 2: Cost Optimization on Google CloudTable 3: Business Continuity and Disaster RecoveryTable 4: High Availability, Scalability and Performance DesignTable 5: Google Cloud Well-Architected Framework and Operational ExcellenceTable 6: Cloud Migration PlanningTable 7: VPC Design and Network SegmentationTable 8: Private Connectivity and Service AccessTable 9: Cloud Load BalancingTable 10: Hybrid and Multicloud ConnectivityTable 11: Network Security and ProtectionTable 12: Choosing Compute PlatformsTable 13: Compute Engine and Machine TypesTable 14: GKE and Container OrchestrationTable 15: Serverless Computing on Google CloudTable 16: Infrastructure Orchestration and Specialized ComputeTable 17: Choosing Storage Types: Object, File and BlockTable 18: Choosing Database ServicesTable 19: Data Processing and AnalyticsTable 20: Data Lifecycle, Transfer and ProtectionTable 21: API Management and Integration PatternsTable 22: Vertex AI ML WorkflowsTable 23: AI Hypercomputer and AcceleratorsTable 24: Google Cloud AI APIs and Generative AITable 25: Identity and Access ManagementTable 26: Resource Hierarchy and Organization PolicyTable 27: Data Security, Encryption and Key ManagementTable 28: Security Controls and AuditingTable 29: Secure Access and Software Supply ChainTable 30: Securing AI WorkloadsTable 31: Regulatory Compliance and Data PrivacyTable 32: Industry Certifications and Audit LoggingTable 33: SDLC, CI/CD and Service CatalogTable 34: Troubleshooting, Testing and ValidationTable 35: Business Processes and Change ManagementTable 36: Google Cloud SDK, CLI and Programmatic AccessTable 37: Infrastructure as Code with TerraformTable 38: Cloud Observability: Monitoring and LoggingTable 39: Reliability, SLOs and AlertingTable 40: Deployment and Release ManagementTable 41: Production Support and Quality Control

Table 1: Business Requirements and Solution Strategy

PCA Exam Section 1.1 / 1.5: designing a cloud solution that meets business requirements and envisioning future improvements. These concepts turn business goals into measurable technical requirements, choose how each workload moves to the cloud, and weigh the trade-offs Google's Well-Architected Framework asks an architect to balance.

Concept	Example	Description
Non-Functional Requirements (NFRs)	`"99.99% availability, p95 latency < 200ms"` are NFRs; `"users can reset a password"` is functional	The quality attributes (the "-ilities") a system must meet: availability, performance, security, cost, operational efficiency. • Define HOW WELL the system works, not WHAT it does • NFRs drive the architecture, so capture them early
Functional Requirements	`Add item to cart`, `process a payment`, `email a receipt`	The specific behaviors and features the system must perform. Not to be confused with NFRs: functional = what it does, non-functional = how well it does it. Both belong in an architecture decision record.
Workload Disposition (the migration R's)	`Legacy VM, no change needed → Rehost` `Move to GKE containers → Replatform`	Six strategies for moving each workload: rehost, replatform, refactor, re-architect, rebuild, repurchase. Choose per workload by business value vs effort, not one strategy for everything.
Rehost (Lift and Shift)	`Move a VM as-is to Compute Engine`	Move a workload with minor or no changes. Fastest, lowest effort, reuses existing skills. Trade-off: does not gain cloud-native benefits like horizontal scalability or managed services.
Replatform (Lift and Optimize)	`Self-hosted PostgreSQL → Cloud SQL`	Lift the workload then make targeted optimizations for the cloud (containers, managed DB). More effort than rehost, but gains elasticity, redundancy, and performance. Sits between rehost and refactor.
Refactor / Re-architect	`Break a monolith into microservices on Cloud Run`	Re-engineer the code to be cloud-native. Refactor improves the code; re-architect changes how it functions. Highest effort and risk, but unlocks scalability and removes technical debt.
Repurchase	`On-prem email → Google Workspace (SaaS)`	Replace a purchased on-premises product with a cloud-hosted SaaS equivalent. Low resourcing effort. Trade-off: can cost more and you lose granular control of the environment.
Well-Architected Framework Pillars	`Add a 2nd region → reliability up, cost up`	Six pillars covering the non-functional focus areas: operational excellence, security, reliability, cost optimization, performance, sustainability. Architecture is a balance of trade-offs across them.
Design Trade-offs (ADR)	`Pub/Sub vs Cloud Tasks → record the why in an ADR`	An architecture decision record captures the options, the requirements driving the choice, and the accepted decision. Designs trade reliability, cost, performance, and complexity; there is rarely one universally best answer.
Service Level Objective (SLO)	`SLO = 99.95% availability over 30 days`	A precise numerical target for a non-functional attribute. Set it to the lowest reliability users actually need, since more reliability costs more. Measured by an SLI; an SLA is the external promise.

Table 1: Business Requirements and Solution Strategy

Concept	Example	Description
Non-Functional Requirements (NFRs)	`"99.99% availability, p95 latency < 200ms"` are NFRs; `"users can reset a password"` is functional	The quality attributes (the "-ilities") a system must meet: availability, performance, security, cost, operational efficiency. • Define HOW WELL the system works, not WHAT it does • NFRs drive the architecture, so capture them early
Functional Requirements	`Add item to cart`, `process a payment`, `email a receipt`	The specific behaviors and features the system must perform. Not to be confused with NFRs: functional = what it does, non-functional = how well it does it. Both belong in an architecture decision record.
Workload Disposition (the migration R's)	`Legacy VM, no change needed → Rehost` `Move to GKE containers → Replatform`	Six strategies for moving each workload: rehost, replatform, refactor, re-architect, rebuild, repurchase. Choose per workload by business value vs effort, not one strategy for everything.
Rehost (Lift and Shift)	`Move a VM as-is to Compute Engine`	Move a workload with minor or no changes. Fastest, lowest effort, reuses existing skills. Trade-off: does not gain cloud-native benefits like horizontal scalability or managed services.
Replatform (Lift and Optimize)	`Self-hosted PostgreSQL → Cloud SQL`	Lift the workload then make targeted optimizations for the cloud (containers, managed DB). More effort than rehost, but gains elasticity, redundancy, and performance. Sits between rehost and refactor.
Refactor / Re-architect	`Break a monolith into microservices on Cloud Run`	Re-engineer the code to be cloud-native. Refactor improves the code; re-architect changes how it functions. Highest effort and risk, but unlocks scalability and removes technical debt.
Repurchase	`On-prem email → Google Workspace (SaaS)`	Replace a purchased on-premises product with a cloud-hosted SaaS equivalent. Low resourcing effort. Trade-off: can cost more and you lose granular control of the environment.
Well-Architected Framework Pillars	`Add a 2nd region → reliability up, cost up`	Six pillars covering the non-functional focus areas: operational excellence, security, reliability, cost optimization, performance, sustainability. Architecture is a balance of trade-offs across them.
Design Trade-offs (ADR)	`Pub/Sub vs Cloud Tasks → record the why in an ADR`	An architecture decision record captures the options, the requirements driving the choice, and the accepted decision. Designs trade reliability, cost, performance, and complexity; there is rarely one universally best answer.
Service Level Objective (SLO)	`SLO = 99.95% availability over 30 days`	A precise numerical target for a non-functional attribute. Set it to the lowest reliability users actually need, since more reliability costs more. Measured by an SLI; an SLA is the external promise.