PCA Cheat Sheet

A business goal becomes architectable only when you separate what the system must do (the functional requirement) from how well it must do it (the non-functional requirements: availability, latency, recovery, compliance). The non-functional requirement is what drives the service choice, so on a case study the binding constraint is usually a non-functional one even when the stem leads with a feature. Name it first, then the right Google Cloud product follows from it.

Trap Picking the service from the stated feature instead of the non-functional constraint; a global storefront that needs strong global consistency is a Spanner question, not just any regional database that also serves storefronts.

Altostrat, Cymbal, EHR Healthcare, and KnightMotives stems wrap the testable constraint in a business narrative. Underline the numbers and the must/never clauses, because those are the requirements; the surrounding prose is context. The correct answer is the one that satisfies the binding constraint, so extracting it is the first move on any case-study question.

Recovery targets set the cost: Google states that the smaller the RTO and RPO, the more the application costs to run, because faster recovery needs warmer, more-replicated infrastructure. Use the stated tolerance to pick the cheapest pattern that still meets it, and resist gold-plating a workload to a stricter tier than the business asked for.

Trap Defaulting every workload to a hot, multi-region active design; a workload whose owners accept a few hours of downtime is over-provisioned and over-billed by that choice.

Each existing system gets a disposition. Build a cloud-native service only when no managed option meets the functional requirement; buy a managed service or SaaS when one already does, because it offloads operational work; modify (refactor or containerize) an app that has value but does not fit as-is; deprecate a capability the business no longer needs, which is the cheapest outcome. The default lean is buy and modify over build.

Trap Reaching for a custom build when a managed service already meets the requirement; building adds the run-and-staff burden a buy decision avoids and is justified only when no managed product fits.

A managed or SaaS service that meets the requirement carries the lowest operational load, because Google runs the platform while you run only your data and configuration. That offload is itself a design goal: it frees the team you would otherwise have to staff to operate a self-built equivalent. Build custom only when the functional requirement has no managed answer.

Before deciding how to move a workload, ask whether the business still needs it at all. Retiring a capability nobody uses removes its entire run cost immediately, which beats any migration of it. Disposition analysis starts with the still-needed question, not with how to rehost.

Most cloud resources are billed as OpEx (you pay as you consume) rather than the up-front CapEx of buying hardware. The decision-grade comparison you put to a business owner is therefore total cost of ownership over time, not a one-time sticker price. This shift is what lets a pay-as-you-go option beat owned hardware once utilization and lifecycle are counted.

Google's cost optimization pillar rests on four principles: align cloud spending with business value, foster a culture of cost awareness, optimize resource usage, and optimize continuously. "Align spending with business value" is the exam's favourite: a cheaper option that misses a non-functional requirement is not cost-optimal, because it fails the requirement it existed to satisfy. Cost-optimal means cheapest among the options that actually meet the requirements.

Trap Picking the lowest-price option that breaks a stated requirement; cost optimization means cheapest that still meets every requirement, not cheapest overall.

The Google Cloud Well-Architected Framework defines six pillars: operational excellence; security, privacy, and compliance; reliability; cost optimization; performance optimization; and sustainability. The exam guide names familiarity with this framework as a key requirement for the role, so mapping each business goal to the pillar it stresses surfaces the non-functional requirements behind it.

Trap Counting five pillars or dropping sustainability; sustainability is a full, named pillar of the framework alongside the other five.

An architecture is judged against success measurements the business already tracks, such as key performance indicators (conversion rate, cost per transaction, p99 latency) and return on investment. Define the KPI and capture its baseline before launch so there is a measurable target, and design observability in from the start so the signal is actually collected. A solution that meets its functional spec but reports no agreed metric cannot prove value.

Trap Bolting on metrics after launch with no pre-launch baseline; without the baseline you cannot show the change a KPI is supposed to measure.

How a solution exchanges data with external systems is a requirement that constrains the network, messaging, and storage choices downstream, so decide it during requirements analysis. A synchronous request/response API suits an immediately-needed answer and is governed with an API management layer such as Apigee; asynchronous messaging with Pub/Sub decouples a fast producer from slower consumers and absorbs spikes; a scheduled batch transfer fits large, periodic, latency-tolerant loads.

Trap Reaching for a synchronous API to connect a fast producer to a slow or bursty consumer; that couples their rates, so asynchronous messaging is the pattern that absorbs the spike.

Data-movement needs (volume, frequency, one-time versus ongoing, on-premises source versus cloud-native) feed directly into later design choices, so capture the volume and latency tolerance early. A one-time bulk ingest of very large data is a transfer-appliance decision, while an ongoing low-latency event stream is a streaming-pipeline decision. The requirements stage's job is to make those numbers explicit, not to pick the tool.

Regulatory rules (HIPAA for health records, PCI DSS for card data, data sovereignty for a region-bound business) are non-functional requirements that constrain the design from the start, exactly like an availability target. Fold them in at requirements time rather than retrofitting, because a residency or compliance rule can rule out an entire region or service that an otherwise-cheaper answer relied on.

Trap Choosing the cheapest or most elegant option and adding compliance later; a data-residency rule can invalidate the region or service that option depended on, forcing a redesign.

The recognizable stem states a business outcome plus a constraint and asks for the option that best meets the requirements. Distractors typically each break one requirement: one is cheaper but misses the RTO, one is elegant but violates a compliance rule, one over-provisions for a need never stated. Eliminate every option that breaks a hard requirement, then pick the cheapest survivor.

A VPC network, with its routes and firewall rules, is global and not tied to any region, while each subnet lives in exactly one region. One VPC therefore spans every region you use: you add a regional subnet wherever workloads sit and they share one routing fabric over internal IP. This is why GCP needs no separate network per region the way some clouds do.

Trap Assuming you must build a separate VPC per region; the VPC is global and you only add a regional subnet per region.

A global VPC removes per-region network sprawl, but it does not auto-connect to a different VPC or to on-premises. Joining a separate network requires VPC Network Peering for VPC-to-VPC, or Cloud VPN / Cloud Interconnect for hybrid. Connectivity within one VPC is automatic over internal IP; connectivity between distinct networks is not.

Trap Assuming two separate VPCs can reach each other by internal IP without peering; distinct networks need an explicit connection.

Application Load Balancers are proxy-based Layer 7 load balancers with content-based routing. The global external variant fronts an internet-facing app with backends across multiple regions behind a single anycast IP. Choose it whenever the requirement is HTTP/HTTPS-aware routing for a public web app at global scale.

Trap Picking a Network Load Balancer for an HTTP app that needs URL or header-based routing; that L4 balancer cannot see Layer 7 content.

Network Load Balancers operate at Layer 4 for TCP and UDP. The passthrough variant forwards packets without terminating the connection, so it preserves the original client source IP and is regional in scope. Reach for it when the workload needs raw TCP/UDP or must see the real client IP, rather than HTTP-aware routing.

Trap Assuming an Application Load Balancer preserves the client source IP; as a proxy it terminates the connection, so the backend sees the proxy.

Private Service Connect (PSC) lets a consumer reach Google APIs or a published service over an internal IP inside its own VPC, so traffic stays off the public internet. It is service-oriented: consumer traffic can reach only the service's endpoint, not an entire network. That is the line between PSC and VPC Network Peering, which joins whole networks bidirectionally.

Trap Using VPC Peering to expose one managed service privately; peering grants reachability to the entire peered network, whereas PSC exposes a single endpoint.

GCP compute runs a ladder from most control to most managed: Compute Engine, GKE, Cloud Run, Cloud Run functions, ordered by degree of abstraction. Each step up removes operational work like patching, scaling, and capacity planning, so the default move is to pick the highest rung that still meets the workload's needs rather than defaulting to VMs.

Trap Defaulting to Compute Engine VMs for a stateless container app that Cloud Run would run with no infrastructure to manage.

Compute Engine gives full OS-level control, custom system packages, GPU and TPU attachment, no request timeout, and background processes. Google lists licensed and legacy software (relational databases, SAP HANA, ERP) as its use cases. It is the right rung when the workload needs the operating system itself, not just a place to run a container.

Cloud Run runs stateless, container-based HTTP services and APIs, scales to zero when idle (the last instance is removed), and bills only for what is used. It is request-driven, so it is the default for web apps and APIs but not for a long-running background daemon or a process that needs local persistent state.

Trap Putting a long-running background process or a stateful daemon on Cloud Run; it is request-driven, so use Compute Engine or GKE instead.

GKE is the choice when containerized workloads need full Kubernetes orchestration: many coordinated services, custom controllers, or complex multi-service deployments. It runs in two modes: Autopilot, where Google manages the node infrastructure and you pay for the resources your workloads request, and Standard, where you manage the node pools yourself. Autopilot is the recommended default.

Trap Reaching for GKE to run a single stateless service; Cloud Run carries no cluster to manage, so GKE only pays off when you actually need orchestration.

