Domain 1 of 6 · Chapter 3 of 5

Network, Storage & Compute Design

Three resource families, one decision each

Picture a scenario stem: a retailer wants a globally available storefront, a shared analytics file system for its data team, and a way to add product recommendations without hiring data scientists. Designing that solution comes down to three independent decisions, one per resource family: which network shape carries traffic, which storage shape holds each kind of data, and which compute platform runs each piece of code. The Professional Cloud Architect blueprint[1] groups them together for a reason: a real design touches all three, and the exam tests whether you can pick the right member of each family for a given workload.

The governing idea across all three is the same. Each family is a short ladder ordered by how much you manage versus how much Google manages, and the architect's job is to choose the most managed option a workload tolerates. On compute that ladder runs Compute Engine to GKE to Cloud Run to Cloud Run functions as Google orders them by degree of abstraction[2]. On AI it runs pre-trained API to AutoML to custom training. Storage is less a ladder than a set of shapes (object, file, block, database), but the same instinct applies: prefer the managed service whose access pattern matches the data, rather than rebuilding it on a raw VM.

A Virtual Private Cloud (VPC) is the network container those resources live in, Cloud Storage is the object store, and Vertex AI is the unified AI platform. Each of those terms gets its full treatment in the sections below; this page walks them family by family so a single workload's network, storage, and compute choices fit together rather than being made in isolation.

Cloud-native networking: VPC, load balancing, private access

The single rule that anchors GCP networking: a VPC network, with its routes and firewall rules, is a global resource, and each subnet inside it is regional. Google states it directly, that "VPC networks, including their associated routes and firewall rules, are global resources"[3] and that "subnets are regional resources." The practical consequence is that one VPC spans every region you operate in: you create a regional subnet wherever workloads sit, and instances communicate over Google's backbone using internal IP addresses on that one network. You do not provision a separate network per region. Reaching a different VPC, or on-premises, still needs an explicit connection (VPC Network Peering, Cloud VPN, or Cloud Interconnect); the global VPC removes per-region network sprawl, not the need to join separate networks.

Firewalls and Shared VPC

Firewall rules attach to the VPC and filter traffic to and from instances by IP range, tag, or service account. For organizations with many teams, Shared VPC centralizes that control: a host project owns the Shared VPC network, and service projects attach to it so their resources use the host's subnets. Google describes it as letting you "connect resources from multiple projects to a common Virtual Private Cloud (VPC) network"[4] over internal IP. The architectural value is separation of duties: a central network team manages subnets, routes, and firewalls in the host project, while workload teams manage only their instances in service projects. A project cannot be both a host and a service project at once.

Load balancing

Google Cloud load balancers split into two families, and the exam turns on picking the right one. Application Load Balancers are proxy-based Layer 7 load balancers[5] for HTTP and HTTPS, with content-based routing; the global external Application Load Balancer fronts an internet-facing app with backends in multiple regions behind one anycast IP (a single IP address Google advertises from every region, so clients reach the nearest healthy backend). Network Load Balancers operate at Layer 4 for TCP and UDP: the passthrough variant preserves the client source IP and is regional, while the proxy variant terminates connections. The decision is layer first (do you need HTTP-aware routing, or raw TCP/UDP?), then scope (global multi-region, or regional), then exposure (external or internal).

Private Service Connect

Private Service Connect (PSC) lets a consumer reach Google APIs or a published service over a private internal IP inside their own VPC, so traffic never traverses the public internet. Google frames it as service-oriented: it "allows consumers to access managed services privately from inside their VPC network"[6], where consumer traffic can reach only the service's IP address rather than an entire peered network. That is the line between PSC and VPC Network Peering: peering joins whole networks bidirectionally, while PSC exposes a single service endpoint unidirectionally. It is the answer when a question asks for private, granular access to a managed or third-party service without opening up full network reachability.

VPC network (global)one network, routes and firewall rules are globalSubnet (region A)Subnet (region B)InstanceInstanceInstanceInstanceregional resourceregional resourceinstances talk over internal IP on one global network
Scope model: one global VPC network holding regional subnets, each containing instances that share internal-IP connectivity.

