PCA — Google Cloud Professional Cloud Architect 2026 Quick Reference
Compact Google Cloud Professional Cloud Architect 2026 (PCA) architecture reference for service selection, security, reliability, networking, and exam decision points.
How to Use This Quick Reference
This independent Quick Reference supports candidates preparing for the Google Cloud Professional Cloud Architect 2026, exam code PCA. Use it to quickly map scenario requirements to Google Cloud services, architecture patterns, and exam decision points.
For PCA-style questions, read for:
- Business goal: reduce operations, improve availability, meet compliance, cut cost, modernize.
- Workload shape: stateless, stateful, batch, streaming, OLTP, analytics, ML, legacy.
- Constraints: latency, RTO/RPO, data residency, existing tooling, skills, portability.
- Managed-service fit: prefer managed/serverless when requirements allow.
- Security and governance: least privilege, centralized control, auditability, network boundaries.
- Tradeoff: cheapest is not always correct; most managed is not always correct.
Core PCA Architecture Heuristics
| If the scenario emphasizes… | Prefer… | Watch for traps |
|---|---|---|
| Minimal operations | Cloud Run, App Engine, Cloud SQL, BigQuery, Pub/Sub, managed services | Do not choose GKE/Compute Engine just because they are familiar |
| Existing VM app with OS dependencies | Compute Engine, managed instance groups, Migrate to Virtual Machines | Do not force serverless if custom kernel, agents, or stateful local dependencies are required |
| Container portability and Kubernetes ecosystem | GKE Autopilot or GKE Standard | Autopilot reduces ops; Standard gives more node-level control |
| Simple event-driven function | Cloud Run functions / Cloud Functions | For container control, concurrency, or portable runtime, use Cloud Run |
| Global relational consistency and scale | Cloud Spanner | Cloud SQL is simpler when a single-region relational database is enough |
| Analytics over large datasets | BigQuery | BigQuery is not an OLTP database |
| Streaming ingestion | Pub/Sub plus Dataflow | Pub/Sub alone is messaging, not transformation/analytics |
| Low-latency key/value or wide-column access | Bigtable | Not relational; not ad hoc SQL analytics |
| Centralized enterprise network | Shared VPC, Cloud Interconnect/VPN, Cloud Router, Network Connectivity Center | VPC peering is not transitive |
| Data exfiltration protection | VPC Service Controls, IAM, org policy, logging | VPC Service Controls do not replace IAM |
| Hybrid private connectivity | Cloud Interconnect or HA VPN | Cloud NAT is outbound only; it does not provide inbound access |
| Global web app | Global external Application Load Balancer, Cloud CDN, Cloud Armor | Regional LBs may be wrong for worldwide latency and failover |
| Cost control for batch/fault-tolerant compute | Spot VMs, autoscaling, managed services, lifecycle policies | Spot VMs can be interrupted; design for retry |
Service Selection: Compute
| Service | Choose when | Avoid when | PCA cues |
|---|---|---|---|
| Cloud Run | Stateless containerized services, APIs, webhooks, event consumers, scale-to-zero, low ops | Stateful workloads, deep VM control, specialized networking not supported by service | “Containerized app,” “serverless,” “variable traffic,” “reduce operations” |
| Cloud Run Jobs | Containerized batch jobs, scheduled tasks, finite work | Long-running services needing continuous serving | “Run a job,” “batch container,” “no server management” |
| Cloud Run functions / Cloud Functions | Lightweight event handlers, glue code, simple HTTP functions | Complex services, custom container needs, extensive runtime control | “Trigger on upload/message,” “small function” |
| App Engine Standard | Web apps with supported runtimes, automatic scaling, minimal infrastructure | Custom OS/packages, unsupported runtime, portability concerns | “Legacy App Engine,” “simple web app,” “PaaS” |
| App Engine Flexible | App Engine model with custom runtime/container-like flexibility | Need Kubernetes control or scale-to-zero economics | “Managed web app but custom runtime” |
| GKE Autopilot | Kubernetes workloads with reduced node management | Need detailed node, daemonset, privileged, or specialized control | “Kubernetes required,” “reduce cluster operations” |
| GKE Standard | Full Kubernetes control, custom node pools, GPUs, service mesh, complex networking | Team lacks Kubernetes skills; serverless fits better | “Kubernetes ecosystem,” “custom scheduling,” “platform team” |
| Compute Engine | Lift-and-shift, OS-level control, legacy apps, custom agents, specialized machines | App can be easily containerized/serverless | “VM-based,” “custom OS,” “existing licenses,” “stateful server” |
| Managed Instance Groups | Autoscaled/stateless VM fleets, rolling updates, self-healing | Single pets, unmanaged stateful VMs | “Autoscale VMs,” “self-healing,” “regional availability” |
| Batch | Large batch processing, parallel jobs, queue-based compute | Always-on web serving | “Batch workloads,” “parallel compute,” “jobs” |
| VMware Engine | VMware migration with minimal re-platforming | Cloud-native modernization is feasible and required | “Existing VMware,” “rapid data center exit” |
Compute Decision Path
flowchart TD
A[Workload to host] --> B{Needs OS or VM-level control?}
B -->|Yes| C[Compute Engine or MIG]
B -->|No| D{Requires Kubernetes APIs/ecosystem?}
D -->|Yes| E{Need node-level control?}
E -->|Yes| F[GKE Standard]
E -->|No| G[GKE Autopilot]
D -->|No| H{Containerized service or job?}
H -->|Service/API| I[Cloud Run]
H -->|Finite job| J[Cloud Run Jobs or Batch]
H -->|No, simple function| K[Cloud Run functions / Cloud Functions]
Service Selection: Storage and Databases
| Need | Best-fit services | Key distinction |
|---|---|---|
| Object storage | Cloud Storage | Durable object store for files, backups, static assets, data lakes |
| VM block storage | Persistent Disk / Hyperdisk | Attached to Compute Engine or GKE nodes; not object storage |
| Shared POSIX/NFS file system | Filestore | Managed NFS for apps requiring shared file semantics |
| Relational database, moderate scale | Cloud SQL | Managed MySQL, PostgreSQL, SQL Server; simpler than Spanner |
| PostgreSQL-compatible high performance | AlloyDB | Managed PostgreSQL-compatible option for demanding workloads |
| Global relational scale and strong consistency | Cloud Spanner | Distributed relational database; choose when Cloud SQL cannot meet scale/availability/global needs |
| Document database | Firestore | Serverless document model, mobile/web backends, flexible schema |
| Wide-column, low-latency high throughput | Bigtable | Time series, IoT, personalization, operational analytics; not relational |
| In-memory cache | Memorystore | Redis/Valkey-compatible cache layer; not durable primary system of record |
| Data warehouse | BigQuery | Serverless analytics, SQL over large datasets; not OLTP |
| Search | Vertex AI Search / search-oriented managed options | Use when full-text/search relevance is central, not simple primary-key lookup |
Database Decision Table
| Requirement | Prefer | Why |
|---|---|---|
| Existing MySQL/PostgreSQL/SQL Server app | Cloud SQL | Lowest migration complexity |
| Existing PostgreSQL app needs higher performance/scaling | AlloyDB | PostgreSQL compatibility with managed performance features |
| Multi-region relational writes and strong consistency | Spanner | Designed for distributed relational scale |
| Mobile app with flexible JSON-like data | Firestore | Serverless document database with client-friendly model |
| Time-series telemetry at high write rate | Bigtable | Wide-column, low-latency writes/reads |
| BI dashboards over petabyte-scale data | BigQuery | Analytical SQL engine |
| Cache frequent reads | Memorystore | Reduces database load; not authoritative storage |
| Lift-and-shift database with full admin control | Compute Engine database VM | Only when managed database does not meet requirements |
Cloud Storage Selection
| Requirement | Use | Notes |
|---|---|---|
| Frequently accessed objects | Standard storage class | Common for active content and serving |
| Infrequent access | Nearline / Coldline / Archive | Choose based on access pattern and retrieval expectations; avoid memorizing invented thresholds |
| Automatic tiering by age | Lifecycle rules | Common exam answer for cost optimization |
| Prevent accidental deletion | Versioning, retention policy, soft delete controls where applicable | Match to governance need |
| Static web assets | Cloud Storage plus Cloud CDN / load balancing where needed | Bucket alone is not full application hosting |
| Private object access | IAM, signed URLs, signed policy documents | Avoid making buckets public unless explicitly required |
| Data lake | Cloud Storage plus Dataproc, Dataflow, BigQuery, Dataplex | Object store is storage; governance/query need additional services |
Analytics, Data Engineering, and AI
| Use case | Choose | Avoid confusing with |
|---|---|---|
| Decoupled event ingestion | Pub/Sub | Cloud Tasks for task dispatch with explicit retry/target semantics |
| Stream/batch transformation | Dataflow | Pub/Sub stores messages; Dataflow processes them |
| Hadoop/Spark migration | Dataproc | BigQuery for serverless SQL analytics |
| Serverless warehouse | BigQuery | Cloud SQL for OLTP |
| Workflow orchestration | Cloud Composer | Dataflow for data processing; Workflows for simpler service orchestration |
| Visual/code-light ETL | Cloud Data Fusion | Dataflow for custom Apache Beam pipelines |
| CDC into analytics | Datastream | Database Migration Service for database migration workflows |
| SQL data transformation in BigQuery | Dataform | Composer when cross-system orchestration is required |
| Data governance and discovery | Dataplex, Data Catalog capabilities | IAM alone is not data governance |
| BI semantic layer/reporting | Looker / Looker Studio | BigQuery stores and queries data |
| ML model training/serving | Vertex AI | BigQuery ML for SQL-centric models inside BigQuery |
| Prebuilt document extraction | Document AI | Custom ML when prebuilt processors do not fit |
| Sensitive data discovery/masking | Sensitive Data Protection | KMS encrypts; it does not classify data |
Common Data Architecture Patterns
| Pattern | Reference architecture |
|---|---|
| Real-time analytics | Producers → Pub/Sub → Dataflow → BigQuery → Looker |
| Batch data lake | Sources → Cloud Storage → Dataproc/Dataflow/BigQuery external or native tables → Dataplex governance |
| CDC replication | Source DB → Datastream → Cloud Storage/BigQuery or target pipeline |
| ML pipeline | Cloud Storage/BigQuery → Vertex AI training/pipelines → model registry → endpoint/batch prediction |
| Log analytics | Cloud Logging sinks → BigQuery/Cloud Storage/Pub/Sub → analysis or archival |
Networking and Connectivity
| Service / feature | Choose when | Key exam distinction |
|---|---|---|
| VPC | Private network foundation | VPC is global; subnets are regional |
| Shared VPC | Central networking team, multiple service projects | Host project owns network; service projects deploy workloads |
| VPC Network Peering | Private RFC1918 connectivity between VPCs | Not transitive; no central inspection by default |
| Private Service Connect | Private access to Google APIs, producer services, or supported SaaS | Better for controlled private service exposure than broad peering |
| Private Google Access | VM without external IP needs Google APIs over internal path | Applies to subnet/VM access patterns; not general inbound connectivity |
| Cloud NAT | Private VMs need outbound internet | No inbound connections; pair with no external IPs |
| Cloud Router | Dynamic routing with BGP | Used with HA VPN and Interconnect |
| HA VPN | Encrypted hybrid connectivity over internet | Faster to set up; bandwidth/latency less predictable than Interconnect |
| Dedicated Interconnect | High-throughput private physical connection | Requires colocation/provider planning |
| Partner Interconnect | Private connectivity through supported provider | Useful when Dedicated Interconnect is not practical |
| Cross-Cloud Interconnect | Private connectivity to supported other clouds | Use for multicloud private networking scenarios |
| Network Connectivity Center | Hub-and-spoke connectivity management | Good for enterprise hybrid/multicloud topology |
| Cloud DNS | Managed DNS | Combine with private zones for internal resolution |
| Cloud CDN | Cache static/cacheable content at edge | Requires appropriate backend/load balancing pattern |
| Cloud Armor | WAF and DDoS protection for supported HTTP(S) workloads | Not a substitute for IAM or app auth |
Load Balancer Selection
| Requirement | Prefer | Notes |
|---|---|---|
| Global HTTP(S) web app | Global external Application Load Balancer | L7 routing, TLS, Cloud CDN, Cloud Armor integration |
| Regional HTTP(S) app | Regional external Application Load Balancer | Use when regional scope is required |
| Private HTTP(S) services | Internal Application Load Balancer | Internal L7 traffic management |
| TCP/UDP pass-through | Network Load Balancer options | Use for L4 workloads, non-HTTP protocols |
| Internal TCP/UDP | Internal passthrough Network Load Balancer | Private load balancing inside VPC |
| GKE ingress | Google Cloud load balancing via GKE Ingress/Gateway | Match with GKE architecture |
| Hybrid backend integration | Load balancer with hybrid connectivity patterns where supported | Confirm backend type and connectivity requirement conceptually |
Networking Traps
| Trap | Correct thinking |
|---|---|
| “Cloud NAT lets users reach private VMs” | Cloud NAT is outbound-only |
| “VPC peering creates a hub-and-spoke transit network” | VPC peering is not transitive |
| “External IPs are required for Google API access” | Private Google Access or Private Service Connect can avoid external IPs |
| “Firewall rules replace IAM” | Network controls and identity controls solve different problems |
| “Global VPC means subnets are global” | Subnets are regional |
| “Interconnect is encrypted by default like VPN” | VPN provides encryption; for Interconnect, evaluate encryption requirements separately |
IAM, Security, and Governance
Resource Hierarchy
| Level | Use for |
|---|---|
| Organization | Enterprise-wide policies, central governance |
| Folder | Department, environment, business unit segmentation |
| Project | Workload/application boundary, billing/quota/IAM unit |
| Resource | Service-specific access where appropriate |
IAM Reference
| Concept | Use | PCA distinction |
|---|---|---|
| Principal | User, group, service account, workload identity | Prefer groups for humans and service accounts for workloads |
| Role | Set of permissions | Use predefined roles first; custom roles for least privilege gaps |
| Policy binding | Grants role to principal at resource scope | Grant at lowest practical scope |
| Basic roles | Owner, Editor, Viewer | Usually too broad for production least privilege |
| Service account | Application/workload identity | Do not treat as a human user |
| Service account key | Long-lived credential | Avoid when federation or attached service accounts work |
| IAM Conditions | Context-aware conditional grants | Useful for time, resource, or attribute-based constraints |
| Deny policies | Explicitly restrict permissions | Use for guardrails where allow policies are too broad |
| Organization Policy Service | Constraint-based governance | Controls allowed configurations; not the same as IAM |
| Policy Controller / Config Controller patterns | Kubernetes/resource policy enforcement | Useful in platform governance scenarios |
Security Service Selection
| Requirement | Prefer | Notes |
|---|---|---|
| Centralized identity for workforce | Cloud Identity / external IdP federation | Use SSO and groups for manageability |
| No service account keys from external workloads | Workload Identity Federation | Replaces long-lived keys for many external CI/CD and workload scenarios |
| GKE workloads use Google Cloud APIs | Workload Identity for GKE | Avoid node-wide broad service account permissions |
| Secrets storage | Secret Manager | Do not store secrets in images, source code, or metadata |
| Encryption key control | Cloud KMS with CMEK where required | Default encryption exists, but CMEK gives customer-managed control |
| External key control | Cloud External Key Manager where required | Use only when scenario demands external key custody |
| Data perimeter | VPC Service Controls | Helps reduce data exfiltration from supported services |
| App access without VPN | Identity-Aware Proxy | User/context-aware access to supported apps/resources |
| Threat/security posture | Security Command Center | Central visibility, findings, risk management |
| Asset inventory | Cloud Asset Inventory | Audit resources and IAM over time |
| Sensitive data inspection | Sensitive Data Protection | Classification, inspection, masking/tokenization use cases |
| Audit trail | Cloud Audit Logs, log sinks | Export to BigQuery/Cloud Storage/SIEM as required |
Security Traps
| Scenario wording | Wrong shortcut | Better answer |
|---|---|---|
| “Developers need temporary deployment access” | Give Owner | Use least-privilege predefined/custom role, group, condition if applicable |
| “On-prem app needs Google Cloud access” | Download service account key | Prefer Workload Identity Federation if supported |
| “Prevent data exfiltration from BigQuery/Cloud Storage” | IAM only | Combine IAM, VPC Service Controls, org policies, logging, DLP as needed |
| “KMS encrypts sensitive fields” | Use KMS as classifier | KMS manages keys; Sensitive Data Protection discovers/classifies/masks |
| “Network is private, so auth is unnecessary” | Trust network boundary only | Use identity, IAM, mTLS/service auth where appropriate |
| “Give GKE node service account broad access” | Node-level permissions | Use Workload Identity for GKE per workload |
Reliability, Availability, and Disaster Recovery
Core Terms
| Term | Meaning | Exam use |
|---|---|---|
| SLI | Measured indicator, such as latency or availability | What you measure |
| SLO | Target for an SLI | What you promise internally |
| SLA | External contractual commitment | Do not invent values |
| Error budget | Allowed unreliability under SLO | Balances release velocity and reliability |
| RTO | Maximum acceptable recovery time | Drives failover automation |
| RPO | Maximum acceptable data loss | Drives replication/backup design |
| MTTR | Mean time to recover | Improve with automation and observability |
Availability Pattern Selection
| Requirement | Pattern |
|---|---|
| Survive VM failure | Managed instance group, health checks, autoscaling |
| Survive zone failure | Regional managed instance group or regional managed service |
| Survive region failure | Multi-region active-active or active-passive architecture |
| Low global latency | Global load balancing, CDN, regional backends near users |
| Stateless app HA | Multiple zones/regions behind load balancer |
| Stateful relational HA | Managed HA database option or replicated architecture |
| Backup/restore DR | Automated backups, tested restore procedures |
| Near-zero downtime deployments | Rolling, blue/green, or canary deployments |
| Fault isolation | Separate projects, regions, clusters, service boundaries |
DR Decision Table
| RTO/RPO pressure | Typical architecture | Tradeoff |
|---|---|---|
| Low pressure, cost-sensitive | Backup and restore | Cheapest, slowest recovery |
| Moderate | Pilot light / warm standby | Faster recovery, some idle cost |
| High | Active-passive with replication | More automation and duplicate capacity |
| Very high global availability | Active-active multi-region | Highest complexity; conflict/data design matters |
Reliability Traps
| Trap | Correct thinking |
|---|---|
| Backups are enough for all DR | Restore time and data loss must meet RTO/RPO |
| Multi-zone equals multi-region | Zonal failure protection is not regional disaster protection |
| Stateless autoscaling fixes database bottlenecks | Scale and protect the stateful tier separately |
| Active-active is always best | It increases cost and complexity; use only when justified |
| Health checks alone guarantee app health | Health checks must reflect real dependency readiness |
| Manual failover is acceptable for strict RTO | Automation is usually required for tight RTO |
Application Modernization and Migration
| Strategy | Meaning | Google Cloud fit |
|---|---|---|
| Rehost | Move as-is | Compute Engine, Migrate to Virtual Machines, VMware Engine |
| Replatform | Minor changes to managed services | Cloud SQL, Cloud Run, GKE, managed load balancing |
| Refactor | Redesign app architecture | Microservices, Pub/Sub, Cloud Run/GKE, managed databases |
| Replace | Adopt SaaS or packaged solution | Use when custom app no longer provides business value |
| Retire | Remove unused systems | Common cost/risk reduction step |
| Retain | Keep temporarily | Use for dependencies, compliance, or phased migration |
Migration Service Selection
| Need | Choose |
|---|---|
| VM migration | Migrate to Virtual Machines |
| VMware environment migration with minimal change | Google Cloud VMware Engine |
| Database migration | Database Migration Service |
| Large online/offline object transfer | Storage Transfer Service |
| Physical appliance transfer for large datasets | Transfer Appliance |
| Streaming database change replication | Datastream |
| Landing zone setup | Resource hierarchy, IAM, Shared VPC, logging, billing, org policies |
| App dependency discovery | Migration assessment/discovery tooling and architecture review |
Modernization Patterns
| Pattern | Use when | Reference design |
|---|---|---|
| Strangler fig | Replace legacy app gradually | Route selected functions to new services while legacy remains |
| Event-driven decoupling | Systems need async integration | Pub/Sub between producers and consumers |
| API façade | Legacy backend needs modern interface | API layer on Cloud Run/GKE with auth, logging, throttling |
| Containerize first | App can run in containers but not fully refactored | Cloud Run for stateless, GKE for Kubernetes/platform needs |
| Database offload | Analytics overloads OLTP database | Replicate/export to BigQuery |
DevOps, CI/CD, and Infrastructure as Code
| Requirement | Prefer | Notes |
|---|---|---|
| Source repository integration | Cloud Build with source triggers or existing CI | Match enterprise tooling if specified |
| Artifact storage | Artifact Registry | Container and package artifact management |
| Progressive delivery to GKE/Cloud Run | Cloud Deploy | Managed delivery pipelines |
| Infrastructure as code | Terraform, Infrastructure Manager, Config Controller where appropriate | PCA tests concepts more than syntax |
| Policy as code | Organization Policy, Policy Controller, CI checks | Enforce guardrails before deployment |
| Secrets in CI/CD | Secret Manager and workload identity/federation | Avoid plaintext build variables |
| Deployment rollback | Versioned artifacts, blue/green/canary, release promotion | Design rollback before failure |
| Environment separation | Separate projects/folders per environment | Enables IAM, billing, quota, and blast-radius control |
Deployment Pattern Selection
| Pattern | Choose when | Tradeoff |
|---|---|---|
| Rolling update | Normal low-risk updates | Simple; some mixed-version period |
| Blue/green | Fast rollback and environment validation | Duplicate capacity during cutover |
| Canary | Validate with small traffic percentage | Requires monitoring and traffic control |
| Immutable infrastructure | Avoid configuration drift | Requires automated build/deploy pipeline |
| Feature flags | Decouple release from deployment | Requires app-level implementation |
Observability and Troubleshooting
| Need | Service / feature | Exam cue |
|---|---|---|
| Metrics and alerting | Cloud Monitoring | SLOs, dashboards, uptime checks |
| Logs | Cloud Logging | Central logs, log-based metrics |
| Audit trail | Cloud Audit Logs | Admin, data access, policy activity; verify what must be enabled/exported |
| Error aggregation | Error Reporting | App exceptions |
| Distributed tracing | Cloud Trace | Latency across services |
| Profiling | Cloud Profiler | CPU/memory performance over time |
| Log export | Log sinks to BigQuery, Cloud Storage, Pub/Sub | Analytics, retention, SIEM integration |
| Resource inventory | Cloud Asset Inventory | “What changed?” and governance review |
| SLO management | Cloud Monitoring SLOs | Reliability engineering scenarios |
Troubleshooting Decision Table
| Symptom | Check first | Likely issue |
|---|---|---|
| 403 permission denied | IAM binding scope, service account, org policy, VPC Service Controls | Identity or policy problem |
| VM has no internet egress | Route, firewall egress, Cloud NAT, external IP, Private Google Access for APIs | Network egress design |
| Private VM cannot call Google APIs | Private Google Access / Private Service Connect, DNS, firewall | Missing private API access path |
| GKE pod cannot access Google APIs | Workload Identity for GKE, Kubernetes service account binding, IAM role | Workload identity mapping |
| High web latency globally | Load balancer scope, CDN, backend region, database latency | Regional architecture for global users |
| Pub/Sub duplicates | Subscriber idempotency and ack handling | Pub/Sub is at-least-once; design consumers accordingly |
| BigQuery query cost high | Partitioning, clustering, selected columns, materialized views, reservations if applicable | Inefficient analytical query design |
| Cloud Run cold-start concern | Min instances where justified, right runtime/container size | Serverless scaling tradeoff |
| Database overloaded by reports | Read replica or analytics offload to BigQuery | Mixing OLTP and analytics |
Cost and Performance Optimization
| Area | Practical controls |
|---|---|
| Compute Engine | Rightsizing, autoscaling, managed instance groups, committed use discounts where stable, Spot VMs for interruptible work |
| GKE | Autopilot for reduced ops, right-sized requests/limits, cluster autoscaling, separate node pools for specialized workloads |
| Cloud Run | Concurrency, min instances only when needed, efficient container startup, scale-to-zero for variable traffic |
| Cloud Storage | Lifecycle policies, storage class selection, avoid unnecessary duplication, monitor retrieval/egress patterns |
| BigQuery | Partitioning, clustering, materialized views, avoid SELECT *, manage reservations/slots where appropriate |
| Databases | Read replicas, caching, indexing, connection pooling, choose the right database model |
| Networking | Reduce unnecessary cross-region egress, use CDN for cacheable content, place compute near data/users |
| Operations | Billing export to BigQuery, budgets/alerts, labels, project separation, resource cleanup automation |
Cost Traps
| Trap | Better approach |
|---|---|
| Use the cheapest VM shape for everything | Match workload performance and reliability requirements |
| Use Spot VMs for critical stateful services | Use Spot only when interruption is acceptable |
| Store all data in one class forever | Apply lifecycle policies based on access |
| Run analytics on production OLTP | Offload to BigQuery or replicas |
| Add min instances everywhere | Use only where latency requirement justifies cost |
| Ignore network egress | Architect data locality and caching intentionally |
Governance and Enterprise Landing Zone Checklist
| Domain | Include in target architecture |
|---|---|
| Resource hierarchy | Organization, folders, projects by environment/app/team |
| Identity | Cloud Identity or federation, groups, least privilege |
| Networking | Shared VPC, subnet strategy, hybrid connectivity, DNS, firewall policy |
| Security guardrails | Org policies, IAM deny where appropriate, VPC Service Controls for sensitive services |
| Logging | Central log sinks, audit log retention/export, SIEM integration if required |
| Billing | Billing accounts, budgets, labels, export to BigQuery |
| Key management | KMS key rings/keys, CMEK requirements, separation of duties |
| CI/CD | Artifact Registry, build/deploy pipelines, policy checks |
| Monitoring | Standard dashboards, alerting, SLOs, incident response |
| Compliance evidence | Asset inventory, audit logs, security findings, documented controls |
High-Yield Exam Distinctions
| Do not confuse | With | Distinction |
|---|---|---|
| Cloud SQL | Spanner | Cloud SQL is regional managed relational; Spanner is distributed relational scale/global consistency |
| BigQuery | Cloud SQL | BigQuery is analytics; Cloud SQL is transactional |
| Bigtable | BigQuery | Bigtable serves low-latency operational access; BigQuery analyzes large datasets |
| Pub/Sub | Cloud Tasks | Pub/Sub is event messaging; Cloud Tasks dispatches tasks to handlers with queue semantics |
| Dataflow | Dataproc | Dataflow is managed Beam stream/batch; Dataproc is managed Spark/Hadoop |
| Cloud Run | GKE | Cloud Run is serverless containers; GKE is Kubernetes platform |
| GKE Autopilot | GKE Standard | Autopilot reduces node ops; Standard gives more control |
| Cloud NAT | Load balancer | NAT enables outbound private VM egress; load balancer handles inbound distribution |
| VPC peering | Shared VPC | Peering connects networks; Shared VPC centralizes network ownership for projects |
| IAM | Org Policy | IAM grants permissions; org policy constrains allowed configurations |
| KMS | Secret Manager | KMS manages cryptographic keys; Secret Manager stores secrets |
| VPC Service Controls | Firewall | VPC-SC protects service perimeters; firewall controls network traffic |
| Cloud CDN | Cloud Storage | CDN caches/serves content closer to users; Storage holds objects |
Scenario Answer Patterns
| Scenario clue | Strong candidate answer |
|---|---|
| “Reduce operational overhead” | Prefer serverless/managed services; avoid self-managed clusters/VMs unless required |
| “Existing monolith on VMs, rapid migration” | Rehost to Compute Engine or VMware Engine; modernize later |
| “Stateless container API with unpredictable traffic” | Cloud Run behind appropriate load balancing/auth controls |
| “Kubernetes required by platform team” | GKE Autopilot unless node-level control is required |
| “Global users, static and dynamic web content” | Global external Application Load Balancer, Cloud CDN for cacheable assets, regional backends |
| “Strict least privilege” | Groups, predefined/custom roles, minimal scope, service accounts, IAM Conditions if useful |
| “No public IPs on workloads” | Private subnets, Cloud NAT for egress, Private Google Access/Private Service Connect |
| “Sensitive data perimeter” | IAM plus VPC Service Controls, audit logs, org policies, DLP/Sensitive Data Protection |
| “Streaming sensor data” | Pub/Sub ingestion, Dataflow processing, Bigtable or BigQuery depending on serving/analytics need |
| “Reports slow down production DB” | Replicate/export to BigQuery; use read replicas when appropriate |
| “Need multi-region relational consistency” | Cloud Spanner |
| “Need cache to reduce read latency” | Memorystore in front of primary database |
| “Need central network administration” | Shared VPC with host/service projects |
| “Need private hybrid connectivity” | HA VPN for encrypted internet-based connectivity; Interconnect for private higher-throughput needs |
| “Need auditable infrastructure changes” | IaC, CI/CD approvals, Cloud Audit Logs, Asset Inventory |
Last-Minute PCA Review Checklist
- Can you justify why a managed service is or is not suitable?
- Can you separate OLTP, analytics, cache, object, block, and file storage?
- Can you choose between Cloud Run, GKE, App Engine, and Compute Engine from requirements?
- Can you explain Shared VPC, VPC peering, Private Service Connect, Private Google Access, Cloud NAT, VPN, and Interconnect?
- Can you design for least privilege without using broad basic roles?
- Can you identify when VPC Service Controls are needed and when they are not enough?
- Can you map RTO/RPO to backup, warm standby, active-passive, or active-active?
- Can you design centralized logging, monitoring, alerting, and audit export?
- Can you optimize BigQuery, Cloud Storage, compute, and network egress without breaking requirements?
- Can you spot answers that are technically possible but operationally heavy?
Practical Next Step
Use this Quick Reference to review one architecture scenario at a time: identify the business goal, choose the managed services, define the security boundary, plan reliability, and explain the tradeoff. Then move into timed PCA practice questions and force yourself to eliminate answers that violate requirements, add unnecessary operations, or ignore security and reliability constraints.