Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Scope and study context 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.The PCA exam is not just a service-name recall test. Strong candidates can translate business requirements into secure, reliable, cost-aware Google Cloud architectures. Expect scenarios where several answers are technically possible, but only one best matches the constraints.
Core Google Cloud architecture decision rules Compute, networking, data, security, and operations patterns Common traps in scenario questions How to connect review to IT Mastery practice and original practice questions 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”
Notes and examples 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
Notes and examples 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
Storage and database decision table Most PCA data questions come down to workload shape: object storage, relational transactions, global consistency, document access, time-series/wide-column data, or analytics.
Workload Strong candidate service Object storage, backups, media, data lake landing zone Cloud Storage Managed MySQL/PostgreSQL/SQL Server relational database Cloud SQL High-performance PostgreSQL-compatible transactional workload AlloyDB Global relational database with strong consistency and horizontal scale Spanner Document database for app development Firestore Wide-column, low-latency, high-throughput workloads Bigtable In-memory cache Memorystore Enterprise file shares Filestore Analytics warehouse BigQuery Streaming messaging Pub/Sub Stream/batch data processing Dataflow Managed Spark/Hadoop Dataproc Workflow orchestration Cloud Composer Data lake storage foundation Cloud Storage plus analytics tools
Data decision traps Trap Better thinking Choosing BigQuery for high-frequency OLTP app transactions BigQuery is analytics-focused; use transactional databases for OLTP Choosing Cloud SQL for global horizontal scale with strong consistency Consider Spanner if global relational scale is required Choosing Bigtable because data is “big” Bigtable fits low-latency key-based access patterns, not general SQL analytics Choosing Firestore for complex relational joins Firestore is document-oriented; model access patterns carefully Storing secrets in Cloud Storage or source code Use Secret Manager Ignoring data residency or compliance clues Choose region/multi-region deliberately and apply governance controls Overusing multi-region storage without need Balance availability, latency, compliance, and cost
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
Notes and examples 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
Notes and examples 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
Networking quick review Networking questions often test whether you can keep traffic private, reduce latency, connect hybrid environments, or choose the right load balancer.
Requirement Likely Google Cloud concept Isolate resources VPC, subnet design, firewall rules, IAM Centralize networking for many projects Shared VPC Private communication to Google APIs Private Google Access / Private Service Connect depending on use case Private service publishing/consumption Private Service Connect Connect VPCs VPC Network Peering or Network Connectivity Center patterns Outbound internet for private VMs Cloud NAT Hybrid connectivity Cloud VPN or Cloud Interconnect Low-latency dedicated hybrid link Cloud Interconnect Global external HTTP(S) traffic Global external Application Load Balancer Internal service traffic Internal load balancing Edge caching Cloud CDN DNS management Cloud DNS DDoS/WAF protection Cloud Armor Service-to-service control in GKE Service mesh / network policies where appropriate
Networking traps Cloud NAT is outbound only. It does not allow inbound internet connections to private instances.Firewall rules are stateful , but you still need the right direction, target, source, and priority.Shared VPC is commonly the right answer when central network teams manage networking for service projects.VPC peering is not transitive. Do not assume A-to-B and B-to-C means A-to-C connectivity.Private Google Access helps private VMs reach supported Google APIs without external IPs.Cloud VPN is often faster to set up; Cloud Interconnect is typically used when dedicated, higher-throughput, lower-latency connectivity is required.Use Cloud CDN and global load balancing for global web performance; do not solve every latency issue by adding more VMs. 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
Notes and examples 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
Security and IAM quick review Security scenarios often ask for the least privileged , most auditable , and most maintainable answer.
Requirement Strong approach Human access control IAM groups, predefined/custom roles, least privilege Application identity Service accounts Avoid long-lived keys Workload identity federation or attached service accounts instead of downloadable keys Store secrets Secret Manager Encryption key control Cloud KMS / Cloud HSM when appropriate Central policy enforcement Organization Policy Service Detect security risks Security Command Center Audit activity Cloud Audit Logs Restrict data exfiltration from supported services VPC Service Controls Context-aware access Access Context Manager / BeyondCorp-style controls Protect web apps Cloud Armor Private access to services Private Service Connect and private networking patterns
IAM decision rules Assign access to groups , not individual users, where possible. Use predefined roles before custom roles unless the scenario requires exact permission tailoring. Avoid Owner , Editor , and Viewer for production access unless the question explicitly justifies them. Use service accounts per workload rather than sharing one broad service account. Avoid service account keys when an identity-based alternative is available. Use organization policies to enforce constraints across projects. Use separation of duties for production deployments, security administration, and audit review. Security traps “Encrypt the data” is not enough; identify whether default encryption is sufficient or customer-managed keys are required. Do not grant broad project-level roles to solve one resource-level permission issue. Do not expose a private workload with public IPs when private connectivity is required. Do not use firewall rules as the only security boundary for identity-sensitive services. Do not confuse authentication with authorization. Do not store API keys, passwords, or certificates in container images or source repositories. 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
Notes and examples 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
Notes and examples 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
Migration and modernization review Migration scenarios test sequencing, risk reduction, downtime tolerance, and data movement.
Scenario Strong approach Lift-and-shift VMs Migrate to Virtual Machines / Compute Engine migration tooling Modernize monolith gradually Strangler pattern, APIs, staged migration Database migration with minimal downtime Database Migration Service where supported, replication, cutover planning Large object/data transfer Storage Transfer Service, Transfer Appliance for very large/offline transfers Hybrid period required Cloud VPN or Cloud Interconnect, hybrid DNS, identity integration Validate before cutover Pilot, test migration, dual-run, canary, rollback plan Standardize infrastructure Infrastructure as code and repeatable deployment pipelines Legacy app with minimal changes Compute Engine or VMware Engine depending on constraints
Migration traps Replatforming everything at once increases risk unless the scenario requires it. Choosing a solution that requires downtime when the requirement says minimal downtime. Ignoring identity, DNS, firewall, monitoring, and rollback planning. Moving data without validating consistency and application compatibility. Forgetting that migration success includes operations after cutover, not only data transfer. 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
Notes and examples 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
Notes and examples 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
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
Notes and examples 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
PCA cost questions are usually about selecting an architecture that meets requirements without overengineering.
Cost area Review points Compute Autoscaling, rightsizing, machine family selection, committed use discounts where appropriate Serverless Pay-per-use can reduce idle cost, but understand concurrency and invocation patterns Storage Choose appropriate storage class, lifecycle policies, retention, object versioning Networking Watch egress, inter-region traffic, CDN caching, private connectivity needs BigQuery Partitioning, clustering, materialized views, reservations/slots or on-demand fit Logging Log volume, exclusions, retention Databases Scale shape, replicas, HA, storage growth, backups DR Balance RTO/RPO against standby capacity cost
Cost traps Choosing active-active multi-region when the RTO/RPO does not require it. Keeping development environments running 24/7 without need. Ignoring network egress in distributed architectures. Overprovisioning GKE clusters when serverless or autoscaling would satisfy the requirement. Using premium managed services by default without matching workload needs. Treating committed discounts as a first step before rightsizing and usage analysis. 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
Notes and examples Common answer-choice patterns If the option says… Be cautious because… “Grant Owner role” Usually violates least privilege “Create service account keys” Long-lived keys are often avoidable “Use a single VM” May fail availability/scaling requirements “Use BigQuery for app transactions” Wrong fit for OLTP “Manually copy data” Weak for repeatability, scale, and auditability “Expose the database publicly” Usually fails security requirements “Use Cloud NAT for inbound access” Cloud NAT is outbound only “Use multi-region everywhere” May overrun cost/complexity requirements “Refactor all applications immediately” Often too risky for migration scenarios “Rely only on backups for low RTO” Restore time may not meet requirement
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? High-yield PCA mindset The best answer usually balances business requirements , technical constraints , Google Cloud managed services , and operational simplicity .
Scenario clue Architectural instinct “Minimize operations” Prefer managed/serverless services over self-managed infrastructure “Global users, low latency” Consider global load balancing, CDN, multi-region data, edge caching “Strict RPO/RTO” Design for replication, automated failover, tested recovery, backups “Regulated data” Use IAM least privilege, encryption, audit logging, VPC Service Controls where appropriate “Existing on-premises integration” Consider Cloud VPN, Cloud Interconnect, hybrid DNS, identity federation “Unpredictable traffic” Use autoscaling, serverless, queues, event-driven design “Large analytics workloads” Think BigQuery, Dataflow, Dataproc, Pub/Sub, Cloud Storage “Transactional relational workload” Consider Cloud SQL, AlloyDB, or Spanner depending on scale and global needs “Need portability / Kubernetes standardization” Consider Google Kubernetes Engine, but weigh operational complexity “Cost is a key constraint” Rightsize, autoscale, choose storage classes, avoid unnecessary egress, use commitments carefully
Fast architecture decision flow
flowchart TD
A[Read business goal] --> B[Identify constraints]
B --> C{Primary workload type?}
C -->|Web/API/app| D[Choose compute pattern]
C -->|Data/analytics| E[Choose storage and pipeline]
C -->|Hybrid/migration| F[Choose connectivity and migration path]
D --> G[Secure identity, network, secrets]
E --> G
F --> G
G --> H[Design reliability and DR]
H --> I[Optimize cost and operations]
I --> J[Select answer with least complexity that satisfies requirements]
Core Google Cloud resource model Understand the hierarchy because many PCA security and governance questions depend on it.
Level What to remember Organization Top-level boundary for centralized policy, IAM, billing, and governance Folder Groups projects by department, environment, app, or business unit Project Main isolation boundary for resources, IAM, quotas, billing attribution, APIs Resource Individual service objects such as VM instances, buckets, clusters, datasets
Common hierarchy traps Granting permissions too broadly at the organization level when project-level or resource-level access is enough. Using primitive roles when predefined or custom roles better support least privilege. Forgetting that inherited IAM can create access unintentionally. Mixing production and non-production workloads in the same project without a strong reason. Ignoring organization policies when the scenario asks for centralized enforcement. Choose compute by matching operational burden, portability, scaling, and runtime requirements.
Service / pattern Best fit Watch for Cloud Run Stateless containers, APIs, event-driven apps, scale-to-zero patterns Not ideal for highly stateful workloads without external state storage Cloud Functions Lightweight event-driven functions Avoid when container control or complex runtime dependencies are required App Engine Managed web apps with minimal infrastructure management Less control than GKE or Compute Engine Google Kubernetes Engine Container orchestration, microservices, Kubernetes portability, platform teams More operational complexity than Cloud Run Compute Engine Custom VMs, legacy workloads, special OS/configuration needs Requires more management than serverless/managed platforms Managed instance groups Autoscaled VM fleets, rolling updates, self-healing Design health checks and load balancing correctly Batch Batch jobs and high-throughput non-interactive workloads Not for low-latency request/response apps Cloud Run jobs Containerized jobs without always-on infrastructure Good for task execution, not long-lived services VMware Engine VMware-based migration or extension scenarios Use when VMware compatibility matters, not as default modernization
Notes and examples Compute decision rules Prefer Cloud Run for stateless containerized services when you want managed scaling and low operational overhead. Prefer GKE when Kubernetes control, service mesh, custom networking, or workload portability is a requirement. Prefer Compute Engine when the workload needs custom machine configuration, legacy software, or VM-level control. Prefer managed instance groups over unmanaged VM fleets for autoscaling and self-healing. Externalize state to managed storage such as Cloud SQL, Spanner, Firestore, Memorystore, Cloud Storage, or Bigtable. Container and delivery topics to review Need Google Cloud option Store container images Artifact Registry Build/test/deploy pipeline Cloud Build, Cloud Deploy Kubernetes workload identity Workload Identity / workload identity federation patterns Enforce trusted container deployment Binary Authorization Manage GKE configuration Config Sync / policy-based controls where appropriate Canary or progressive delivery Cloud Deploy, load balancing, GKE rollout strategies, Cloud Run revisions Secrets Secret Manager, not hardcoded environment values
BigQuery and analytics review BigQuery questions often mix cost, performance, governance, and ingestion choices.
Need Review point Analyze large datasets with SQL BigQuery Load data periodically Batch loads, BigQuery Data Transfer Service, Storage Transfer Service depending on source Stream events Pub/Sub into Dataflow or supported streaming ingestion patterns Reduce query cost Partitioning, clustering, selective columns, materialized views, query optimization Control data access Dataset/table permissions, authorized views, row-level and column-level controls where appropriate Separate storage and compute Understand BigQuery’s serverless analytics model Share governed datasets Use appropriate IAM and data sharing patterns
BigQuery traps Querying unnecessary columns increases scanned data when using on-demand pricing models. Partitioning is useful only when queries filter on partitioned fields. Clustering helps when queries filter or aggregate on clustered columns. BigQuery is not a replacement for a low-latency transactional application database. Governance is not just IAM; consider dataset structure, views, policy tags, and auditability. Reliability, DR, and SRE review PCA reliability questions usually test whether the architecture meets availability and recovery requirements without unnecessary complexity.
Key terms:
RTO : how quickly the service must be restored.RPO : how much data loss is acceptable.SLO : target reliability level for a service.Error budget : allowable unreliability over a period.Notes and examples \[
\text{Availability} = \frac{\text{Successful requests}}{\text{Total valid requests}}
\]\[
\text{Error budget} = 1 - \text{SLO}
\]Reliability design table Requirement Design instinct Survive zonal failure Use regional managed services or deploy across zones Survive regional failure Use multi-region or cross-region DR design Low RTO Automate failover and keep warm/active capacity Low RPO Use synchronous or near-real-time replication where appropriate Stateless web tier Use load balancing and autoscaling across zones Stateful database Use managed HA, replicas, backups, and tested restore Message buffering Pub/Sub or queues to absorb spikes and decouple systems Graceful degradation Cache, fallback responses, circuit breakers Operational visibility Cloud Monitoring, Cloud Logging, tracing, alerts, dashboards
DR pattern comparison Pattern Use when Tradeoff Backup and restore Lower cost, higher RTO acceptable Slowest recovery Pilot light Minimal standby environment Faster than restore, still needs scale-up Warm standby Reduced-capacity duplicate environment Higher cost, faster recovery Active-active Very low RTO, global availability Highest complexity and cost
Reliability traps Backups do not prove recoverability; restores must be tested. Multi-zone is not the same as multi-region. Autoscaling does not fix database bottlenecks automatically. A load balancer cannot route to healthy capacity if the backend design is single-zone. SLOs should reflect user experience, not only infrastructure uptime. Alerting on every metric creates noise; alert on symptoms and user-impacting conditions. Operations and observability Operational questions look for maintainable, automated, auditable solutions.
Need Google Cloud capability Metrics and alerting Cloud Monitoring Logs Cloud Logging Distributed traces Cloud Trace Error aggregation Error Reporting Service health and SLOs Cloud Monitoring service monitoring Audit trail Cloud Audit Logs Deployment automation Cloud Build, Cloud Deploy, Terraform/infrastructure as code patterns Config governance Organization policies, policy-as-code, Config Controller/Config Sync where appropriate Incident response Dashboards, alerts, runbooks, postmortems
Operations traps Manual console changes are rarely the best answer for repeatable production architecture. Alerts should be actionable and tied to service impact. Logs have cost and retention implications; collect what you need and manage retention. Monitoring must include dependencies such as databases, queues, and external services. Production changes should be versioned, reviewed, and reversible. Scenario-reading technique for PCA Use this checklist on every long question.
Identify the primary business goal. Cost reduction, availability, compliance, modernization, speed, scalability, or migration?Underline hard constraints. “Must,” “without downtime,” “least operational overhead,” “existing Kubernetes,” “global,” “private,” “auditable.”Classify the workload. Web app, batch, analytics, streaming, relational transaction, document, ML, hybrid.Choose managed services first. Only add lower-level infrastructure when needed.Apply security by default. IAM least privilege, private access, encryption, audit logs, secrets management.Check reliability. Does the answer meet stated RTO/RPO and failure-domain requirements?Check cost and simplicity. Avoid architectures that exceed the requirement.Eliminate answers with one fatal flaw. Broad IAM, public exposure, manual process, single point of failure, wrong data model.Final rapid review checklist Before starting original practice questions, confirm that you can quickly explain:
When to choose Cloud Run, GKE, Compute Engine, App Engine, or Cloud Functions How Shared VPC, VPC peering, Private Google Access, Private Service Connect, Cloud NAT, Cloud VPN, and Cloud Interconnect differ When to choose Cloud SQL, AlloyDB, Spanner, Firestore, Bigtable, BigQuery, or Cloud Storage How IAM inheritance, service accounts, least privilege, and organization policies work How to design for zonal, regional, and multi-region resilience How RTO, RPO, SLOs, and error budgets influence architecture choices How to reduce BigQuery, compute, storage, logging, and network costs How to plan staged migrations with validation and rollback How to spot overbroad permissions, public exposure, manual operations, and single points of failure Connect this review to practice After this Cheat Sheet, move into IT Mastery practice:
Use topic drills for weak areas such as IAM, networking, data services, and reliability. Use original practice questions to build scenario-reading speed. Use a full question bank to compare similar services under realistic constraints. Review detailed explanations carefully, especially when an answer is technically possible but not the best architectural choice. Practical next step: choose one weak domain, complete a focused topic drill, and review every explanation until you can state why the correct answer is better than the plausible distractors.
Put the review into practice IT Mastery
Practice PCA \u2014 Google Cloud Professional Cloud Architect 2026 on Web Use the web app to preview question style, then practise the topics you need to revisit.
Original IT Mastery practice, independent of the exam provider; not official exam questions.
Open in IT Mastery Free preview
Included
before subscription
Practice bank
720
total questions
in the app
This bank is live. We continue expanding and refining high-demand banks based on learner usage, feedback, and syllabus updates.