Cloud Run functions (formerly Cloud Functions) is the most managed compute rung: short, event-driven functions triggered by HTTP, Cloud Storage, or Pub/Sub events. It fits glue logic such as reacting to an uploaded file or a published message, not long-running services.

Spot VMs run on spare Compute Engine capacity at up to roughly 91% off on-demand, but Google can reclaim them at any time after a brief best-effort shutdown notice. They suit fault-tolerant, interruption-tolerant work like batch jobs and CI, where a lost node just reruns; they are the current generation of the older preemptible VMs. For steady, always-on workloads, a committed-use discount on reserved capacity is the cost play instead.

Trap Putting stateful databases or user-facing servers on Spot VMs; a reclaim can terminate them at any time and lose in-flight work.

Custom machine types let you set vCPU and memory independently rather than rounding up to a predefined shape, which removes waste when a workload's CPU-to-memory ratio does not match a standard size (for example memory-heavy but CPU-light). It changes only sizing, not the workload's behavior, so it trades a little sizing effort for a lower bill.

Cloud Storage's four classes (Standard, Nearline, Coldline, Archive) share the same low-latency access and eleven-nines (99.999999999%) annual durability, and differ only in cost and minimum storage duration: Standard none, Nearline 30 days, Coldline 90 days, Archive 365 days. Colder classes cost less to store but more to retrieve, so the class follows how often you read the data.

Trap Choosing Archive for data read often to save on storage cost; its higher retrieval cost and 365-day minimum make frequent access expensive.

Filestore is fully managed NFS file storage with POSIX semantics, file locking, and concurrent multi-writer access, mountable by many VMs or GKE pods at once. Reach for it when a lift-and-shift app or an HPC or rendering fleet needs a shared file system, which Persistent Disk (single-VM block) and raw Cloud Storage (object) cannot provide.

Trap Using Cloud Storage or a Persistent Disk where the requirement is a shared POSIX file system across many clients; that is Filestore's job.

Cloud SQL is managed relational (MySQL, PostgreSQL, SQL Server) for a regional transactional app and is the default relational store. Spanner is relational with horizontal, globally-distributed scale and strong consistency at up to a 99.999% availability SLA, but it carries that cost. Pick Spanner only when global scale or horizontal write scale is a genuine requirement.

Trap Reaching for Spanner for a small single-region app; Cloud SQL fits, and Spanner's global-scale design is unnecessary cost there.

Bigtable is a NoSQL wide-column store for high-throughput, low-latency single-keyed workloads such as time-series, IoT, and financial data, scaling to billions of rows. Firestore is a serverless NoSQL document database with realtime sync and offline support, aimed at mobile, web, and server apps. Match the data model: wide-column high-throughput points to Bigtable, document with sync points to Firestore.

Trap Choosing Firestore for a high-throughput time-series or IoT ingestion workload; that single-keyed high-write pattern is Bigtable's.

GCP's AI build options rise in effort and differentiation: a pre-trained API or Gemini model called as-is (no training, no differentiation), AutoML trained on your own data with minimal ML expertise, then custom training on Vertex AI for full control and differentiation. Pick the highest rung that meets the need, because each rung below custom training removes data-science and infrastructure work.

Trap Building a custom model when a pre-trained API or Gemini already meets the need; custom training only pays off when differentiation requires it.