Choosing storage: object, file, block, database

Storage selection follows how the data is accessed, not how large it is. Four shapes cover the field, and naming the access pattern in the question stem usually names the service.

Object storage: Cloud Storage

Cloud Storage holds unstructured objects (images, backups, logs, the raw layer of a data lake) addressed by key, not mounted as a file system. Its four storage classes (Standard, Nearline, Coldline, Archive[7]) share the same low-latency access and eleven-nines (99.999999999%) annual durability, and differ only in cost and minimum storage duration: Standard has no minimum (hot data), Nearline 30 days (about monthly access), Coldline 90 days (about quarterly), Archive 365 days (less than yearly). Colder classes cost less to store but more to retrieve, so the class follows access frequency.

File storage: Filestore

Filestore is fully managed NFS (network file system) file storage[8] that many clients can mount at once, with POSIX semantics, file locking, and concurrent multi-writer access. Reach for it when a lift-and-shift application or a high-performance computing (HPC) or rendering fleet needs a shared file system that several VMs or GKE pods read and write together, which a Persistent Disk (single-VM block) and raw Cloud Storage do not provide.

Block storage: Persistent Disk, Hyperdisk, Local SSD

Block volumes attach to a VM as raw disks. Persistent Disk and Hyperdisk are durable network block storage; a regional Persistent Disk replicates synchronously across two zones[9] so the data survives a zonal failure, while a zonal disk does not. Local SSD is physically attached to the host and is the fastest option but ephemeral, and Google warns that with Local SSD "the stored data is lost if the VM stops for any reason"; use it only for scratch, cache, or temporary data.

Databases

For structured records you query, pick the managed database that matches scale and model. Cloud SQL[10] is managed relational (MySQL, PostgreSQL, SQL Server) for a regional transactional app. Spanner[11] is relational with horizontal, globally-distributed scale and strong consistency at up to a 99.999% availability SLA, chosen over Cloud SQL only when global scale and high availability are real requirements. Bigtable[12] is a NoSQL wide-column store for high-throughput, low-latency single-keyed workloads such as time-series and IoT. Firestore[13] is a serverless NoSQL document database with realtime sync, aimed at mobile and web apps.

Mapping compute to a platform

GCP's core compute products form a ladder from most control to most managed, and Google orders them exactly that way: Compute Engine, GKE, Cloud Run, Cloud Run functions, ordered by degree of abstraction[2]. The architect's rule is to choose the most managed rung the workload tolerates, because each step up removes operational work (patching, scaling, capacity planning).

When each rung wins

Compute Engine gives OS-level control with custom system packages, GPUs and TPUs, no request timeout, and background processes, which is why Google lists licensed and legacy software (relational databases, SAP HANA, ERP) as its use cases. GKE runs containerized apps that need orchestration: many coordinated services, custom controllers, persistent volumes. Cloud Run runs stateless container-based HTTP services and APIs, scales to zero when idle, and bills only for what you use, but it is request-driven so it does not host long background daemons. Cloud Run functions is the most managed rung, for short event-driven work triggered by HTTP, Cloud Storage, or Pub/Sub events.

Cost levers on Compute Engine

Two levers cut Compute Engine cost without touching the workload's logic. Spot VMs run on spare capacity at up to roughly 91% off on-demand[14], but Google can reclaim them at any time after a brief best-effort shutdown notice, so they fit only fault-tolerant, interruption-tolerant work such as batch processing and CI; they are the current generation of the older preemptible VMs. 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 steady, always-on workloads, a committed-use discount on reserved capacity is the cost play instead, since Spot's interruption risk rules it out.

GKE modes

GKE offers two modes. In Autopilot, Google manages the node infrastructure[15], scaling, and security and you pay for the resources your workloads request; in Standard, you manage the node pools yourself. Autopilot is the recommended default when you want Kubernetes without running the node fleet.