Vertex AI is the unified platform for building, training, deploying, and serving models on GCP, and Gemini (Google's generative model family) is reached as a managed service through it. Model Garden is Vertex AI's catalog of foundation models spanning Google, partner, and open models, so an architect compares and deploys from one place. Agent Builder assembles agentic applications on top of these models.

AutoML trains a high-quality custom model on your own labelled data with minimal ML expertise and automated model-building. It fits the middle case: a pre-trained API is too generic for the task, yet there is no data-science team to do custom training. It needs your labelled data but not deep ML skills.

Cloud NAT lets VMs with no external IP make outbound connections (downloads, third-party APIs) while blocking all unsolicited inbound. It is a regional resource, so you need a gateway per region; for Shared VPC create it in the host project. Use manual NAT IP allocation with reserved static IPs when a partner must allowlist your egress addresses, and a custom subnet list to NAT only specific subnets.

Trap Cloud NAT is regional and outbound-only — it does not give inbound access, and one gateway does not cover other regions.

Autoclass automatically moves each object between Standard, Nearline, Coldline, and (optional terminal) Archive based on its actual access, with no manual policy, and waives retrieval and early-deletion fees. Choose it when access patterns are unpredictable or unmonitored. Use Object Lifecycle Management instead when access is well understood and you want explicit age-based transition or delete rules.

Trap Manual lifecycle rules still incur retrieval and early-deletion charges; only Autoclass removes them.

If multiple Object Lifecycle Management conditions match the same object at once, Cloud Storage performs only one action, and a Delete action always takes precedence over a SetStorageClass transition. To keep objects from being deleted before an intended transition, set the delete rule's age higher than the transition ages.

A bucket retention policy blocks deleting or overwriting objects until they reach the set age; locking it makes the policy permanent so the period cannot be shortened or removed by anyone, satisfying WORM and financial/healthcare retention mandates. Pair it with a colder storage class for cost and a lifecycle delete rule if objects should auto-delete after the period.

Trap An unlocked retention policy can still be removed or reduced by an admin — it must be locked to be immutable.

A dual-region (or configurable dual-region) bucket stores data redundantly across two named regions with automatic failover (RTO 0, no path change), useful when data must stay within a geography (e.g. the EU or NAM4 for the US). Turbo replication adds a 15-minute RPO for replication between the two regions.

Trap Turbo replication targets a 15-minute RPO between the two regions; standard dual-region replication is best-effort and can lag further behind.

Use pd-standard (HDD) for cheap sequential throughput, pd-balanced or pd-ssd for low-latency random database IOPS, and Extreme Persistent Disk (pd-extreme) to provision target IOPS independently of capacity for the highest-end databases. For pd-ssd/pd-balanced, IOPS scales with disk size and the VM's vCPU count, so resizing the disk (online, while attached to a running VM) raises its IOPS ceiling.

Use BigQuery for large-scale ad-hoc SQL, BI reporting, and complex joins over terabytes-to-petabytes — not Cloud SQL, which is for OLTP. Partition tables by a date column to prune scans on time-filtered queries and cluster on commonly filtered high-cardinality columns to cut data scanned, lowering both cost and latency.

Trap Cloud SQL handles transactional sub-second reads/writes; pushing analytical aggregations onto it instead of BigQuery is the wrong split.

Batch prediction runs asynchronously against the model resource without deploying an endpoint, reading from and writing to BigQuery or Cloud Storage — the cost-effective choice for large overnight jobs where latency does not matter. Deploy to an online endpoint (with autoscaling) only when each request needs a low-latency synchronous response.

Trap An always-on endpoint for a nightly batch job wastes money; batch prediction needs no deployed endpoint.

Node auto-provisioning extends the cluster autoscaler so GKE creates new node pools matching the hardware (CPU, memory, GPU/TPU) requested by pending Pods, instead of pre-defining every pool. You must set cluster-wide resource limits that cap total CPU, memory, and accelerators across all auto-provisioned pools.

Trap Plain cluster autoscaler only adds/removes nodes in existing pools; auto-provisioning is what creates the new pools.

The GKE cluster autoscaler will not remove an underutilized node if doing so would violate a PodDisruptionBudget or if a Pod carries cluster-autoscaler.kubernetes.io/safe-to-evict: false. Avoid restrictive PDBs on single-replica system Pods so they don't pin nodes, and reserve the annotation for Pods that genuinely must not be disrupted.

Trap A PDB on a single-replica Pod can block its node from being drained, keeping that node from scaling down.

Cold-start delays after idle periods come from scaling to zero; set minimum instances above zero to keep warm containers ready, and tune max concurrency so each instance absorbs more requests during spikes before new ones start. Startup CPU boost and caching connections in global scope further cut first-request latency.

Hierarchical firewall policies attached at the organization or folder level are evaluated higher in the resource hierarchy and cannot be overridden by lower levels. Use allow/deny to enforce mandatory baseline rules across all projects, and the goto_next action to delegate the remaining decision to lower-level VPC firewall rules. In Shared VPC, a VM interface on a host-project network is governed by the host project's hierarchical firewall policy rules, not the service project's.

Trap A lower-level rule cannot override an allow/deny set higher up — only an explicit goto_next at the higher level hands the decision down.

Base firewall rules on service accounts or IAM-governed secure tags rather than network tags so that assigning the identity requires IAM permission, preventing a developer from bypassing segmentation by tagging their own VM. Secure tags with network firewall policies enable identity-based micro-segmentation at the VM level.

Trap Network tags can be added by anyone who can edit the VM, so they don't stop a user from granting their VM unintended access; secure tags and service accounts are gated by IAM.

The on-premises connectivity choice splits first on the path. Cloud VPN builds encrypted IPsec tunnels across the public internet, so it is quick to deploy and needs no physical gear, but bandwidth is per-tunnel and limited. Cloud Interconnect carries traffic over a private physical circuit that never touches the internet, giving far higher throughput at the cost of physical provisioning. When a scenario forbids internet transit or demands tens of gigabits, the answer is Interconnect; when speed-to-deploy and encryption matter more than raw bandwidth, it is VPN.

Trap Reaching for Cloud VPN when the requirement says traffic must not cross the public internet; VPN tunnels are internet-bound, only Interconnect keeps the path private.

HA VPN is the recommended Cloud VPN product for new designs; Classic VPN is the legacy option and only reaches a 99.9% SLA. HA VPN earns a 99.99% availability SLA for most topologies when configured with two interfaces connected to two peer devices; other configurations drop to 99.9%. Throughput is per-tunnel, roughly 1 to 3 Gbps (up to 250,000 packets per second), so you add tunnels to scale, which is why VPN suits modest bandwidth and Interconnect wins for tens of gigabits.

Trap Choosing Classic VPN for a new high-availability connection; it tops out at a 99.9% SLA, while a two-interface HA VPN reaches 99.99%.

Both forms of Cloud Interconnect give a private path, and they differ only in who owns the last mile. Dedicated Interconnect runs your own 10-Gbps or 100-Gbps circuits into a Google colocation facility and is the most cost-effective choice for high bandwidth when you can reach one. Partner Interconnect uses a supported service provider to bridge the gap when you cannot reach a Google facility, with VLAN attachments from 50 Mbps to 50 Gbps. The deciding question is physical reach to a colocation facility.

Trap Recommending Dedicated Interconnect for an organization with no access to a Google colocation facility; that gap is exactly what Partner Interconnect exists to cover.

Dedicated Interconnect provisions physical circuits at 10 Gbps, 100 Gbps, or 400 Gbps, and you can bundle up to 8 circuits per Interconnect for higher aggregate capacity. You then carve each circuit into VLAN attachments sized anywhere from 50 Mbps to 50 Gbps, which is how you map the physical capacity to individual VPC networks. Knowing the circuit sizes separates Interconnect (tens to hundreds of gigabits) from VPN (a few gigabits per tunnel) in a bandwidth question.

When the far side is AWS, Microsoft Azure, OCI, or Alibaba Cloud rather than your data center, the product is Cross-Cloud Interconnect: a dedicated physical link that Google provisions to the other provider's network, at 10 Gbps or 100 Gbps (up to 400 Gbps on AWS and OCI). It is the multicloud answer. Dedicated Interconnect terminates at your own colocation equipment for on-premises reach, and VPN is internet-bound and bandwidth-limited, so neither fits a cloud-to-cloud requirement.

Trap Choosing Dedicated Interconnect to link Google Cloud to AWS; Dedicated Interconnect reaches your own colo, while Cross-Cloud Interconnect is the product built to land in another cloud provider.

Direct Peering and Carrier Peering connect your network to Google's edge to reach Google APIs and Google Workspace, but they give no access to VPC resources over internal IPs and carry no SLA. So if a scenario only needs Workspace or public Google API access, peering can suffice without standing up Interconnect or VPN. If it needs to reach resources inside a VPC, peering is the wrong tool; use Cloud Interconnect or HA VPN instead.

Trap Using Direct or Carrier Peering to reach VM instances inside a VPC by internal IP; peering only reaches Google APIs and Workspace, with no VPC access and no SLA.

VPC Network Peering links exactly two VPC networks and exchanges their subnet routes so resources communicate over internal IPs at same-network latency. The defining limitation is that peering is not transitive: if net-a peers with net-b and net-a peers with net-c, net-b and net-c still cannot reach each other. Every pair needs its own peering, so a many-network mesh becomes unmanageable, which is precisely when you move to Network Connectivity Center.

Trap Assuming that peering net-a to net-b and net-a to net-c connects net-b and net-c; peering is non-transitive, so that path does not exist.

Peered VPC networks stay administratively separate: peering exchanges subnet routes but does not share firewall rules, policies, or IAM, so each network keeps its own controls. Subnet ranges also cannot overlap, no range may match, contain, or fit within a range in the peered network. These constraints explain why peering is a routing link, not a merged network, and why security must be configured per network on both sides.

Trap Expecting firewall rules to carry across a peering so a rule on one side protects the other; peering exchanges routes only, each network enforces its own firewalls.

When more than two networks must all reach each other, Network Connectivity Center (NCC) is the answer. NCC is a hub-and-spoke orchestration framework: spokes attach to a central hub and communicate transitively through it, supplying the any-to-any reachability that VPC Peering cannot. A spoke can be a VPC network or a hybrid link such as an HA VPN tunnel, a Cloud Interconnect VLAN attachment, or a router appliance, so one hub becomes the backbone for VPC-to-VPC, on-premises, and multicloud traffic together.

Trap Adding more VPC peerings to give many networks full any-to-any reachability; peering is non-transitive, so the mesh grows quadratically. NCC's hub provides transitivity instead.

Shared VPC does not connect separate networks; it places resources from many projects onto one VPC owned by a host project. The host project owns the subnets, routes, and firewalls, and service projects attach to it and deploy resources that use internal IPs from that shared network. The purpose is administrative separation of duties: a central network team controls the network while application teams deploy into it without managing it, the least-privilege split for enterprise networking.

Trap Reaching for VPC Peering when the requirement is one centrally-administered network for many project teams; peering keeps networks separately administered, while Shared VPC centralizes control under a host project.

Shared VPC has firm structural limits worth memorizing. A service project can attach to only one host project at a time, a project cannot be both a host and a service project, and all projects must belong to the same organization. Establishing the configuration requires the Shared VPC Admin role at the organization level. These constraints often decide whether a proposed Shared VPC layout is even valid.

Cloud Load Balancing splits first on protocol layer. Application Load Balancers operate at Layer 7 and route HTTP and HTTPS by host, path, and headers, and can terminate TLS. Network Load Balancers operate at Layer 4 for TCP, UDP, and other IP protocols without reading the payload. So path-based or host-based HTTP routing requires an Application Load Balancer, while a raw TCP or UDP service requires a Network Load Balancer.

Trap Putting an Application Load Balancer in front of non-HTTP TCP or UDP traffic; Application LBs only handle HTTP and HTTPS, so Layer 4 traffic needs a Network Load Balancer.

Network Load Balancers come in two flavors. A passthrough Network Load Balancer forwards packets without terminating the connection, so the backend sees the original client source IP, which matters when the application logs or authorizes by client address. A proxy Network Load Balancer terminates the client connection and opens a new one to the backend, which is what you want for TLS offload on non-HTTP traffic but which hides the real source IP behind the load balancer.

Trap Choosing a proxy Network Load Balancer when the backend must see the real client IP; the proxy terminates the connection, so only a passthrough load balancer preserves the source IP.

Load balancers are offered as global or regional. The global external Application Load Balancer serves backends in regions around the world behind a single anycast IP address on the Premium network tier, so one address routes each user to the nearest healthy backend. A regional load balancer keeps backends in one region, which is the right call when data residency or a single-region service constrains the design. Choose global for worldwide reach, regional when geography is pinned.

The last load-balancer axis is exposure. An external load balancer accepts traffic from the public internet; an internal load balancer serves clients inside the VPC and cloud-adjacent on-premises clients reaching it over Cloud Interconnect or HA VPN. So an on-premises client arriving over Interconnect that needs to reach an HTTP service in your VPC by an internal address wants an internal Application Load Balancer, not an external one.

Trap Exposing a service that only serves VPC and on-premises clients through an external load balancer; an internal load balancer keeps it off the internet and still serves cloud-adjacent clients over Interconnect or VPN.

VPC firewall rules are stateful: when a connection is allowed in one direction, the return traffic for that connection is permitted automatically, so you never write a separate rule for replies. The network also ships with two implied rules you cannot delete, an implied allow-egress that lets instances reach any destination and an implied deny-ingress that blocks all inbound until a rule allows it. Rules carry a priority from 0 to 65535 where lower wins, defaulting to 1000.

Trap Writing a separate inbound rule to permit the replies to an allowed outbound connection; the firewall is stateful, so return traffic on an established connection is already allowed.

VPC firewall rules are scoped to a single network and are not shared across networks, even peered ones. When a control must apply across many networks at once, such as a company-wide block or a baseline health-check allow, hierarchical firewall policies attach at the organization or folder level and apply to every VPC beneath that node, which a project owner cannot override. Use hierarchical policies for centralized governance; keep per-VPC rules for network-specific needs.

Trap Trying to enforce an organization-wide firewall baseline by editing each VPC's own rules; that does not scale or prevent override. Hierarchical firewall policies at the org or folder level apply to every network below.

The strongest access control is to never expose a service publicly. Private Service Connect (PSC) lets a consumer reach managed services and Google APIs such as Cloud Storage and BigQuery over internal IP addresses inside their own VPC, with traffic staying entirely within Google Cloud, no public internet path and no VPC peering required. It is how you give an application private access to a published service or a Google API without widening the attack surface.

Trap Setting up VPC Peering or a public endpoint to let a VPC consume a managed service privately; Private Service Connect gives that private internal-IP access without peering and without exposing the service to the internet.

A Cloud Router in Regional dynamic routing mode (the default) only advertises and learns routes for subnets in its own region. When VLAN attachments or VPN tunnels must carry traffic to or from resources in a different region than the Cloud Router, switch the VPC network to Global dynamic routing mode so routes propagate across all regions.

Trap Regional mode is the default, so cross-region Interconnect/VPN silently fails until you flip the whole VPC to Global — it is a VPC-wide setting, not a per-attachment one.

Advertised route priority is the BGP MED value, and a lower MED is preferred. To spread egress across multiple Interconnect VLAN attachments or VPN tunnels, place them in the same region and advertise the same prefix with identical MED so Cloud Router uses ECMP (a five-tuple hash). For active-passive failover instead, give the primary a lower MED and the standby a higher MED.

Trap ECMP hashes per flow, so a single TCP stream always pins to one tunnel — lopsided traffic is not a misconfiguration; test with multiple concurrent flows.

For HA VPN and Dedicated Interconnect, the Cloud Router must use a private ASN (16-bit 64512-65534 or 32-bit 4200000000-4294967294) that differs from the peer ASN, since Google Cloud only runs eBGP. Partner Interconnect is the exception: its Cloud Router must use the Google-owned ASN 16550.

Trap Partner Interconnect rejects a private ASN — 16550 is mandatory there, unlike Dedicated Interconnect which takes your private ASN.

Network tags in a VPC firewall rule resolve only to instances in that same VPC, so they never match VMs reached through VPC Peering, and hierarchical firewall policies reject network tags entirely. To target VMs in those cases, use target service accounts or IAM-governed secure tags instead.

Trap A peered VM carrying the same network-tag string is not matched by the other network's rules, and a 'forgot the target tag' allow rule silently lets a lower-priority deny-all win.

Google Cloud's compute products order by abstraction from most control to most managed: Compute Engine (VMs), GKE (managed Kubernetes), Cloud Run (serverless containers), and Cloud Run functions (serverless functions). Each step up hands more operations (patching, node sizing, capacity) to Google, so the cost- and operations-optimal answer is the highest rung whose hard constraints you still satisfy. A real OS-level requirement pins you lower; the absence of one lets you climb.

Trap Reflexively choosing the most-managed option without checking constraints; a licensed OS or custom kernel forces Compute Engine no matter how convenient Cloud Run looks.

Cloud Run runs any container that serves requests, autoscales on incoming traffic, and scales to zero when idle so you pay only while serving. It is the default for stateless HTTP services and APIs with bursty or intermittent load, because an idle service costs nothing and there is no cluster to manage.

Trap Standing up a GKE cluster for a single stateless service just to get autoscaling; that adds cluster management Cloud Run removes.

Cloud Run functions (the current name for Cloud Functions) runs short snippets triggered by HTTP, Cloud Storage, or Pub/Sub events, with no server and no container build pipeline of your own. Reach for it when the workload is event glue rather than a long-running service; a full container service or VM is more than the job needs.

GKE is the rung for multi-service systems that need Kubernetes-level control: service meshes, complex networking, DaemonSets, GPUs, or fine-grained scheduling. If the workload is a single request-driven service, Cloud Run gives scale-to-zero with no cluster; reserve GKE for true orchestration needs so you do not pay the cluster-management cost for nothing.

Trap Choosing Cloud Run for a multi-service platform that needs a service mesh, DaemonSets, or fine-grained scheduling; Cloud Run runs containers but offers no cluster-level orchestration.

GKE Autopilot has Google provision, scale, secure, and upgrade the nodes, and bills only for the CPU and memory your running Pods request. Standard makes you size and manage node pools and pay per node whether or not Pods fill them. Autopilot is the recommended default for least operational overhead; pick Standard only when you need node-level control such as privileged DaemonSets, a specific machine family or sole-tenant placement, or GPU configurations Autopilot does not expose.

Trap Choosing Standard for least operational overhead; Standard hands node management and per-node billing back to you, the opposite of low-overhead.

Concurrency sets how many requests one Cloud Run instance handles at once: higher concurrency packs more requests per instance and lowers cost for lightweight requests, while concurrency of 1 isolates each request for CPU-heavy or non-thread-safe code. Minimum instances keeps a number of instances warm to avoid cold starts, trading the scale-to-zero saving for predictable first-request latency.

A managed instance group (MIG) builds identical VMs from an instance template and provides what a lone VM cannot: autohealing (recreate a VM that fails its health check), regional multi-zone placement (survive a zone failure), autoscaling, and automated rolling updates. Any production VM tier that must survive failure or absorb load belongs in a regional MIG behind a load balancer.

Trap Deploying hand-placed individual VMs for a tier that must self-heal or scale; an unmanaged VM has no autohealing, multi-zone spread, or autoscaling.

The MIG autoscaler scales the group toward a target on one signal: average CPU utilization, serving capacity reported by an attached load balancer, or a Cloud Monitoring metric such as queue depth. You set the target value plus minimum and maximum instance counts, and it adds or removes VMs to hold the target.

Autohealing uses an application-based health check to detect a VM that is running but not serving correctly, and recreates it automatically. This catches a hung-but-running instance that CPU-based scaling would miss entirely, so a scenario about a VM that keeps serving errors and should be replaced automatically points at MIG autohealing, not at the autoscaler.

Trap Relying on the autoscaler to replace a hung VM; CPU-based scaling does not detect an unhealthy-but-running instance, only autohealing's health check does.

Compute Engine custom machine types let you set vCPU and memory independently rather than rounding up to the next predefined shape, removing waste when a workload's CPU-to-memory ratio does not match a standard size. They change sizing only, not workload behavior.

Trap Rounding up to a larger predefined machine type to get enough memory; that overprovisions vCPU you do not need and pays for waste a custom type avoids.

Sole-tenant nodes are physical Compute Engine servers that host only one project's VMs, satisfying bring-your-own-license terms for per-core or per-processor software such as Windows Server, SQL Server, or Oracle that mandate dedicated hardware. They report the physical server ID a VM runs on so you can track core and processor usage for license compliance. Standard multi-tenant VMs are cheaper but cannot meet a dedicated-hardware license requirement.

Trap Putting BYOL per-core software on standard multi-tenant VMs; the license term requiring dedicated hardware is not met, regardless of cost.

Spot VMs use Compute Engine spare capacity for up to roughly 91% off on-demand, but Google can reclaim them at any time after a short best-effort shutdown notice; they are the current generation of preemptible VMs. That fits fault-tolerant, restartable work like batch processing, big-data jobs, CI fleets, and stateless web tiers behind a MIG, where a lost node just reruns. The same discount class is available as Spot Pods on GKE.

Trap Running a stateful, non-restartable job on Spot without checkpointing; one reclaim mid-task loses the in-flight state.

For a predictable workload you know will run continuously, a one- or three-year committed-use discount lowers the rate while keeping full availability. Spot targets interruptible work and can be reclaimed, so it is the wrong cost lever for steady or production load. Sustained-use discounts also apply automatically with no commitment the longer an eligible VM runs in a billing month, and they are mutually exclusive with committed-use on the same usage.

Trap Offering Spot as the way to save money on a steady, always-on or production-database workload; Spot can vanish on a reclaim, which that workload cannot absorb.

VM Manager's OS patch management reports patch compliance across the whole Compute Engine fleet and runs scheduled or on-demand patch jobs against many Linux and Windows VMs at once through the OS Config agent. The architecture answer for keeping a large fleet current is centralized patch orchestration, because SSHing into each VM to update it does not scale and drifts out of compliance.

Trap Managing patches by logging into each VM individually; it does not scale and leaves the fleet out of compliance, which is exactly what VM Manager exists to prevent.

On Cloud Run and GKE Autopilot, Google patches the underlying operating system, so OS patch management disappears from your operational burden. This is a concrete reason to climb the compute ladder when a workload allows it: the patching duty you would carry on Compute Engine VMs is one of the operations handed to Google on the managed rungs.

Google Cloud VMware Engine (GCVE) runs the native VMware stack (vSphere, vSAN, NSX) on dedicated bare-metal nodes inside Google Cloud, so an organization can lift a vSphere estate into the cloud without re-architecting and keep its existing VMware tooling, operations, and licensing. Choose it when the requirement is to preserve the VMware operating model rather than to modernize onto native compute.

Trap Choosing GCVE when the goal is to modernize onto native managed services; it keeps the old VMware operating model instead of moving off it.

GCVE runs VMware itself on dedicated nodes, whereas Migrate to Virtual Machines converts source VMs into native Compute Engine instances. The choice turns on intent: preserve the VMware stack and tooling (GCVE) versus land workloads as native VMs you then manage and optimize like any other Compute Engine instance (Migrate to VMs).

Trap Picking Migrate to VMs when the requirement is to keep running the native VMware stack; it drops the VMware layer by converting to Compute Engine VMs.

The cluster autoscaler's optimize-utilization profile removes underused nodes faster and bin-packs Pods onto already-loaded nodes, cutting cost at the price of slightly slower scheduling during spikes. The default balanced profile keeps more spare capacity for responsiveness.

Trap The profile only controls how aggressively nodes are removed; it does not protect critical Pods — annotate those separately so they are not evicted.

The cluster autoscaler will not remove a node whose Pods cannot be safely drained. A node stays up if a Pod has the cluster-autoscaler.kubernetes.io/safe-to-evict: false annotation, if a PodDisruptionBudget would be violated (e.g. maxUnavailable: 0), or if it runs kube-system Pods that lack a PDB. Loosen the PDB or add one to let scale-down proceed.

Trap Low utilization alone does not trigger scale-down — an idle node sticks around until every Pod on it is evictable.

Google Cloud security is defense in depth across four independent layers, and most PCA scenarios resolve once you name which layer owns the stated risk. Identity (IAM) answers who can act, the resource hierarchy plus Organization Policy answers what configurations are allowed, VPC Service Controls and context-aware access answer from where and under what conditions, and Cloud KMS, Secret Manager, and Sensitive Data Protection answer how the data itself is guarded. The layers are independent by design, so picking the layer first stops you from reaching for an IAM answer to a perimeter problem.

IAM always checks relevant deny policies before allow policies, so a matching deny blocks a permission no matter what role granted it, including an inherited Owner role. Allow policies are additive only and cannot subtract a permission, which is why removing access a principal inherits from a parent requires a separate deny policy rather than editing the allow. Deny policies attach at the organization, folder, or project level and support exceptionPrincipals so you can deny broadly while exempting break-glass accounts.

Trap Editing the allow policy to take away a permission a principal inherits from a folder; allow policies only add, so the inherited grant survives and you need a deny policy.

IAM grants roles, which are bundles of permissions, to principals rather than granting permissions directly. Basic roles (Owner, Editor, Viewer) are coarse and project-wide and are almost always too broad for production. Prefer Google's predefined roles scoped to a service and job, and drop to a custom role when even a predefined role grants more than the task needs. Least privilege is the recurring correct answer whenever a scenario says a principal can do more than required.

Trap Granting Editor to give a service write access; Editor is a project-wide basic role that also permits far more than the one resource, breaking least privilege.

The hierarchy has four levels: organization at the root, optional folders for grouping, then projects, then resources, and every resource except the organization has exactly one parent, making it a strict tree. Both IAM allow policies and Organization Policy constraints inherit downward, so where a project sits decides what it inherits. A project moved under a folder automatically picks up that folder's policies, which is why a clean hierarchy mirroring teams and environments is itself a control.

Organization Policy sets constraints on how resources can be configured and inherits down the hierarchy, where IAM sets who can take actions. They are complementary, not substitutes: IAM answers who, Organization Policy answers what. A constraint set at a folder applies to every project beneath it, so it is the tool for enforcing a rule across many projects at once rather than configuring each project by hand.

Trap Reaching for an IAM role to stop projects from creating resources in the wrong region; resource location is an Organization Policy constraint, not a permission.

When data must stay in a region or jurisdiction, set the resource-location constraint in Organization Policy at the org or folder level so every project below can only create resources in approved locations. Because the constraint inherits, you write it once high in the tree instead of per project, and new or moved projects pick it up automatically. This is governance, not an access decision, so no IAM change is involved.

An Organization Policy constraint can disable service account key creation across the hierarchy, turning no-downloaded-keys from a guideline into an enforced default. This pushes teams to Workload Identity Federation for external workloads and impersonation inside Google Cloud, removing the long-lived credential a leaked key represents. Pair it with break-glass exceptions only where a tool genuinely cannot federate.

A VPC Service Controls service perimeter draws a boundary around projects and the Google-managed services in them, allowing free communication inside and blocking all communication across the boundary by default. The point that makes it the exfiltration answer is that it is independent of IAM: a caller holding valid IAM permissions is still blocked when the request crosses the perimeter. Controlled exceptions are ingress and egress rules, and you build the perimeter in dry-run mode first to log what would be blocked before enforcing.

Trap Tightening IAM roles to stop a stolen credential from copying data to an outside project; the credential is still valid, so only a VPC Service Controls perimeter stops the cross-boundary API call.

VPC Service Controls and VPC firewall rules sound interchangeable but operate at different layers: a service perimeter controls API access to Google-managed services, while VPC firewall rules and hierarchical firewall policy filter packet-level network traffic between VMs. Per-instance network filtering is a firewall job; stopping data from leaving via a Google API is a perimeter job. Reading the layer keeps these apart.

Trap Using a VPC firewall rule to stop data exfiltration through the BigQuery or Cloud Storage API; firewalls do not see Google API access, so the perimeter is required.

IAP provides a central authorization layer at the application level, so a user must hold the right IAM role and satisfy context conditions to reach an HTTPS app, rather than relying on a network-level VPN or open firewall port. IAP also does TCP forwarding for SSH and RDP to VMs, removing the need for bastion hosts and public IPs. This is the practical form of zero trust: trust nothing by network location, verify identity and context on every request.

Trap Opening a firewall port or standing up a VPN to expose an internal app when the scenario wants zero-trust access; IAP authorizes at the application layer by identity and context instead.

Context-aware access lets you allow a request only when extra conditions hold, such as a managed device, a corporate IP range, or an approved region, layered on top of the IAM identity check. It is applied to applications through IAP and is bundled with endpoint and threat protections as Chrome Enterprise Premium (formerly BeyondCorp Enterprise). The model is that a valid identity is necessary but not sufficient; the access context must also pass.

Google encrypts all customer content at rest by default with AES-256, using envelope encryption where each data-encryption key (DEK) is wrapped by a key-encryption key (KEK), with no customer action required. With the default, Google owns and you cannot view or manage the KEK. The architectural decision is never whether to encrypt at rest but who controls the key, which is what CMEK changes.

Customer-managed encryption keys (CMEK) in Cloud KMS are keys you own, letting you set a rotation period, trigger rotations, and disable or destroy a key version. Disabling or destroying the CMEK makes the data it protected unreadable, which is the deliberate crypto-shredding technique for guaranteed data destruction. Reach for default encryption when there is no key-control requirement; reach for CMEK when compliance or revocation demands customer control of the key.

Trap Choosing CMEK to protect data while it is being processed in memory; CMEK controls keys for data at rest, but data in use needs Confidential VMs.

CMEK has protection-level options that form a ladder of control. Cloud HSM stores the key in a FIPS 140-2 Level 3 hardware security module when a hardware-backed key is mandated by policy or regulation. Cloud EKM (External Key Manager) keeps the key in an external system outside Google Cloud entirely, for when the key must never reside in Google. Plain CMEK is a software-protected key in KMS, sufficient when you need control but not a specific hardware or off-cloud requirement.

Trap Picking Cloud EKM when the requirement is only a hardware-backed key; EKM is for keys held outside Google, while a FIPS 140-2 Level 3 hardware key inside Google is Cloud HSM.

Secret Manager centrally stores API keys, passwords, and certificates, versions them, gates access with IAM, and logs access to Cloud Audit Logs. Putting a secret in source code, an environment variable, or a config file makes it leak with the repo or image, which is exactly the risk Secret Manager removes. The exam answer to where the database password lives is Secret Manager.

A downloaded service account key is a long-lived bearer credential and a top cause of cloud breaches when it leaks, so the design goal is to never create one. For a workload outside Google Cloud (on-premises, AWS, Azure, GitHub Actions, any OIDC or SAML 2.0 provider), Workload Identity Federation exchanges the external token at Google's Security Token Service for a short-lived federated token, with no key to store. External identities are managed in a workload identity pool, ideally one per environment.

Trap Downloading a service account key and shipping it to an external CI system because it looks simplest; the key is a standing credential, and federation gives short-lived tokens with nothing to leak.

Inside Google Cloud, attach a service account to the resource (VM, GKE workload, Cloud Run service) so it gets credentials automatically, or use service account impersonation so a principal temporarily acts as the service account and receives a short-lived token. Neither approach ever creates a key file. Impersonation also gives an audit trail of who acted as the service account, which a shared exported key cannot.

Binary Authorization is a deploy-time software supply-chain control that lets only container images conforming to a policy deploy to GKE, Cloud Run, and Cloud Service Mesh; non-conforming images are blocked and the violation is logged. Conformance is proven by an attestation, a signed statement from a trusted attestor that the image cleared a stage such as the approved build pipeline or vulnerability scanning. Run the policy in dry-run mode first to surface what would be blocked, mirroring the shift-left principle of catching defects before production.

Trap Relying on Artifact Analysis vulnerability scanning alone to keep bad images out of production; scanning reports findings but does not block a deploy, whereas Binary Authorization enforces the gate.

Cloud Audit Logs answer who did what, where, and when, and are the backbone of security auditing. Admin Activity audit logs are always written and cannot be disabled, while Data Access audit logs are off by default and must be explicitly enabled because they can be high volume. A scenario that needs to prove who read sensitive data, not just who changed configuration, requires turning on Data Access logs.

Trap Assuming Data Access logs already capture who read a dataset; they are off by default, so reads go unlogged until you explicitly enable them.

Separation of duties keeps one person or team from holding end-to-end control. Shared VPC implements it for networking: a host project owns the subnets, routes, and firewall rules while service projects attach and run workloads, so a central network team controls the network and workload owners cannot change it. The same principle at the policy layer gives the Organization Policy Administrator role to a governance team distinct from the project owners who deploy.

When you rotate a Cloud KMS key, the new key version becomes the primary version used for new encryption operations, but all enabled previous versions stay available so existing ciphertext keeps decrypting. Rotation never re-encrypts data already at rest, so to move existing data onto the new version you must explicitly decrypt and re-encrypt it (and only then disable or destroy the old versions).

Trap Assuming rotation automatically re-encrypts existing objects or that old versions are disabled — they remain active (and billable) until you act.

Cloud KMS supports a scheduled automatic-rotation period (e.g. 90 days) only for symmetric encryption keys. Asymmetric keys used for signing or encryption require manual rotation because extra steps are needed first — such as distributing the new public key — so you create new versions and promote them by hand.

Trap Setting an automatic-rotation schedule on an asymmetric key and expecting it to rotate — it silently won't.

Disabling a key version blocks all cryptographic use immediately and is fully reversible, so it is the right move for a suspected compromise. Destruction is delayed: a version sits in the scheduled-for-destruction state (30 days by default) and can be reverted to disabled with RestoreCryptoKeyVersion until that period expires. Enforce constraints/cloudkms.minimumDestroyScheduledDuration to require a longer minimum delay, and constraints/cloudkms.disableBeforeDestroy to force a version to be disabled before it can be scheduled for destruction.

Trap Destroying a key version to take it out of service — disabling is the reversible action; destruction risks permanent data loss after the grace period.

Single-tenant Cloud HSM provisions a dedicated cluster of HSM partitions for one customer's exclusive use, each partition cryptographically isolated from others, with a quorum approval model using asymmetric control keys for critical administrative operations, while keeping the standard Cloud KMS API (no code changes). Cloud KMS Autokey automates CMEK provisioning and creates keys at the HSM protection level by default (AES-256-GCM, one-year rotation); to create CMEK in locations where Cloud HSM is unavailable you must create the key manually.

Trap Reaching for multi-tenant Cloud HSM when the requirement is dedicated isolation plus quorum control — that calls for single-tenant Cloud HSM.

Security Command Center (Premium/Enterprise) detects threats with three distinct services: Event Threat Detection scans Cloud Logging for things like anomalous IAM grants and data exfiltration, Container Threat Detection analyzes GKE container runtime behavior, and Virtual Machine Threat Detection scans VM memory from the hypervisor (agentless) for malware such as cryptominers and rootkits. Match each requirement (logs / containers / VMs) to the corresponding service.

Trap Expecting one detector to cover all three layers — VM cryptomining needs VM Threat Detection, not Event or Container Threat Detection.

Cloud Armor Adaptive Protection (Cloud Armor Enterprise) applies machine learning to baseline traffic on a backend service, detect Layer 7 (HTTP) DDoS attacks, and generate alerts with attack signatures, confidence scores, and suggested WAF rules. Findings surface in the Cloud Armor dashboard, Security Command Center (Application DDoS Attacks category), and Cloud Logging; deploy a suggested rule in preview mode first and enable auto-deploy only once you confirm legitimate traffic is unaffected.

Trap Confusing Adaptive Protection (L7/HTTP application DDoS on load balancers) with advanced network DDoS protection, which guards passthrough Network Load Balancers and public-IP VMs.

Google recommends a single large common unified service perimeter over many small ones for the most effective exfiltration protection and lower management overhead; isolate any workload needing a service not supported by VPC Service Controls into a separate project (or move it out of the perimeter). With Shared VPC you must include the host project in the perimeter alongside the projects that belong to the Shared VPC — omitting the host project leaves their network endpoints outside the perimeter because the subnets belong to the host project.

Trap Putting only the service projects in the perimeter under Shared VPC — omitting the host project makes service-project VM traffic look external and gets blocked.

Split the pipeline by stage: Cloud Build is the continuous-integration service that runs your build config as steps in containers (fetching dependencies, running unit, static-analysis, and integration tests, and producing artifacts), while Cloud Deploy is the continuous-delivery service that promotes a release through an ordered sequence of target environments such as dev, staging, then prod. Cloud Deploy sits downstream of any CI tool that outputs container images, so the two pair naturally but are distinct responsibilities.

Trap Putting your unit or integration test suite in Cloud Deploy; Cloud Deploy runs Skaffold verify against a target, your behavioral tests belong in the Cloud Build steps.

A Cloud Build build is specified by a build config (typically cloudbuild.yaml) that lists steps, and each step runs in its own Docker container, so any tool packaged as an image can be a step. A build trigger starts a new build on code changes from Cloud Source Repositories, GitHub, or Bitbucket, and finished artifacts are pushed to Artifact Registry. That containerized-step model is why you can run tests, linters, and the build itself in one declarative file.

Cloud Deploy has four constructs. The delivery pipeline holds the promotion sequence (the order of targets). A target is one destination environment, a GKE cluster, a Cloud Run service, or a GKE attached cluster. A release is the rendered, deployable artifact built from your source, a skaffold.yaml, and specific container image references. A rollout binds a release to a target and performs the deploy. Promotion advances a release to the next target in the sequence.

To put a human checkpoint before a sensitive environment, set the target to require approval; promotion to that target then pauses until approved, and Cloud Deploy emits a Pub/Sub message an external system can consume. Use it on the prod target so no release reaches production unreviewed, while lower environments promote automatically.

A rollback in Cloud Deploy triggers a new rollout against the last successfully deployed release on that target, so recovery from a bad deploy is a first-class operation rather than a manual re-run of the old pipeline. Cloud Deploy also supports canary deployments, rolling a release out to a percentage of traffic before full promotion, so risk is contained on the way in and a rollback is the fast exit if it goes wrong. Together they keep time-to-restore short for deployment-caused incidents.

DORA research names four metrics: deployment frequency and lead time for changes measure velocity, while change failure rate and time to restore service measure stability. Read them as two pairs on purpose, because improving velocity while ignoring stability just ships failures faster. When a scenario asks whether a process change helped, the answer is to track these four, not commit counts or story points.

Trap Reporting only deployment frequency and lead time to claim success; without change failure rate and time to restore, a faster pipeline can be hiding a rising failure rate.

Binary Authorization enforces that container images deployed to a supported platform (GKE, Cloud Run, Cloud Service Mesh, Google Distributed Cloud) conform to a policy you define, admitting only images that carry the required cryptographic attestations and rejecting the rest. An attestation records the image's registry path and digest and is signed by a required signer, proving a specific image passed a specific step. It is a software-supply-chain control and integrates with Cloud Build and Artifact Analysis.

Trap Reaching for an IAM role or firewall rule to keep untrusted images out of prod; neither inspects image provenance at deploy time, which is what Binary Authorization checks.

Before enforcing, set the policy to dry-run so it logs which deployments would be blocked without actually blocking them. That lets you confirm the policy admits everything legitimate and catches everything it should before flipping to enforcement, avoiding an outage caused by a too-strict policy.

Trap Enforcing a brand-new Binary Authorization policy directly in production; a single overly strict rule then blocks legitimate deploys instead of just logging them.

Recovery time objective (RTO) is the maximum acceptable time the application can be offline; recovery point objective (RPO) is the maximum acceptable length of time during which data might be lost. Settle these business numbers first, then choose the cheapest DR pattern that meets both. The relationship is monotonic: the smaller (tighter) your RTO and RPO, the more your application costs to run.

Google's DR planning guide frames three patterns. Cold is backup and restore: recovery resources are provisioned only after a disaster, so it is cheapest and slowest. Warm keeps a scaled-down standby already running and scales it up on failover, the middle ground. Hot runs a full second deployment serving traffic, the fastest and the priciest. Match the pattern to the RTO and RPO rather than defaulting to the most resilient.

Trap Choosing a hot or active-active DR design when the stated RTO and RPO are loose; it meets the objective but over-provisions and overspends, where cold backup-and-restore would qualify.

When many teams need infrastructure, Service Catalog lets cloud admins curate a list of approved solutions (Terraform configurations, Deployment Manager templates, or reference links) that internal users discover and deploy themselves. Admins control distribution at different folder and project levels and bake in parameters and organization policies, so developers self-serve within guardrails the admin already approved. It is the middle path between a central-ops bottleneck and unrestricted access.

Trap Granting broad project owner or editor access so teams can provision freely; that removes the bottleneck but also the guardrails Service Catalog keeps, inviting drift and policy violations.

The operational excellence pillar's manage-incidents-and-problems principle says to restore service first, then run a retrospective that identifies the systemic contributing causes without indicting any individual, on the assumption people acted reasonably on the information they had. The deliverable is action items that reduce the likelihood or impact of recurrence, which is what drives change failure rate and time to restore down over time.

Trap Running a root cause analysis that assigns individual blame; it discourages honest disclosure, so the real systemic causes stay hidden and the incident recurs.

Testing software and infrastructure spans the pipeline in two distinct places. Pre-build validation runs as Cloud Build steps (unit, static analysis, integration), and a failing step fails the build so no artifact ships. The deploy-time gate checks provenance, not behavior: Binary Authorization admits only images with the required attestations. Knowing which gate a requirement maps to is the decision the exam tests.

Cloud Deploy relies on Skaffold for rendering, deployment, and verification, and a release is generated from your source plus a skaffold.yaml and references to specific container images. So a Cloud Deploy setup requires a skaffold configuration even though you may not run Skaffold by hand. The render step turns templates into the concrete manifest applied to each target.

Beyond a plain rollout, a Cloud Deploy delivery pipeline can run a canary that shifts traffic in phases (for example 25% then 50% then 100%); for GKE you declare a gatewayServiceMesh stanza referencing the HTTPRoute, Service, and Deployment rather than editing manifests. A canary needs an already-deployed version to split traffic against, so the very first release skips straight to the stable phase. Automation resources remove manual steps: promoteReleaseRule auto-promotes a release to the next target after a successful rollout, and advanceRolloutRule auto-advances a canary from one phase to the next after a wait time.

Trap A canary skipping to stable on the first deploy is expected, not a misconfiguration — there is no prior version to compare against.

When a requirement stresses reproducibility, peer review, drift detection, or rebuilding an environment identically, the answer is Infrastructure as Code (IaC), where you declare the desired end state and a tool converges to it idempotently. An imperative gcloud command or shell script performs a single action and can fail or duplicate on rerun, so it fits a throwaway task, not a managed environment. The deciding keywords are version-controlled, reproducible, and rebuild-from-scratch.

Trap Reaching for a gcloud shell script to stand up infrastructure that must be reproducible and reviewed; an imperative script is not idempotent and is not the version-controlled source of truth IaC gives you.

IaC is declarative: you describe the end state once and the tool computes the diff, so applying the same configuration twice changes nothing the second time. A gcloud command or client-library call is imperative, performing one action when run, which is why rerunning it can create duplicates or error. This idempotence is the property questions point at when they ask which approach safely converges an environment to a known state.

For Cloud Storage from the command line, use gcloud storage, not gsutil. Google states gsutil is not the recommended CLI: it is a legacy, minimally-maintained tool that does not support newer features like soft delete and managed folders, while gcloud storage is the successor and needs less manual tuning for fast transfers. When a question offers both gsutil cp and gcloud storage cp, the modern recommended choice is gcloud storage.

Trap Picking gsutil because its name looks like the canonical storage tool; it is the legacy CLI, and gcloud storage is what Google now recommends.

The Google Cloud CLI ships three command-line tools: gcloud for almost every service, gsutil as the original Cloud Storage tool, and bq for BigQuery. Mapping the service in the stem to its tool is the first step, then choosing the current recommended command (for storage, gcloud storage rather than gsutil).

gcloud auth login authenticates the gcloud tool itself as you, for running gcloud commands. gcloud auth application-default login instead writes a local Application Default Credentials (ADC) file that your locally-run application code reads, and it does not change which account gcloud uses. Use the application-default variant when the goal is to let code on your laptop authenticate to Google APIs without a key file.

Trap Running gcloud auth login expecting your application code to pick up the credentials; that only authenticates the gcloud tool, while application code needs gcloud auth application-default login to populate ADC.

Application Default Credentials (ADC) is the strategy the authentication libraries use to find credentials automatically from the environment, so the same application code authenticates unchanged on a laptop and in production. Cloud Client Libraries resolve credentials through ADC rather than each inventing its own scheme, which is why you configure auth once via the environment, not per-service.

ADC checks three locations in a fixed sequence: the GOOGLE_APPLICATION_CREDENTIALS environment variable, then the credentials from gcloud auth application-default login, then the service account attached to the running resource via the metadata server. Google explicitly notes the order is not related to the relative merit of each location, so being checked first does not make the env var the recommended source. The first hit wins, but the preferred source for in-cloud code is the attached service account.

Trap Reading the search order as a quality ranking and treating GOOGLE_APPLICATION_CREDENTIALS as the recommended source because ADC checks it first; the docs say order is unrelated to merit.

For code running on Google Cloud (GKE, Cloud Run, Compute Engine), attach a service account and let ADC find it through the metadata server; Google calls this the preferred method for finding credentials. Downloaded service account keys are discouraged because of the security risk of a leaked long-lived credential, so they are a fallback for the rarer off-Google case, not the default. The keyless attached-service-account pattern removes any key to manage or rotate.

Trap Exporting a JSON service account key and setting GOOGLE_APPLICATION_CREDENTIALS on an in-cloud workload; that ships a leakable long-lived key when the attached service account would authenticate with none.

For application code calling Google APIs, use the Cloud Client Libraries, which Google recommends where available: they are idiomatic per language and support gRPC. The older Google API Client Libraries provide access to the REST interface only, with no gRPC, and are auto-generated rather than idiomatic. Choose the legacy library only when a service offers no Cloud Client Library.

Trap Defaulting to the Google API Client Libraries; they are the legacy REST-only option, and Cloud Client Libraries are the recommended, gRPC-capable choice where available.

Terraform, Google's most commonly used provisioning tool, is the default IaC answer when the workflow is standalone and portable. You write HashiCorp Configuration Language (HCL) in .tf files, and the google and google-beta providers translate it to Google Cloud API calls (google-beta exists for beta APIs). The loop is terraform plan to preview the diff, then terraform apply to converge, producing a state file that tracks every resource.

Terraform's state file is the system of record mapping configuration to real resources, so a team must store it in a shared remote backend such as a Cloud Storage bucket rather than locally. A local-only state file blocks collaboration and risks corruption when two engineers apply concurrently, because each would work from a divergent copy of the truth.

Trap Leaving Terraform state on one engineer's machine for a team project; concurrent applies then race on divergent state and can corrupt or drift the deployment.

Config Connector is a Kubernetes add-on, a set of Custom Resource Definitions (CRDs) and controllers, that lets you define Google Cloud resources as Kubernetes objects in YAML (the Kubernetes Resource Model) and apply them with kubectl, with a controller continuously reconciling the real resource to match. It fits a team already running GKE that wants one control plane for apps and infrastructure, but it presumes a cluster to host the controllers, so it is overhead for a team with no Kubernetes footprint.

Trap Adopting Config Connector for IaC with no existing GKE footprint; you then run a cluster solely to host its controllers, overhead that Terraform or Infrastructure Manager avoids.

The gcloud beta emulators command group ships local emulators for Bigtable, Datastore, Firestore, Pub/Sub, and Spanner, so you can build and run integration tests offline against a local stand-in with no cost or network. The limit, and the trap, is that an emulator approximates the service and can miss quotas, IAM behavior, and edge cases, so final validation must still run against the real API before release.

Trap Treating an emulator as proof the integration works in production; it approximates the service, so behaviors and limits the live API enforces can be absent.

Cloud Shell is a browser-based environment where the gcloud CLI and common utilities are pre-installed, fully authenticated, and up to date, backed by a 5 GB persistent home directory that survives across sessions. It pairs a Terminal with a built-in Editor that has an integrated Cloud Code experience, so it suits quick interactive work or learning without any local setup.

Cloud Code provides IDE support across VS Code, IntelliJ, and the Cloud Shell Editor for the full development cycle of Kubernetes and Cloud Run applications, with run-ready samples, configuration snippets, advanced Kubernetes YAML support, and a Gemini Code Assist extension. It targets developers building and deploying container workloads, distinct from gcloud (commands) and the client libraries (runtime API access).

When an external workload (GitHub Actions, GitLab, Jenkins, Terraform Cloud, on-prem CI/CD) must act as a Google Cloud service account without downloaded keys, use Workload Identity Federation: the external identity provider's OIDC/SAML token is exchanged for short-lived Google Cloud credentials that impersonate the service account. This eliminates long-lived key files and is the recommended pattern for workloads running outside Google Cloud.

Trap Attaching a service account covers workloads running on Google Cloud; external/off-Google-Cloud systems use Workload Identity Federation instead.

When one Terraform configuration (e.g. networking) must expose values like VPC and subnet IDs to another configuration (e.g. application) managed separately, have the producing config declare those values as outputs in its root module and store state in a remote backend such as Cloud Storage. The consuming config reads them with the terraform_remote_state data source pointing at that backend. This is Google's recommended way to reference another root module's outputs.

Trap Reading or copying another team's state file directly to share its values, instead of exposing them as outputs consumed through the terraform_remote_state data source.

google_project_iam_member (and the matching _iam_member resources) add individual bindings additively without touching other roles. google_project_iam_policy is authoritative: it overwrites the entire IAM policy, removing roles that Google Cloud services manage automatically, which makes Terraform show constant IAM changes (drift) on every plan. Prefer the non-authoritative _iam_member resources for adding bindings.

Trap _iam_policy is authoritative and overwrites everything (causing drift); _iam_member is additive and only manages the binding you declare.

Google Cloud Observability is one suite of five products, each answering a different question. "Is it up and how full" is a metric in Cloud Monitoring; "what happened on this event" is a log in Cloud Logging; "where did latency go across services" is a trace in Cloud Trace; "which function burns CPU or memory" is a profile in Cloud Profiler; "how often is this exception firing" is Error Reporting. On the exam the skill is routing the scenario to the right product, not configuring it.

Google Cloud Observability is the current name for what was branded Stackdriver; the documentation still lives under the cloud.google.com/stackdriver path. Stems may use either name for the same metrics, logging, and tracing suite, so treat Stackdriver Monitoring/Logging as today's Cloud Monitoring/Cloud Logging.

When a request fans out across microservices and you need to find which hop ate the time, use Cloud Trace: it records the request as a trace of spans (one timed unit of work each) and shows aggregate latency on a heatmap. A Cloud Monitoring dashboard tells you the service is slow; only trace spans tell you where, so reach for Trace whenever the scenario crosses service boundaries.

Trap Reaching for a Cloud Monitoring latency dashboard to locate the slow hop; it shows that the service is slow in aggregate but not which downstream call is responsible.

When a service is CPU- or memory-bound and you cannot reproduce it locally, attach Cloud Profiler: it continuously samples production using statistical profiling and attributes CPU and heap usage to source-code lines. Collection overhead is under 5%, and amortized across replicas commonly under 0.5%, so it is safe to leave on always. It supports Go, Java, Node.js, and Python.

When the same exception keeps crashing an app and you want it counted and grouped without extra instrumentation, use Error Reporting: it reads log entries, recognizes stack traces, and groups errors by exception type and the top stack frames, then can notify you of new ones. It samples up to 1,000 errors per hour and estimates counts beyond that, so very high-volume counts are approximate.

Trap Building a custom log-based counter to detect duplicate exceptions; Error Reporting already groups by exception type and top frames out of the box.

Logs do not land anywhere by themselves: the Log Router evaluates sinks, and each sink has an inclusion filter plus a destination. A sink can write to a log bucket, a BigQuery dataset, a Cloud Storage bucket, or a Pub/Sub topic. This single model is the answer to most routing questions: to send logs somewhere new you create or edit a sink, not a per-log setting.

When logs must be queried with SQL or joined with other data, route a sink to BigQuery. When they must be archived cheaply for years or held for compliance, route to a Cloud Storage bucket. When they must stream into a third-party SIEM or custom pipeline, route to a Pub/Sub topic. The default keep-and-search destination is a Cloud Logging log bucket.

Admin Activity and other required audit logs go to the _Required bucket, which retains them for 400 days, a period fixed by Google and not configurable. Everything else lands in the _Default bucket at 30 days by default, which you can change. Knowing the 400-day fixed value is the testable specific behind most audit-retention questions.

Trap Assuming you can shorten or extend the _Required bucket's 400-day retention; it is fixed, so to keep audit logs longer you route them out via a sink.

A user-defined log bucket (and the _Default bucket in a project) can have its retention set anywhere from 1 day to 3650 days (ten years). Raise it toward 3650 for compliance holds, or lower it to control cost. The _Default starts at 30 days; only custom or _Default project buckets are configurable, while folder- and organization-level _Default buckets are not.

Audit logs sit in the fixed-400-day _Required bucket, so changing the _Default bucket's retention does nothing for them. To keep audit logs beyond 400 days you must route them via a sink to a custom log bucket (up to 3650 days) or to Cloud Storage. This is the classic audit-retention trap on the exam.

Trap Raising _Default retention to keep audit logs longer; audit logs live in _Required, so they are unaffected and still expire at 400 days.

A log-based metric converts log entries that match a filter into a metric you can chart and alert on like any other. A counter metric counts matching entries (for example, lines containing a specific error). A distribution metric extracts a number from each entry and builds a histogram (for example, parsing a latency value). This is how you page on "more than N of this error per minute" without a custom pipeline.

A Cloud Monitoring alerting policy bundles a condition (the metric, threshold, and aggregation), one or more notification channels (email, PagerDuty, Slack, Pub/Sub, Cloud Mobile App), and documentation that appears in the notification. When the condition is met it opens an incident and notifies the channels. Notification channels are reusable objects you attach to many policies.

Page on the four golden signals that map to user pain (latency, traffic, errors, saturation), not on raw causes like a single CPU spike. Tie the alert threshold to an SLO so a page means a real error-budget burn, which directly cures alert fatigue. Cause-level metrics belong on dashboards for diagnosis, not on pagers. This is the answer when a stem describes on-call drowning in pages with no user impact.

Trap Adding more per-resource metric thresholds to fix alert fatigue; that multiplies cause-level noise, while SLO-anchored symptom alerts reduce it.

Google SRE's four golden signals are latency (time to serve a request, tracked separately for successes and errors), traffic (demand on the system), errors (rate of failed requests), and saturation (how full the most-constrained resource is). They are the default set of things to monitor and alert on for any user-facing service, and the SRE-flavored questions expect you to name all four.

An SLI (service level indicator) is a quantitative measurement of one aspect of service behavior, usually a ratio of good events to total. An SLO (service level objective) is a target value for that SLI over a window, expressed in nines and set below 100% on purpose because perfect uptime is unattainable and not worth its cost. Cloud Monitoring service monitoring computes SLOs against the SLI.

An SLA (service level agreement) promises an SLO to a customer and carries a consequence such as a refund or credit if breached; the test for whether something is an SLA is "what happens if it is missed." Because a breach costs money, the SLA target is deliberately set looser than the internal SLO that protects it, giving the team headroom before the contract is at risk.

Trap Treating the SLA and the internal SLO as the same number; the SLA is set looser so the team has margin before a contractual penalty triggers.

The error budget is the allowed failure margin that falls out of the SLO: (1 minus the SLO) times the eligible events in the compliance period. A 99.9% SLO over a million requests yields a budget of 1,000 failures. It is the acceptable amount of unreliability a team may spend on shipping features and taking risk; while budget remains the team ships, once it is exhausted the policy freezes risky launches and pours effort into stability. This is the lever for balancing velocity against reliability.

A Cloud Monitoring SLO measures over a compliance period that is either rolling (a continuous trailing window of 1 to 30 days where the oldest data drops out each day) or calendar-based (a fixed week or month that resets on a boundary). Rolling gives a continuously updating view; calendar matches reporting cycles. Pick rolling for steady operational alerting, calendar when the SLO must align with monthly business reporting.

A request-based SLO is the ratio of good requests to total (for example, latency under 100 ms for 95% of requests). A windows-based SLO is the ratio of good time windows to total (for example, the 95th-percentile latency is under 100 ms for 99% of 10-minute windows). Windows-based smooths over bursty traffic and is the choice when you care that the service was healthy over intervals rather than per individual request.

A burn-rate alert fires when the error budget is being consumed faster than the SLO allows, rather than at a fixed metric threshold. This makes the page mean a real, accelerating reliability problem the user feels, and lets a slow steady burn pass without paging. It is the SLO-native form of symptom-based alerting and the recommended alerting strategy in Cloud Monitoring service monitoring.

To centralize observability across an estate, configure a Cloud Monitoring metrics scope: a scoping project can view metrics from many Google Cloud projects, and even AWS accounts, on shared dashboards. This is the standard answer when the requirement is one pane of glass across an organization's projects, rather than logging into each project separately.

Trap Creating a separate dashboard inside every project and switching between them; a single metrics scope already aggregates all of their metrics in one scoping project.

Cloud Monitoring uptime checks probe HTTP, HTTPS, and TCP endpoints from Google's global locations to confirm responsiveness, and you alert when a check fails. They are the answer for blackbox external availability monitoring of a public endpoint, complementing the whitebox metrics the service emits about itself.

Cloud Trace and the Cloud Observability agents prefer OpenTelemetry, the vendor-neutral instrumentation standard, over product-specific tracing SDKs. Instrumenting with OpenTelemetry (it speaks OTLP) means the same code survives a future tooling or vendor change, which is the recommended choice whenever a design must avoid lock-in to one tracing backend.

A log-based alerting policy fires a notification when a log entry matching its query filter appears, evaluating individual entries in near real time without first creating a metric. It is the right tool for rare-but-important events such as a specific error message or audit-log security event that needs immediate per-occurrence notification, and it can extract fields from the entry as labels for context.

Trap Reaching for a log-based metric plus a metric-threshold alert to get per-occurrence notification of a rare event; a metric counts and trends over time, while the log-based alerting policy fires immediate notification that one specific entry occurred.