Most controlMost managedCompute EngineVMs: OS control, GPUs, legacy appsGKEManaged Kubernetes: orchestrated containersCloud RunServerless containers: stateless HTTP, scale to zeroCloud Run functionsEvent-driven functions: HTTP, storage, Pub/Sub
GCP compute platforms ordered by degree of abstraction, most control to most managed (Google hosting-options guide).

GCP AI and ML solutions through Vertex AI

Vertex AI is the unified platform for building, training, deploying, and serving models on GCP, and the same effort-versus-differentiation ladder that governs every build-or-buy choice governs AI here. The rule: buy as high up the ladder as the requirement allows, because each rung below custom training removes data-science and infrastructure work.

The three rungs

Lowest effort is a pre-trained API or a foundation model called as-is: you send input and get output with no training and no labelled data of your own, but you get no differentiation because everyone shares the same model. AutoML sits in the middle, training a high-quality custom model on your own labelled data with minimal ML expertise, which fits when a generic API is not specific enough but there is no data-science team. Custom training on Vertex AI is the top rung: full control over architecture and data for genuine differentiation, at the cost of needing data scientists and substantial high-quality data.

Gemini, Model Garden, and Agent Builder

Gemini is Google's flagship family of generative AI models, reached as a managed service through Vertex AI rather than self-hosted. Model Garden is Vertex AI's catalog of foundation models, spanning Google's own models (the Gemini family), partner models, and open models, so an architect can compare and deploy a model from one place. Agent Builder assembles agentic applications (assistants and search experiences) on top of these models. For training and serving large models at scale, AI Hypercomputer is Google's integrated supercomputing stack of TPUs and GPUs.

Recognizing the question

The AI questions on this exam are almost always disguised build-or-buy decisions. A stem that says "limited ML expertise" or "no data-science team" is pointing at a pre-trained API or AutoML, not custom training. A stem that stresses "differentiation" or "proprietary model" is pointing at custom training on Vertex AI. A stem asking how to access Google's generative models is pointing at Gemini through Vertex AI, with Model Garden as the place to find and choose them.

Least effortMost differentiationPre-trained API / Geminicall as-is: no training, no own data, shared modelAutoMLtrain on own data, minimal ML expertiseCustom training on Vertex AIfull control, needs data scientists
Vertex AI build options by rising effort and differentiation: pre-trained API or Gemini, AutoML, then custom training.

Exam-pattern recognition

PCA network, storage, and compute questions are scenario-shaped: a fictitious business (Altostrat, Cymbal, EHR Healthcare, KnightMotives) states a requirement and you choose the service. The distractors are usually plausible members of the same family, so the win comes from matching one or two keywords in the stem to the deciding property.

Network patterns

"Internet-facing web app across multiple regions" points to a global external Application Load Balancer (Layer 7, anycast IP). "Preserve the client source IP" or "TCP/UDP, not HTTP" points to a passthrough Network Load Balancer (Layer 4). "Many projects, central network team, separation of duties" points to Shared VPC (host plus service projects). "Reach a managed or third-party service over a private IP without exposing the whole network" points to Private Service Connect, not VPC Peering, because peering joins entire networks while PSC exposes one service endpoint.

Storage patterns

"Shared file system mounted by many VMs or pods" points to Filestore (NFS), not Cloud Storage or Persistent Disk. "Rarely accessed, retain for years" points to a colder Cloud Storage class (Coldline or Archive) chosen by access frequency. "Globally distributed, strongly consistent SQL" points to Spanner; a plain regional relational app points to Cloud SQL, and reaching for Spanner there is the trap. "Survive a zonal failure" on block storage points to a regional Persistent Disk, never Local SSD, whose data is lost when the VM stops.

Compute patterns

"Stateless HTTP service, scale to zero, pay per use" points to Cloud Run. "Many coordinated containers needing orchestration" points to GKE. "Licensed software, OS control, GPUs, or a long background process" points to Compute Engine. "Fault-tolerant batch at lowest cost" points to Spot VMs, with the trap being to put stateful or user-facing work on Spot and lose it to a reclaim. "Right-size an oddly-shaped workload" points to a custom machine type rather than overpaying for the next predefined size up.

Mapping a workload to a GCP compute platform

Decision factorCompute EngineGKECloud RunCloud Run functions
Control vs managementMost control (full OS)Managed KubernetesServerless containersMost managed (functions)
Unit deployedVM imageContainer (orchestrated)ContainerSingle function
Scales to zeroNoNoYesYes
Best-fit workloadLicensed software, stateful or legacy apps, GPUsMany coordinated containers needing orchestrationStateless HTTP services and APIsShort event-driven glue (HTTP, storage, Pub/Sub)
Long-running background processYesYesNo (request-driven)No (event-driven)

Decision tree

Need OS control, GPUs,or licensed/legacy software?YesCompute Engine (VMs)NoMany coordinated containersneeding full orchestration?YesGKE (managed Kubernetes)NoLong-running HTTP service,or short event-driven task?HTTP serviceCloud Run (serverless)EventCloud Run functionsHTTP, storage, Pub/SubCost levers: Spot VMs for fault-tolerant batch; custom machine types to right-size
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

A VPC is a global resource; its subnets are regional

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.

Reaching another VPC or on-premises still needs an explicit connection

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.

Use a global external Application Load Balancer for internet-facing multi-region HTTP(S)

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.

9 questions test this
A passthrough Network Load Balancer is Layer 4 and preserves the client source IP

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.

1 question tests this
Private Service Connect reaches a service over a private IP without exposing the network

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.

5 questions test this
Choose the most managed compute rung the workload tolerates

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.

Use Compute Engine when you need OS control, GPUs, or licensed software

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.

Use Cloud Run for stateless HTTP services that should scale to zero

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.

Use GKE for many coordinated containers; Autopilot is the managed default

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.

Use Cloud Run functions for short, event-driven tasks

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.

2 questions test this
Run only interruption-tolerant work on Spot VMs

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.

5 questions test this
Use a custom machine type to right-size vCPU and memory independently

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.

Pick a Cloud Storage class by access frequency, not by data size

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.

3 questions test this
Use Filestore when many clients must mount one shared file system

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.

Choose Spanner over Cloud SQL only when global scale and HA are required

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.

1 question tests this
Bigtable for high-throughput wide-column; Firestore for document data

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.

Buy AI as high up the effort ladder as the requirement allows

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 AI platform; Model Garden catalogs the models

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.

Use AutoML when an API is too generic but you have no data-science team

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 gives private VMs outbound internet without exposing them

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.

7 questions test this
Enable Autoclass when access patterns are unknown; lifecycle rules when they are known

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.

12 questions test this
When two lifecycle rules fire, Delete wins over SetStorageClass

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.

1 question tests this
Bucket Lock with a locked retention policy is the WORM/immutable-storage answer

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.

7 questions test this
Dual-region buckets give automatic regional failover; turbo replication backs a 15-min RPO

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.

2 questions test this
Pick the Persistent Disk by IOPS need; PD performance scales with size and vCPUs

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.

7 questions test this
BigQuery is the analytics warehouse; partition by date and cluster by filter columns

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.

4 questions test this
Use Vertex AI batch prediction for accumulated data, online endpoints for low-latency

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.

7 questions test this
Node auto-provisioning lets GKE create right-sized node pools on demand

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.

4 questions test this
PodDisruptionBudgets and the safe-to-evict:false annotation block node scale-down

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.

4 questions test this
Set Cloud Run minimum instances above zero to kill cold-start latency

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.

4 questions test this
Hierarchical firewall policies enforce org/folder rules that lower levels cannot override

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.

4 questions test this
Use service accounts or IAM-governed secure tags for firewall micro-segmentation

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.

6 questions test this

Also tested in

References

  1. Professional Cloud Architect certification
  2. Choose an application hosting option
  3. Virtual Private Cloud (VPC) overview
  4. Shared VPC overview
  5. Cloud Load Balancing overview
  6. Private Service Connect
  7. Cloud Storage storage classes
  8. Filestore overview
  9. About Compute Engine disks
  10. Cloud SQL introduction
  11. Spanner
  12. Bigtable overview
  13. Firestore documentation
  14. Spot VMs
  15. GKE Autopilot overview