This guide maps out what you actually need to understand about Google Cloud to operate, architect, and secure production systems on it. It is not a certification cram sheet, but it happens to cover almost everything on Google's official Associate Cloud Engineer (ACE) exam guide, published at cloud.google.com/learn/certification/guides/cloud-engineer. If you are also pursuing that certification, this guide doubles as study material: each section below notes which ACE exam domain it maps to.

A note on staleness. Anywhere this guide adds a CLI command, a numeric limit, or a product specific beyond general concepts, that detail is flagged as something to verify in official docs. GCP renames products and shifts limits often enough that a confidently stated stale number is worse than an honest "check this."

0. GCP Services Overview: The Big Picture#

This section is scaffolding worth internalizing before the deep dives in Sections 1 through 9, so the individual services there land as parts of one system instead of a flat list to memorize.

0.1 What GCP Actually Is, Structurally#

GCP is a catalog of managed services, all running on Google's own global infrastructure (its network backbone and data centers). Every service you use sits inside a project (see the resource hierarchy in Section 1).

The hierarchy is the administrative skeleton; the services are what you actually build with.

Keep two things separate in your head as you read the rest of this guide: where something lives administratively (org, folder, project, IAM) versus what a service actually does (compute, storage, networking, and so on). These are different axes, and conflating them is a common source of confusion when a new service first shows up.

0.2 The Service Categories#

The table below is a mental map, not an official Google taxonomy. Google's own console groups things somewhat differently, and has reorganized its product groupings before, so treat this as a learning aid rather than something to quote back verbatim anywhere official.

0.3 How the Categories Connect: A Worked Example#

Think through a simple, familiar shape: a web app with a database, deployed and monitored. Building it touches every category above, roughly in this order:

1. Identity and security. You need a project, and IAM roles for yourself and any service accounts, before anything else works.
2. Networking. A VPC and subnet need to exist (often auto-created, though production setups use custom mode) so anything you deploy has somewhere to live on the network.
3. Compute. The app runs somewhere: Cloud Run for a stateless container, or Compute Engine or GKE if you need more control.
4. Database. The app talks to Cloud SQL (relational) or Firestore (document) over the VPC's private networking, ideally never over the public internet.
5. Storage. User-uploaded files go to Cloud Storage rather than local disk, since Cloud Run and GKE instances are stateless and disposable by design.
6. Load balancing and DNS. Traffic reaches the compute layer through a load balancer, with Cloud DNS resolving the domain to it.
7. Operations. Cloud Logging captures app and request logs automatically; Cloud Monitoring alerts on latency or error-rate spikes.
8. Developer tools. The container image was built by Cloud Build and stored in Artifact Registry before Cloud Run ever pulled it.

This chain, identity, then network, then compute, then data, then observability, is the order that matters when standing up real infrastructure, since each layer assumes the one before it is already correctly set up. It also roughly mirrors how Google structures the ACE exam guide's own Sections 1 through 5, which is not a coincidence: it is the same operational dependency order either way.

0.4 A Rule of Thumb for Navigating the Catalog#

GCP has over 100 products. A working senior engineer or DevOps practitioner does not need fluency with all of them, just the ones that show up repeatedly in real architecture: compute, storage, databases, networking, IAM, and operations, which is what Sections 1 through 9 cover in depth.

A useful filter: if a service appears in this guide, it is core enough to know well. If it is a specialized AI/ML platform, an industry-specific solution, or something you have not encountered here or in hands-on work, it is probably a "look it up when you need it" service rather than something to pre-learn.

If you are targeting ACE specifically, everything in Sections 1 through 5 maps to the official exam guide's bullet points; anything outside that is extra depth for real-world use, not exam-required.

0.5 Two Distinctions Worth Fixing Early#

"Serverless" is a spectrum, not a category. Cloud Functions and Cloud Run are both commonly called serverless, but they solve different shapes of problem (see the compute decision table in Section 4). Do not treat "serverless" as a single bucket when choosing between them.

"Database" and "storage" are not interchangeable. Cloud Storage holds objects and blobs (files). Cloud SQL, Firestore, and similar products hold structured, queryable data. A surprising number of real architecture decisions, and exam-style questions if that is relevant to you, hinge on picking the right one of these two buckets before even choosing a specific product within it.

0.6 Progressive Architecture Examples: Simple CRUD to Production-Grade#

The clearest way to see how these services relate is to watch a system grow. Each tier below adds something and explains why. Pay attention to what changes about identity, networking, and secrets as complexity increases, since those three threads are what "production-grade" really means.

What a Service Account Is#

A service account is an identity for a piece of software, not a person. A human logs into GCP with their own Google account, their own identity. A running application, for example a Cloud Run service, a VM, or a background worker, needs its own identity too, for whenever it calls another GCP service on its own, without a human approving each request. That identity is a service account.

Think of it like a work badge, except the badge is issued to a machine instead of an employee. The badge itself grants no access; it is just an identity. What that badge can actually open, which databases, which buckets, is decided separately, through IAM roles bound to it. That binding mechanism is covered next.

Concretely: a service account has an email-like identifier, for example cloud-run-api@my-project.iam.gserviceaccount.com. It gets attached to a resource, such as a Cloud Run service, so that whenever that resource calls another GCP API, it does so wearing that badge, not as whichever human happened to deploy the code.

The reason this matters before reading any further: almost every arrow in the diagrams below exists only because a service account is wearing a role that permits it. Every "own SA" label in a diagram, and every "who" column in the IAM tables that follow each tier, refers to exactly this concept. Without it, those labels and tables read as unexplained jargon rather than a specific, checkable fact about the system.

It also matters beyond this guide's diagrams: one of the most common real-world security mistakes in GCP is leaving a service account with far broader access than it needs, often because it was never deliberately created and is just the default one GCP provisions automatically. Section 2 covers that gotcha directly.

So every time a tier below says "its own service account," that means a separate, machine-only identity, distinct from any person, that this one piece of the system uses to authenticate itself.

Understanding IAM: The Foundation#

IAM is not a stop along the request path the way a load balancer or a queue is. It is closer to a bouncer's list sitting quietly behind every connection, deciding whether that connection is even allowed to happen.

Mechanically, IAM is three things glued together, shown below.

Who is a service account, as just described above. What they are allowed to do is a role, a named bundle of permissions such as "connect to this database" or "read from this bucket." Where that applies is a specific project, or one single resource.

Each three-part rule is called a binding. A resource can have many bindings stacked on it at once, from different identities.

So when a service account connects to a database, that connection only works because a binding exists behind the scenes: this one identity may connect to this one resource, and nothing else.

No binding, no connection. Remove the binding and the connection stops working; the request gets rejected before it ever reaches the resource. This is why, throughout this guide, IAM shows up as a table of bindings rather than as a box or arrow in any diagram. The diagram shows the intended data flow; the binding table shows what actually makes that flow legal.

Tier 1: Simple CRUD App#

This is the starting shape almost every backend project begins as: a client talks to a single API service, which talks to a single relational database. Nothing is split into multiple services yet, there is no async processing, and networking is left at GCP's defaults because there is no second service to segment away from.

The one thing worth getting right at this stage is identity: the service account attached to your compute should already be scoped to just what it needs, not because this tier is at risk, but because habits formed here carry into every tier after it.

• Compute. Cloud Run, or App Engine, hosting a stateless API.
• Database. Cloud SQL for relational data.
• Identity. One service account for the Cloud Run service, scoped to just the Cloud SQL client role, nothing more.
• Networking. The default (auto-mode) VPC is fine here; there is no segmentation need yet with a single service.

This is the "hello world" production shape. It works, but it is not yet hardened, and should not be mistaken for a finished design.

IAM in this tier. One binding makes the diagram's one arrow work:

That is the entire IAM setup at this stage: one identity, one role, one resource.

Tier 2: Add File Storage#

Almost every real app eventually needs to handle files: profile photos, PDFs, exports. The naive move is to write them to the compute instance's own disk, which breaks the moment you scale beyond one instance, since Cloud Run and GKE instances are stateless and disposable by design.

This tier introduces Cloud Storage as the dedicated place for file data, and signed URLs as the mechanism that lets clients talk to storage directly instead of routing large files through the API.

• Users upload files to Cloud Storage, never the app's own ephemeral local disk.
• Bucket-level IAM restricts the app's service account to that one bucket, and only the specific actions it needs (object create or read, not bucket admin).
• Signed URLs let clients upload and download directly to and from the bucket, so large files never round-trip through the app server.
• Lifecycle rules on the bucket handle aging or archiving files automatically.

IAM in this tier. One new binding gets added:

Scoping matters here. If this same service account had storage.objectAdmin at the project level instead of the bucket level, it could read or delete files in any bucket ever created in the project, not just this one.

Tier 3: Add Asynchronous Processing#

Some work is too slow to do inline with a user's request: resizing an image, sending an email, generating a report. Making the user wait on that work, or worse, risking the request timing out, is the problem this tier solves.

Pub/Sub decouples "the API accepted your request" from "the work actually got done," and a separate worker process picks up the message on its own schedule.

This is also the point where a single service account, abbreviated SA from here on in diagrams and tables, stops being enough and several appear, each narrower than the last, previewing the identity sprawl production systems have to manage deliberately.

• Pub/Sub acts as the queue: "resize this uploaded image," "send this confirmation email."
• A separate worker (another Cloud Run service, or a Cloud Function) subscribes and processes messages, decoupling slow work from the user-facing request path so the API responds fast and the heavy lifting happens elsewhere.
• The worker gets its own SA, scoped only to what it touches (the Pub/Sub subscription, maybe one bucket). This is where least privilege stops being theoretical and becomes an actual design decision with multiple identities to manage.
• Dead-letter topics catch messages that fail processing repeatedly, so bad data does not loop forever.

IAM in this tier. A second identity enters, and the two identities need different, non-overlapping bindings:

Notice cloud-run-api has no binding at all on the subscribe side, and worker-sa has no binding on the publish side. Each identity can only do the one half of the conversation it is actually responsible for.

Tier 4: Multiple Services, Higher Scale#

As the product grows, a single monolithic API service becomes a bottleneck, both technically (one slow endpoint can affect everything) and organizationally (multiple teams stepping on the same codebase). This tier splits the system into independent services by business domain, each with its own identity and its own blast radius if something goes wrong.

A cache gets introduced because hitting the database for every read stops scaling, and the network itself needs deliberate structure for the first time: separate subnets by tier, not just everything in one flat network.

• The app splits into distinct services (auth, orders, notifications, and so on), each with its own service account and its own least-privilege scope. There is no longer one service account that can touch everything.
• Memorystore (managed Redis or Memcached) is added as a cache in front of the database for read-heavy paths.
• Database scaling decision point: read replicas on Cloud SQL, or a move to Spanner if the workload genuinely needs global horizontal scale and strong consistency.
• Custom-mode VPC starts to matter: separate subnets by tier (an app subnet versus a data subnet), with firewall rules restricting which tier can talk to which.
• A load balancer sits in front of the services, possibly across regions.

IAM in this tier. Three identities now, and this is where least privilege starts doing real work:

None of these three service accounts has any binding granting access to another service's resources. If Orders is compromised, the attacker inherits exactly Orders' bindings, not Auth's, not Notifications'. That containment is the entire point of splitting identities in the first place.

Tier 5: Production-Grade, Security-First#

Nothing structurally new gets added at this tier so much as everything from Tier 4 gets hardened. The services, the database, the load balancer are all still there.

What changes is that every implicit trust assumption from earlier tiers gets made explicit and constrained: compute no longer has a public IP by default, credentials no longer live in code, every identity is deliberately scoped rather than inherited from a default, and every environment is isolated enough that a breach in staging cannot touch production.

Separate GCP projects also exist per environment (dev, staging, prod), not shown above since it is a project-level boundary around the whole diagram rather than a component within it.

Identity and access

• No workload uses a default service account; every service has a purpose-built one.
• Custom IAM roles replace predefined roles wherever predefined is broader than necessary.
• Impersonation and short-lived credentials replace exported key files. If a key must exist at all, it is tightly scoped and rotated.
• Separate projects per environment (dev, staging, prod), rather than one project with environment labels, isolate blast radius if one environment is compromised.

IAM in this tier. The same three service accounts as Tier 4, but every binding gets narrower, and one new kind of binding appears:

Orders cannot read Auth's secrets. Even though both secrets live in the same Secret Manager instance, each service account's binding is scoped to only its own secret.

A cross-project binding, for the first time. The log sink writing into a separate logging project is IAM working across a project boundary, a very normal pattern once you centralize anything: logging, security scanning, or billing exports.

Whoever manages the VPC and firewall rules holds a human role like roles/compute.networkAdmin at the project level. This is deliberately not one of the service accounts above; network configuration and application identity are kept as separate concerns, so a compromised app service account cannot also rewrite firewall rules.

Secrets and configuration

• Application secrets (database passwords, API keys, tokens) live in Secret Manager, never as environment variables baked into a container image or committed to source.
• Config values differ per environment and project, and are never shared between production and non-production.

Secret Manager and the ACE exam. Secret Manager is not explicitly named in the official ACE exam guide's bullet points, but it is a foundational production practice and a very plausible "where should this credential be stored" scenario. Worth knowing conceptually even though its exact exam weight is unclear.

Networking

• Backend compute has no public IPs; Cloud NAT handles any outbound-only internet access it needs.
• Firewall rules target service accounts rather than broad IP ranges or tags wherever possible, which is more precise and harder to accidentally over-scope.
• Cloud Armor sits in front of the load balancer for WAF and DDoS protection.
• VPC Service Controls and Private Service Connect restrict data movement between services and help prevent exfiltration paths.

Data protection

• Encryption at rest is on by default in GCP; customer-managed encryption keys (CMEK) apply if compliance requires control over the keys themselves.
• Data Access audit logs are explicitly enabled for sensitive datasets. Recall from Section 9 that these are off by default, unlike Admin Activity logs.
• Backup and disaster recovery processes are actually tested, not just configured and forgotten.

Operations and detection

• Log sinks centralize logs into a dedicated logging or security project rather than leaving them scattered per project.
• Monitoring alerts cover security signals too, such as unexpected IAM policy changes or spikes in denied requests, not just performance metrics.
• Security Command Center gives a unified view of misconfigurations and threats across projects.

CI/CD

• The Cloud Build service account is scoped down; it should not have production deploy rights unless the pipeline is specifically gated for it.
• Artifact Registry vulnerability scanning runs on container images before they are allowed to deploy.

Tier 6: Adding AI Capabilities, RAG, Agents, and Document Ingestion#

This tier does not replace anything from Tiers 1 through 5; the auth, orders, and notifications backbone stays exactly as it was.

What gets added is a parallel system: a pipeline that turns raw documents into searchable vector embeddings, and a separate query path where an agent retrieves relevant embeddings and calls a model to generate a grounded response.

This deserves its own tier rather than folding into Tier 5 because it introduces failure modes production engineers have not typically had to think about before: cost per request that can spike unpredictably based on prompt or context size, and an audit trail requirement (what did the model see, what did it say) that does not map onto traditional access logs.

A naming note. Google has been actively reorganizing this part of its product lineup. What was "Vertex AI Agent Builder" is being folded into a broader Gemini Enterprise Agent Platform, with sub-components named Agent Garden, ADK (Agent Development Kit), MCP Servers, RAG Engine, Vector Search, and Search. This shift appears to have happened around mid-2026, recent enough that these exact names should be treated as current but not fully settled. Confirm against Google's live documentation before designing against them.

Document ingestion

• Cloud Storage object-created events trigger a worker (a Cloud Run Job or Function) that parses and chunks the document, then generates embeddings, the same event-driven shape as Tier 3's queue processing with a different payload.
• Storage choice for embeddings is a real trade-off, not just a preference. pgvector on AlloyDB or Cloud SQL keeps embeddings next to existing relational data (simpler ops, good up to moderate scale, and lets you join vector similarity with normal SQL filters like price or category in one query). Vertex AI Vector Search / RAG Engine is the managed option built for billions of vectors and integrates directly with the Agent Platform's retrieval APIs. Reach for the managed option once pgvector's scale or latency stops being sufficient, not by default.

Agent orchestration and the query path

• The agent orchestrator is its own service with its own service account, scoped to exactly the vector store, tools, and APIs it is allowed to touch, the same least-privilege discipline from Tier 4 and 5 applied to a new kind of workload.
• MCP (Model Context Protocol) servers are how agents connect to external tools (BigQuery, internal APIs, third-party systems) in a standardized way. Worth knowing the term even outside deep agent development, since it is becoming the default integration pattern.
• Calling a managed model API (Gemini via the Agent Platform) requires zero GPU infrastructure of your own; it is metered API usage, not compute you provision.

IAM in this tier. Two new identities, split by action on the same resource rather than by service:

Same resource, opposite permissions. These two service accounts touch the same vector store but have opposite permissions on it: the ingestion worker can write but not retrieve, and the agent can retrieve but not write. That is least privilege applied by action, not just by service. "Can write" and "can read" are different privileges even when it is the same resource and arguably the same team owns both pieces.

Where GPU and Kubernetes decisions actually show up here. Self-hosting an open-weight model, for cost, latency, or data-residency reasons, is the one case where this tier pulls in Section 4's compute decision again. See Where Docker and Kubernetes Actually Enter This Progression below for how that trade-off has shifted with Cloud Run GPU support.

Security specific to this tier

• Prompt and response audit logging. Log sinks need to capture what the model was shown and what it returned, not just standard request and response metadata. This is a new logging category, not an extension of an existing one.
• Data governance on ingestion. PII and sensitive-data handling has to happen before embedding, since redacting after the fact does not help; the embedding itself already encodes the sensitive content.
• Cost controls. Rate limiting and per-request cost monitoring matter more here than almost anywhere else in this guide, since a single malformed or adversarial prompt can be far more expensive than a single malformed API call elsewhere in the system.

Where Docker and Kubernetes Actually Enter This Progression#

Looking back across all six tiers, it is worth naming a pattern explicitly: people often assume Docker and Kubernetes get "added" at some specific tier, like a feature you turn on. In practice it is more about when you start needing to think about them directly.

Docker is already there from Tier 1, you just do not see it. Docker is a way of packaging an app with everything it needs (code, dependencies, settings) so it runs the same way anywhere. When you deploy to Cloud Run, Google quietly builds that package for you behind the scenes, even if you never write a line of Docker configuration yourself.

You start needing Docker directly once you need something custom: a specific system package, an unusual dependency, or wanting your laptop to run the exact same setup as production. For most teams, that moment arrives by Tier 2 or 3, not far in the future.

Kubernetes, via GKE, usually shows up around Tier 4. Kubernetes exists for when you need more hands-on control over how containers run: coordinating several containers together, or handling workloads that do not fit the simple "get a request, send a response" pattern Cloud Run is built for.

That need tends to appear once you have split into multiple services, which is Tier 4. It is not a more advanced version of Cloud Run; think of it as a different tool for a different job, manual control instead of automatic simplicity.

AI workloads, as seen in Tier 6, change this less than people expect. Running your own AI models used to force a move to Kubernetes sooner, since that usually meant needing a GPU. That is less true now: Cloud Run can attach a GPU directly to a service, so serving a single AI model no longer requires Kubernetes at all.

GKE still makes sense once you are juggling several models at once, doing heavy batch processing, or need fine-grained control over how GPUs get shared. For the common case of serving one model, Cloud Run with a GPU is often enough on its own.

Check regional availability first. GPU support on Cloud Run is still expanding, and a few regions currently require special access. Confirm availability for your region before planning around it.

0.7 The Pattern Underneath All Six Tiers#

Three things escalate together as the architecture matures, and this is the lens worth carrying into both real design reviews and exam scenario questions:

1. Number of distinct identities. More services means more service accounts, and each one should get narrower, not broader, as the system grows.
2. Network segmentation. From everything in one default network, to explicit subnets, private IPs, and controlled egress.
3. Secrets and config separation from code. From maybe-hardcoded-and-fine, to fully externalized and access-controlled.

Tier 6 adds a fourth axis specific to AI workloads, worth tracking separately: cost and behavior unpredictability per request. Traditional compute costs scale roughly with traffic volume, but model-calling workloads can spike in cost or produce unexpected output based on input content alone, which is why rate limiting and audit logging get called out as their own concern rather than folded into Tier 5's general security section.

When a real system's "before" state has something wrong with it, or an exam question describes one, it is very often pointing at one of these axes.

1. Foundations: Resource Hierarchy and IAM#

This section maps to ACE exam domain 1, roughly 20% weight, but it is the layer every other section in this guide depends on, certification or not. Get this wrong and everything above it inherits the mistake.

1.1 Resource Hierarchy#

The structure is Organization, then Folder, then Project, then Resource. Folders are optional, used to group projects by team, environment, or business unit. Every resource belongs to exactly one project, and every project can link to one org (or none, for personal accounts).

What each level actually is#

The Organization node is created automatically when a domain is associated with Google Workspace or Cloud Identity. It is the root, and it is what makes org-level policy and centralized billing possible. Personal Gmail-based accounts have no org node, which is why hobby projects behave differently from enterprise ones: there is nothing above the project to attach policy to.

Folders group projects and can nest inside other folders, which lets the hierarchy mirror how a company is actually organized (by department, then by team, then by environment). Nesting depth is limited, so very deep trees are not an option; verify the current maximum depth in docs if a design depends on it.

Projects are the real unit of work in GCP. Almost everything meaningful attaches to a project: APIs get enabled per project, billing links per project, quotas apply per project, and resources live inside one. A project carries three separate identifiers, and confusing them is a common early mistake.

Project IDs are globally unique and permanent. The ID has to be unique across all of GCP, not just your organization, and it cannot be changed after creation. Deleting a project does not immediately free its ID for reuse either. Pick a naming convention before creating projects at scale, because renaming later is not an option.

Resources are the individual things: a VM, a bucket, a Cloud SQL instance, a Pub/Sub topic. These sit at the bottom and inherit everything applied above them.

Project lifecycle#

Projects are not deleted instantly. Deletion moves a project into a pending-deletion state for a grace period before resources are permanently destroyed, which gives an escape hatch for accidents. Verify the current grace period length in docs; it has been on the order of a month, but treat the exact number as something to confirm rather than rely on.

For projects that must never be deleted accidentally, a lien can be placed on them, which blocks deletion until the lien is explicitly removed. This is worth knowing about for production projects, since it defends against a class of mistake that IAM alone does not prevent: someone with legitimate delete permission acting carelessly.

How inheritance actually works#

IAM policies attached at any level inherit downward. A role granted at the Engineering folder above applies to every project and resource beneath it, unless a more specific binding at a lower level adds even more access.

Inheritance is additive only. A more restrictive policy lower in the hierarchy cannot revoke a permission granted higher up. Deny policies are a separate, newer mechanism; verify current behavior in docs, since this area has evolved.

A practical scenario worth internalizing: a principal has role X at org level and role Y at project level. What can they do at the resource? The answer is the union of permissions, not whichever role is more restrictive.

For example, imagine a principal is granted roles/viewer at the Organization level in the diagram above, and separately granted roles/editor on just the web-app-prod project. At any resource inside web-app-prod, that principal effectively has both roles combined: viewer access everywhere in the org, plus editor access specifically within web-app-prod. There is no mechanism at the project level to strip away the org-level viewer grant; inheritance only ever adds.

This has a direct design consequence: grant broadly only what is safe everywhere. An org-level grant is the widest possible blast radius, so org-level bindings should be reserved for genuinely org-wide needs (security auditors, billing administrators) rather than convenience.

Why the hierarchy shape matters in practice#

Two common structural patterns, and what each buys:

Most real organizations combine both: a folder per team, and within it, one project per environment.

1.2 Organization Policies#

Org Policy is a distinct system from IAM. IAM controls who can do what; Org Policy controls what is allowed to exist or happen, regardless of identity.

That distinction is worth sitting with, because it is the most commonly confused pair in this whole area. IAM answers "is this principal permitted to make this call?" Org Policy answers "is this configuration permitted to exist in this part of the hierarchy at all?" A principal with full Owner rights still cannot create a resource that an org policy forbids.

How constraints work#

An org policy applies a constraint at the org, folder, or project level, and it inherits downward like IAM does. Constraints come in two broad shapes:

Policies can be inherited, overridden at a lower level, or merged with a parent's policy, depending on how the policy is configured. That override capability matters: a strict org-wide default can be relaxed for one specific project that has a documented reason, rather than forcing the whole org to the loosest common denominator.

Constraints worth knowing by purpose#

Rather than memorizing constraint strings, it helps to know what categories of control exist, since that is what a real design conversation needs:

• Location restriction. Force resources to be created only in approved regions, typically for data residency or compliance reasons.
• External IP restriction. Prevent VMs from getting public IP addresses, which pushes a project toward the private-networking pattern described in Tier 5.
• Service account key restriction. Block creation of downloadable key files, which forces teams toward impersonation and short-lived credentials instead.
• Uniform bucket-level access. Require Cloud Storage buckets to use IAM only, disabling legacy per-object ACLs.
• Service restriction. Limit which GCP services can be enabled at all in a given part of the hierarchy.

Verify exact constraint identifiers before using them. Constraint names are specific strings, for example in the form constraints/compute.vmExternalIpAccess, and Google adds and occasionally reworks them. Look up the current list in official docs rather than trusting a remembered string.

Why this is a security control, not just a guardrail#

Org Policy is the layer that makes a security posture actually enforceable rather than aspirational. Telling a team "please do not put public IPs on production VMs" is a convention that erodes. Setting the constraint means the API rejects it, every time, including for an automated pipeline that would otherwise do it silently.

1.3 IAM Role Types#

A role is a named bundle of individual permissions. Permissions themselves are granular strings in the form service.resource.verb, for example compute.instances.start. Nobody grants individual permissions directly in practice; roles exist so that a sensible group of permissions can be granted as one unit.

Why basic roles are a trap#

The three basic roles predate the rest of IAM and are extremely wide. Viewer can read almost everything in a project. Editor can modify almost everything. Owner can do all of that plus manage IAM itself, meaning an Owner can grant themselves or anyone else any further access.

They are convenient during a weekend prototype and dangerous in anything shared. The specific problem: they are defined in terms of "everything in the project," so they silently expand as you adopt new services. A principal given Editor last year now also has Editor-level access to every service enabled since.

Owner includes the ability to change IAM. That means granting Owner is not just granting broad access, it is granting the ability to grant further access. Treat it as an administrative role, not a working role.

Predefined roles, and how to choose among them#

Predefined roles are maintained by Google per service, and most services offer a graded set. A common pattern within one service looks like this:

The practical selection method is to start from the narrowest role that plausibly covers the task, test it, and widen only if something legitimately fails. Starting from admin and never narrowing is how over-permissioned service accounts happen.

Custom roles, and their real constraints#

Custom roles let you assemble an exact permission set. They are the right answer when a predefined role is close but includes something dangerous, or when no predefined role covers a specific combination.

There are real operational costs to know about before reaching for them:

• Custom roles are not automatically updated when Google adds new permissions to a service. A predefined role gains relevant new permissions over time; a custom role stays frozen, which can quietly break as services evolve.
• They can be defined at the organization or project level. Folder-level definition is not available in the same way, so verify current behavior in docs if a folder-scoped custom role seems necessary.
• They carry a launch stage label (such as alpha, beta, general availability, or disabled), which is metadata to help teams track maturity of their own role definitions.

IAM Conditions#

A binding can carry an optional condition, which makes the grant apply only in specific circumstances. This turns a static grant into a contextual one. Common uses include time-bounding access (a grant that expires automatically) and restricting a grant to resources matching a naming pattern.

Conditions are how "temporary elevated access" gets implemented cleanly rather than through a reminder to revoke something later.

Who can be granted a role#

The "who" side of a binding is called a principal, and it can be more than an individual person:

allUsers makes a resource fully public. It is the mechanism behind a publicly readable Cloud Storage bucket, which is sometimes exactly what you want (a static website) and sometimes a serious data leak. Never apply it casually, and audit for it deliberately.

1.4 Cloud Identity#

Cloud Identity manages users and groups outside of GCP-resource IAM; it is the identity provider layer. Where IAM says "this identity may do this thing," Cloud Identity is where the identities themselves come from in the first place.

Why groups matter more than they first appear#

Groups are commonly used as the target of IAM bindings rather than individual users, since that is easier to manage at scale. The reasoning goes deeper than convenience:

• Onboarding and offboarding become one action. Adding someone to eng-backend@company.com grants every role that group holds, across every project. Removing them revokes all of it. Compare that to hunting through dozens of projects for individual bindings when someone changes teams.
• The audit story is clearer. Reviewing "which groups have production access" is a tractable question. Reviewing "which of 400 individual bindings across 30 projects are still appropriate" is not.
• Bindings stay stable as people move. The policy describes roles by function, not by person, which is what you actually want to express.

A group-based model only works if group membership is itself controlled. If anyone can add themselves to a group, the group grants become meaningless. Group membership management is part of the security boundary, not an administrative afterthought.

Connecting to an existing identity provider#

Most enterprises already have an identity system, and do not want a second parallel one. Two integration paths are common:

• Directory synchronization. An on-premises directory such as Active Directory can be synced into Cloud Identity so that users and groups mirror what already exists. Google provides tooling for this; verify the current tool name and its capabilities in docs, since this is a smaller and more changeable corner.
• Single sign-on. Cloud Identity can federate authentication to an external provider using SAML, so that the actual password and multi-factor challenge happen at the existing identity provider rather than at Google.

The distinction is worth keeping straight: synchronization is about who exists, single sign-on is about how they prove it. Many organizations use both together.

Super administrators#

Cloud Identity has its own highly privileged super administrator role, separate from GCP IAM roles like Organization Administrator. A super admin can manage the identity domain itself. These accounts sit outside the normal IAM model and warrant special handling: few of them, strong multi-factor authentication, not used for daily work, and monitored.

1.5 APIs, Quotas, and Operations Suite Setup#

API enablement#

APIs and services must be explicitly enabled per project before they can be used. This is not just bureaucratic friction; it is a meaningful default-deny posture. A project cannot accidentally accrue usage of a service nobody enabled.

This causes a specific and very common failure mode worth recognizing on sight: code or Terraform that works in one project fails in a fresh project with a permission-shaped error, and the actual cause is a disabled API rather than a missing IAM role. When a call fails against a brand new project, check API enablement before debugging IAM.

API enablement is a per-project action. Enabling a service in web-app-dev does nothing for web-app-prod. Infrastructure-as-code should declare required API enablement explicitly, or new environments will fail in confusing ways.

Quotas#

Quotas cap how much of a service a project can consume. They exist to protect both Google's infrastructure and you, since a runaway process hitting an unlimited API is a very expensive kind of bug.

Quota increases are requested through the Console, are not instant, and may require justification for large jumps. This has a real planning consequence: capacity for a launch needs to be requested in advance, not discovered on launch day. Checking current quota headroom is part of pre-launch work, alongside load testing.

Operations suite setup#

Initial setup of Cloud Operations suite products happens conceptually here, before the deeper operational usage covered in Section 9. The practical point at this stage is that logging and monitoring are largely on by default for GCP-managed services, but the pieces that need deliberate setup are the ones teams most often skip: agent installation on VMs, log routing to long-term storage, and enabling the audit log categories that are off by default.

2. Service Accounts and Identity Security#

This section maps to ACE exam domain 5, roughly 17.5% weight, but it is conceptually foundational and worth learning early regardless. Section 0.6 already introduced the concept; this section covers the operational mechanics.

2.1 What a Service Account Is#

A service account is an identity for workloads and applications, not humans. It has its own email-like identifier and can be granted IAM roles just like a user.

What makes service accounts unusual in IAM is that they are both an identity and a resource. As an identity, a service account can be granted roles on other things. As a resource, it lives in a project and has its own IAM policy governing who may use it. That dual nature is the source of most confusion about them, and Section 2.3 unpacks it directly.

Service accounts come in a few flavors worth distinguishing:

2.2 Creating and Assigning#

Service accounts are created per project, and can be granted roles at project, folder, or org level like any principal. A service account is assigned to a resource, for example a Compute Engine VM or a Cloud Run service, so that resource "acts as" that identity when calling other GCP APIs.

How a workload actually gets its credentials#

The mechanism is worth understanding, because it explains why key files are usually unnecessary. When a service account is attached to a VM or a Cloud Run service, that compute environment can fetch short-lived access tokens from an internal metadata server at runtime. No secret is stored in the application, no key file is deployed, and tokens rotate automatically.

Client libraries handle this automatically through Application Default Credentials, which look for credentials in a defined order: an explicitly set environment variable first, then local developer credentials, then the metadata server. The practical upshot is that well-written code needs no credential handling at all; it works locally with a developer's own credentials and in production with the attached service account, unchanged.

The single most common audit finding. Favor narrowly-scoped custom or predefined roles over broad ones on service accounts. Overly broad service account permissions are the single most common thing real production security audits flag.

One service account per workload#

A pattern already visible in the Tier 3 through Tier 6 examples, and worth stating as a rule: give each distinct workload its own service account rather than sharing one across services.

The reason is containment. A shared service account accumulates the union of every permission any of its consumers needed, and a compromise of the weakest consumer grants all of it. Separate identities keep the blast radius proportional to what was actually breached.

2.3 Managing IAM of a Service Account#

This is a distinct concept from creating and assigning one. You can grant users permission to act as, or impersonate, a service account; this is an IAM policy on the service account resource itself, separate from what roles the SA holds.

A common point of confusion is "roles granted to the SA" versus "roles granted on the SA to control who can use it." These are two different policies on two different sides of the relationship.

Two arrows, two different questions. The left arrow answers "who is allowed to use this identity?" The right arrow answers "what is this identity allowed to do once it is being used?" Alice having permission to impersonate the service account says nothing about what that service account can access, and the service account's own database access says nothing about who is allowed to act as it.

Why this matters for privilege escalation#

This two-sided structure creates a real escalation path that security reviews specifically look for. If a low-privileged user can impersonate a high-privileged service account, that user effectively has the service account's privileges.

So "who can act as this service account" is as security-sensitive as "what can this service account do." Granting broad service-account-user rights across a project quietly hands out every privilege held by every service account in it.

Audit both directions. Reviewing only what service accounts can access misses half the picture. The other half is who is permitted to become them.

2.4 Impersonation and Credentials#

• Impersonation. A user or another service account temporarily "becomes" the SA to make API calls, preferred over downloading keys.
• Service account keys (JSON key files). Long-lived, higher risk if leaked. Avoid these unless there is genuinely no alternative.
• Short-lived credentials. Generated on demand, expire quickly. This is the security-preferred pattern in production, and the one the ACE exam rewards as well.
• Workload Identity Federation lets external identities, for example AWS or on-prem, assume GCP service accounts without keys. This is increasingly relevant given how the short-lived-credentials pattern is emphasized, but verify current scope and behavior against docs, since it is a more advanced and newer topic.

The diagram below shows why these two approaches carry such different risk profiles.

The key file is a static secret that works forever until someone remembers to revoke it. A short-lived credential from impersonation expires on its own, so a leak is bounded in time even if nobody notices right away. That difference is the entire reason impersonation is the preferred pattern.

Choosing an approach by scenario#

If a key file is unavoidable#

Sometimes it is. In that case the mitigations that actually matter: scope the service account to the minimum, store the key in Secret Manager rather than in a repository or an environment variable baked into an image, rotate on a schedule, and monitor its usage so anomalous activity is visible.

An org policy constraint can block key creation entirely, which is the strongest available control if your environment can live without them. That constraint is mentioned in Section 1.2.

2.5 Default Service Accounts#

Compute Engine and other services provision a default service account automatically, historically with broad Editor-like access. This is a well-known real-world security mistake, and a common thing to catch in a security review, or see tested as "what is wrong with this setup?"

The failure mode is subtle because nothing looks wrong. Nobody deliberately granted broad access; it arrived with the default. A VM launched with all defaults has an identity that can modify a large share of the project, so any code running on that VM, including a compromised dependency, inherits that reach.

Two remediations, both worth knowing:

• Do not use the default service account for workloads. Create a purpose-built one per workload, as described in Section 2.2.
• Reduce or remove the default's broad roles where existing workloads permit it, and verify nothing depends on them before doing so.

Access scopes are a separate, legacy mechanism. Older Compute Engine setups also have "access scopes" on the VM that limit which APIs the attached service account may call, layered on top of IAM. Modern guidance is to control access through IAM roles on a dedicated service account rather than relying on scopes. If you encounter scopes in older infrastructure, treat them as an additional constraint to understand, not as your primary control.

3. Billing and Cost Management#

This section maps to ACE exam domain 1.2, and is also just genuinely necessary for anyone accountable for cloud spend. Cost in cloud infrastructure is an architectural property, not an accounting afterthought, since the design decisions in Sections 4 through 6 determine most of the bill.

3.1 Billing Accounts#

A billing account is separate from a project; one billing account can fund multiple projects. There are two types conceptually, self-serve (credit card) and invoiced (enterprise); verify current terminology, since Google renames billing account types occasionally.

One billing account funding several projects is the normal shape, not an edge case. It is what lets an organization see combined spend across every environment in one place.

Billing has its own IAM roles#

Billing permissions are deliberately separate from resource permissions, which is a security feature rather than an inconvenience. Someone who can deploy infrastructure does not automatically gain the ability to move a project onto a different billing account or view organization-wide spend.

Linking a project to a billing account requires permission on both sides. You need the right to attach billing on the project, and the right to use that specific billing account. This split is intentional: it stops someone from quietly attaching their own project to a company billing account, or moving a company project onto an unmonitored one.

3.2 Linking and Structure#

Projects must be explicitly linked to a billing account to incur or pay charges. A project can only be linked to one billing account at a time, though it can be relinked.

An important operational consequence: unlinking billing effectively stops a project from functioning. Paid resources cannot run without a billing account attached. That makes billing detachment a genuine (if blunt) emergency control, and also a genuine outage risk if it happens accidentally to a production project.

Structuring for cost visibility#

How projects map to billing accounts determines what questions you can answer easily later. Some common approaches:

Labels deserve specific attention here. They are key-value pairs attached to resources, and they flow into billing data, which makes them the main tool for answering "what did feature X cost?" or "how much of this bill is staging?" Labels applied inconsistently, or applied after the fact, produce billing data nobody trusts. Deciding a label schema early and enforcing it in infrastructure-as-code is what makes cost attribution possible at all.

3.3 Budgets and Alerts#

A budget amount and threshold percentages (for example 50%, 90%, 100%) trigger notifications.

Budgets do not stop spending. Budgets and alerts notify. They do not automatically stop spending or shut down resources, unless separate automation is built (for example a Cloud Function triggered by a budget's Pub/Sub notification) to do so. This is an easy thing to assume incorrectly in production.

Notifications can route to billing admins or to a Pub/Sub topic for programmatic response. The diagram below shows the difference between the two: one just tells a human, the other can actually take action.

The email path is the default and does nothing on its own beyond informing a person. The Pub/Sub path is what makes automated shutoff possible, but that automation has to be built deliberately; GCP does not provide it out of the box.

Budget scope and threshold types#

Budgets are more flexible than a single project-wide number. A budget can be scoped to the whole billing account, to specific projects, to specific services, or filtered by label, which lets a team monitor its own spend without needing visibility into everyone else's.

Thresholds can also trigger on two different bases, and the distinction is practically useful:

Forecast-based alerts are the ones that catch a runaway process on day three of the month rather than day twenty-eight.

Think carefully before automating a hard shutoff. Automatically disabling billing does stop the spend, and it also takes production down. For most teams the right automation is targeted (scale down a specific non-critical workload, or page a human) rather than pulling the plug on everything.

3.4 Billing Export#

Detailed billing data can be exported to BigQuery for analysis: standard usage cost data, and optionally more detailed and pricing-oriented datasets. Export to Cloud Storage may also be possible in some form; verify current export target options in docs.

Why bother, when the Console has cost reports? Because the built-in reports answer common questions and BigQuery answers arbitrary ones. Once billing data lands in BigQuery, cost becomes queryable with SQL and joinable against your own data, which is what makes questions like "cost per customer" or "cost per transaction" answerable at all.

Export is not retroactive. Data starts flowing from the point you configure the export forward. There is no way to backfill months you did not export, so this is worth turning on early even before anyone plans to analyze it.

3.5 Quotas#

There is a conceptual distinction between rate quotas (requests per time) and allocation quotas (total resources), which relates back to Section 1.5. Increases are requested through Console, are not instant, and may require justification.

Worth being precise about a common conflation: quotas are not a cost control, and budgets are not a capacity control. A quota caps how much of a resource can exist or be called; a budget watches how much money has been spent. Using quotas as a crude spending cap works in a limited way but produces confusing failures, since the failure surfaces as a capacity error rather than a cost warning.

Discounts worth knowing about#

Cost optimization on GCP is not only about using less. Several pricing mechanisms reward predictability:

Verify current discount mechanics and rates in official pricing docs. The structure above is stable in concept, but the specific percentages, eligible resource types, and commitment terms change, and they differ by service. Do not plan a budget against remembered numbers.

4. Compute Services#

This section maps to ACE exam domains 2.1, 3.1 through 3.3, and 4.1 through 4.3, collectively roughly 25% or more of the exam, and is also the largest decision space in real GCP architecture.

The reason this section is large: GCP offers several genuinely different compute models, and picking the wrong one is expensive to undo. The differences are not about capability so much as about which operational responsibilities you keep and which you hand to Google.

Moving right along that spectrum means less operational work and less control. Neither end is universally correct; the right position depends on what the workload actually needs.

4.1 Compute Engine (VMs)#

Compute Engine is infrastructure-as-a-service: virtual machines you configure, patch, and operate. It is the most flexible option and the one with the most operational responsibility attached.

Instance Fundamentals#

Machine types come as predefined families or custom machine types, where you choose the exact vCPU and memory. Instances have a boot disk plus optional additional persistent disks, in various disk types (verify current naming, since GCP has renamed disk tiers before).

Machine families are grouped by what they optimize for, which is the level of detail that actually drives a decision:

Verify current machine family names and specifications in docs. Google introduces new generations regularly and retires older ones, so specific family names (and which is cheapest for a given shape) change. The categories above are stable; the names inside them are not.

Custom machine types matter for a specific reason: predefined types come in fixed vCPU-to-memory ratios, and a workload that needs lots of memory but little CPU would otherwise force you to pay for unused vCPUs. Custom types let the shape match the workload, which is a real cost lever.

Getting into a VM#

SSH key management is handled either per-instance, or via OS Login, which centralizes SSH access through IAM instead of per-instance metadata keys, and is generally favored for manageability and security.

The difference is worth spelling out, since it is a recurring exam and review topic:

A third option worth knowing: Identity-Aware Proxy TCP forwarding allows SSH to an instance that has no external IP at all, by tunnelling through a Google-managed endpoint that enforces IAM. This is how the private-networking posture from Tier 5 stays operable without bastion hosts.

Availability and Cost Options#

Spot VMs are cheap and can be preempted by Google at any time; the right choice for fault-tolerant or batch workloads, the wrong choice for anything needing uptime guarantees. Availability policy covers on-host maintenance behavior and automatic restart settings.

The termination notice is real but brief. Anything running on a Spot VM needs to expect this interruption as a normal event, not an edge case, which is why Spot VMs are the wrong choice for anything that cannot tolerate an abrupt stop.

Spot VMs superseded the older "preemptible VM" offering. Preemptible instances had a hard maximum runtime; Spot instances relaxed that. If you encounter preemptible terminology in older documentation or infrastructure, it refers to the earlier generation of the same idea. Verify current behavior and notice periods in docs.

Two other availability settings matter for ordinary VMs:

• On-host maintenance behavior determines what happens when Google needs to service the underlying hardware. The default for most instances is live migration, where the VM is moved to other hardware with no shutdown. Some instance types cannot live-migrate and must be terminated and restarted instead.
• Automatic restart controls whether an instance comes back on its own after a crash or a maintenance event that required termination.

Scaling#

Managed Instance Groups (MIGs) are built from an instance template, with autoscaling policies based on CPU, load balancing capacity, or custom and Cloud Monitoring metrics. MIGs can be regional or zonal.

A MIG does considerably more than autoscale, and the other capabilities are the ones that matter most operationally:

Instance templates are immutable. You cannot edit a template in place. Changing the configuration means creating a new template and pointing the MIG at it, which then triggers a rolling update. This is a feature rather than a limitation: it means the running fleet always corresponds to a specific, versioned definition.

Regional versus zonal MIGs is the availability decision here. A zonal MIG's instances all live in one zone, so a zone outage takes out the whole group. A regional MIG spreads instances across zones in the region, surviving the loss of one.

Lifecycle Management#

Snapshots are point-in-time disk backups, and can be scheduled. Images are bootable disk images created from a VM or snapshot, used as the base for new instances or templates.

The diagram makes the split obvious: a snapshot flows back into restoring the same kind of thing it came from, a disk. An image flows forward into creating many new, independent instances. Confusing the two means reaching for a backup tool when what is actually needed is a template, or the reverse.

Snapshots and images serve different purposes. A snapshot is a backup and restore mechanism. An image is a template for creating new instances. The distinction matters in practice, not just as trivia.

Two further details worth carrying:

• Snapshots are incremental. After the first one, subsequent snapshots of the same disk store only changed blocks, which makes frequent scheduled snapshots far cheaper than the raw disk size would suggest.
• Custom images support a golden-image workflow. Rather than configuring each new VM with startup scripts, teams often build one image with everything baked in, then launch identical instances from it. This reduces boot time and configuration drift.

Management Tooling#

VM Manager covers patch management, OS configuration, and inventory reporting across fleets of VMs. It is a newer topic area, less intuitive from general VM experience, and worth a dedicated docs read.

The problem it solves is genuinely painful at scale: once you have dozens or hundreds of VMs, answering "which of these are missing a security patch?" or "which have drifted from the intended configuration?" is not something to do by hand. VM Manager provides that inventory and patch orchestration centrally.

This is also a reminder of why managed compute options exist. Every capability in this subsection is work that Cloud Run and GKE Autopilot users simply do not do.

4.2 Google Kubernetes Engine (GKE)#

GKE is managed Kubernetes. Google runs the control plane; how much of the rest you run depends on the cluster mode.

Cluster Modes#

Autopilot has Google manage the node infrastructure while you manage workloads, meaning less operational overhead but less low-level control. Standard has you manage node pools, sizing, and scaling directly.

The line that moves between the two modes is exactly where node-level responsibility sits. Autopilot pushes almost all of it to Google; Standard keeps it with you, in exchange for more control.

The billing model differs along with the responsibility, which is often the deciding factor:

Autopilot restricts some low-level operations. Because Google owns the nodes, certain privileged workloads, custom node configurations, and DaemonSet patterns are limited or unavailable. If a workload needs deep node access, Standard is the answer. Verify current Autopilot restrictions in docs, since the gap has been narrowing over time.

Cluster Topology#

Clusters can be zonal or regional, where regional means control-plane redundancy across zones and higher availability. Private clusters have nodes with no public IP, changing access patterns to require a bastion or Cloud NAT for egress.

A zonal cluster's control plane is a single point of failure at the zone level; if that zone has an outage, cluster management is unavailable even if the nodes themselves are fine. A regional cluster's control plane survives a single zone going down.

An easily missed implication: losing the control plane does not immediately stop already-running Pods, but it does stop anything that requires the control plane, which includes deployments, scaling, autohealing, and kubectl access. A cluster whose control plane is unreachable is running but unmanageable.

Private clusters are the GKE expression of the Tier 5 posture. Nodes have no public IPs, so:

• Outbound internet access, for pulling public container images or calling external APIs, goes through Cloud NAT.
• Control plane access can be restricted to specific authorized networks, so kubectl only works from approved source ranges.

GKE Enterprise, formerly Anthos, is a multi-cluster and multi-cloud management layer; naming has shifted recently, so confirm current terminology before treating this as settled knowledge.

Working with the Cluster#

Core kubectl verbs are get, describe, apply, and delete, used against Pods, Services, Deployments, and StatefulSets. Node pools can be added, edited, or removed, letting you run heterogeneous machine types in one cluster.

Before kubectl works at all, credentials have to be fetched, which is a step people new to GKE routinely miss:

gcloud container clusters get-credentials CLUSTER_NAME --region REGION

This writes cluster connection details into the local kubeconfig. Without it, kubectl has no idea the cluster exists.

The Kubernetes objects worth recognizing, at overview level:

Node pools exist so that one cluster can contain different machine shapes. A cluster might have a general-purpose pool for most workloads and a GPU pool for inference, with workloads directed to the right pool by scheduling rules.

Scaling in GKE, at three different levels#

This trips people up because "autoscaling" in Kubernetes means three separate things that operate at different layers:

The Horizontal Pod Autoscaler changes how many Pods there are. The Vertical Pod Autoscaler changes how big each Pod asks to be. The Cluster Autoscaler changes how many nodes exist to hold them. In Autopilot mode, node-level scaling is Google's concern, so the cluster autoscaler question largely disappears.

Connecting GKE to other GCP services#

Connecting GKE to Artifact Registry for container images requires an IAM binding between the two, so that the identity used by nodes can pull images.

For workloads inside the cluster that need to call GCP APIs, the recommended mechanism is Workload Identity, which maps a Kubernetes service account to a GCP service account. This is the GKE-native way to avoid key files, and it is the direct equivalent of the metadata-server pattern described in Section 2.2.

Without Workload Identity, teams often fall back to mounting a service account key as a Kubernetes secret. That reintroduces exactly the long-lived-credential problem described in Section 2.4. Workload Identity is the pattern to reach for first.

Version management#

GKE clusters run a Kubernetes version that has to be upgraded over time, and Google offers release channels (with names along the lines of rapid, regular, and stable) that trade newness against stability, plus maintenance windows to control when disruptive upgrades happen.

This matters operationally because Kubernetes versions have a support lifecycle. A cluster left alone will eventually be force-upgraded, so upgrade cadence is something to plan rather than discover.

4.3 Cloud Run#

Cloud Run is a fully managed container platform, request-driven, and scales to zero. Services are long-lived and HTTP-triggered; Jobs are run-to-completion tasks (verify current terminology, since Jobs is a newer addition).

The core appeal: you provide a container that listens on a port, and Cloud Run handles provisioning, scaling, TLS, and routing. There are no nodes, no clusters, and no capacity planning.

Traffic splitting is what makes a gradual rollout possible: instead of switching every user to a new revision at once, a small percentage gets routed there first, and the split shifts over time as confidence in the new revision grows.

You can deploy from source, where Google builds the container for you, or deploy a pre-built container image. Traffic splitting routes a percentage of traffic between revisions, used for canary or gradual rollouts. Scaling parameters include min and max instances and concurrency per instance.

Revisions are immutable#

Every deployment creates a new revision, which is a frozen combination of image, environment variables, and configuration. Revisions do not change after creation; a config change produces a new one. This is what makes traffic splitting and instant rollback possible, since the previous revision still exists and can simply be given traffic again.

The scaling knobs, and what each is actually for#

Cold starts are the main latency consideration. Scaling to zero saves money and means the first request after idle has to wait for an instance to start. Setting a minimum instance count trades cost for consistent latency. Which matters more is a product decision, not a technical one.

Concurrency interacts with database connection limits. Many instances each holding database connections can exhaust a Cloud SQL connection pool. This is a genuinely common production incident, and the fix is usually a combination of connection pooling and a sane max-instances cap.

Access control#

Cloud Run services are private by default in the sense that invocation is governed by IAM, through an invoker role. Making a service publicly reachable means granting that invoker permission to allUsers, which connects back to the warning in Section 1.3.

This is a meaningful design point for internal microservices: service-to-service calls can require an authenticated identity, so an internal API is not reachable by anyone who discovers its URL.

Connecting to a VPC#

By default a Cloud Run service runs outside your VPC, which means it cannot reach private resources such as a Cloud SQL instance on a private IP, or a Memorystore instance. Connecting it to a VPC is an explicit configuration step, and it is what the Tier 5 architecture assumes. Verify the current mechanisms and their names in docs, since this area has evolved and multiple approaches exist.

Event triggers#

Event-driven triggers include Pub/Sub push, Cloud Storage object notifications, and Eventarc as the unifying event-routing layer.

Eventarc is the layer that lets Cloud Run stay agnostic about where an event came from; the service just receives a standardized event, regardless of which source produced it.

Jobs versus Services#

The distinction matters when choosing how to run something:

A Service that is really a batch job ends up fighting request timeouts. A Job is the right shape for work that has an end.

4.4 Cloud Functions#

Cloud Functions are event-driven, single-purpose functions, the simplest serverless compute option, with triggers such as HTTP, Pub/Sub, Cloud Storage, and Firestore. Choose Cloud Functions over Cloud Run when the workload is a small, single-purpose event handler rather than a full containerized service.

The distinction has narrowed considerably over time, and it is worth being honest about why: later generations of Cloud Functions are built on the same underlying platform as Cloud Run. The practical difference is now mostly about developer experience rather than capability.

Verify which generation of Cloud Functions you are targeting. Behavior, limits, and trigger support differ between generations, and the newer generation inherits many Cloud Run capabilities. Confirm current specifics in docs rather than assuming.

4.5 Decision Framework#

The table below is the compute selection logic in practice: given a signal in the scenario, here is the likely right answer.

The same logic, walked as a decision tree rather than a lookup table:

Reading this tree top to bottom mirrors how the decision actually gets made in practice: rule out the workloads that need low-level OS control first, then orchestration complexity, then event-handler simplicity, and whatever is left over defaults to Cloud Run.

Signals that should make you reconsider a choice#

Beyond the initial pick, some symptoms suggest the compute model itself is wrong rather than mis-tuned:

5. Storage and Database Services#

This section maps to ACE exam domains 2.2, 3.4, and 4.4, spread across the exam, and is the most transferable "pick the right product" skill in this whole guide.

The single most useful habit here is separating three questions that often get collapsed together: what shape is the data, how is it accessed, and what durability or latency does it need? Answering those in order narrows the product choice far faster than comparing feature lists.

5.1 Cloud Storage#

Cloud Storage holds objects, which are immutable blobs of bytes with metadata, organized into buckets. It is not a filesystem, even though tools present a folder-like view; there are no real directories, only object names that happen to contain slashes.

Buckets and location#

Bucket names are globally unique across all of GCP, in the same way project IDs are. Location choice happens at creation and affects both cost and resilience:

Location cannot be changed after bucket creation. Moving data to a different location means creating a new bucket and copying, which for large datasets is a real project rather than a setting change.

Storage Classes#

The table below shows the trade-off between access frequency, storage cost, and retrieval cost.

Verify the exact numbers. Figures like 30, 90, and 365 days for Nearline, Coldline, and Archive respectively are commonly cited, but confirm these against current Cloud Storage pricing docs before relying on them for anything, exam or production. Early deletion within the minimum duration incurs a fee.

The cost model is what makes this decision non-obvious. Colder classes charge less to store and more to retrieve, so a "cheap" archive class becomes expensive if the data turns out to be read often. The class should match the actual access pattern, not the aspiration.

Object Lifecycle Management is what moves data through these classes automatically as it ages, rather than requiring anyone to manually reclassify files.

A typical rule: move an object to Nearline after 30 days of no access, to Coldline after 90 days, and to Archive after 365 days. The object itself never moves physically in any way a user would notice; only its storage class, and therefore its cost profile, changes.

There is also an automatic tiering option. Google offers a feature that moves objects between classes based on observed access patterns rather than fixed age rules, which suits data whose access pattern is unpredictable. Verify its current name, behavior, and pricing in docs.

Lifecycle and Access Management#

Object Lifecycle Management defines rules to auto-transition storage class or delete objects based on age or other conditions. Access control is via IAM at the bucket or project level, or via ACLs, which are legacy and object-level; IAM is the modern, generally preferred approach. Signed URLs grant temporary access without any IAM changes.

The IAM-versus-ACL question has a concrete resolution worth knowing: uniform bucket-level access is a bucket setting that disables object-level ACLs entirely, forcing all access through IAM. This is the recommended posture, because having two overlapping permission systems on the same data is how surprising access happens. An org policy constraint can require it, as mentioned in Section 1.2.

Signed URLs deserve emphasis because they solve a specific, very common problem: letting a user upload or download a file directly, without granting them any IAM role and without routing the bytes through your application. A signed URL is a time-limited, cryptographically signed link. This is the mechanism behind the Tier 2 architecture.

Protecting data from deletion#

Several distinct features cover different failure modes, and mixing them up is common:

Bucket lock is genuinely irreversible. It exists for compliance regimes that require provable immutability. That also means a mistake in configuring it cannot be undone, including by Google support. Read the documentation carefully before using it.

Encryption options#

Data is encrypted at rest by default with Google-managed keys, and nothing needs configuring for that. Two alternatives exist for stricter requirements:

• Customer-managed encryption keys, where keys live in Cloud KMS and you control rotation and revocation. Revoking the key makes the data unreadable, which is both the point and the risk.
• Customer-supplied encryption keys, where you provide the key with each request and Google does not store it at all. Maximum control, maximum operational burden.

5.2 Persistent Disk#

Zonal PD attaches to a single zone's VM and is faster. Regional PD replicates across two zones and is used for higher-availability workloads, for example regional MIGs.

If zone A fails entirely, a zonal disk is simply unavailable until that zone recovers. A regional disk has a live replica in zone B ready to take over, which is the entire reason it costs more and writes slightly slower: every write has to be confirmed in both zones.

Disk types and the performance model#

Persistent disks come in several performance tiers, broadly from cheaper spinning-disk-backed options up to high-performance SSD-backed ones, with newer generations added over time. Verify current type names and their characteristics in docs.

One non-obvious property is worth internalizing: persistent disk performance often scales with disk size. A small disk may have a low IOPS ceiling regardless of type, which means a performance problem is sometimes solved by provisioning a larger disk than the capacity alone requires.

Disks can be grown but not shrunk. Resizing up is a live operation; there is no corresponding shrink. Over-provisioning is therefore a one-way cost decision.

Other storage attached to compute#

Local SSD data is lost when the instance stops. It is not a durable store, and no snapshot will save it. Treat it strictly as scratch space.

5.3 Databases#

The table below covers the main relational and NoSQL options.

A simple rule of thumb: Firestore for app and user data, Bigtable for high-volume telemetry-style data.

Cloud SQL in more depth#

Cloud SQL is the default relational choice, and the operational features are where most of the real learning is:

A read replica is not a high-availability standby. The HA standby exists for failover and does not serve traffic. Read replicas serve read traffic but do not automatically take over on failure. Teams sometimes assume having read replicas means they have HA; it does not.

Connecting to Cloud SQL securely is its own topic. The options include private IP within a VPC (the Tier 5 posture), and a connector or proxy component that handles authentication and encryption without exposing the database publicly. Verify current connector options and names in docs.

Spanner in more depth#

Spanner's distinguishing claim is combining relational semantics and strong consistency with horizontal scale, which traditional relational databases give up at scale. It achieves this with a globally synchronized time infrastructure and automatic data sharding.

What matters practically:

• Capacity is provisioned in units (historically described as nodes, and also in smaller processing-unit increments), rather than by picking a machine size.
• Schema design has real performance consequences. Poorly chosen primary keys concentrate writes on one shard, which is the Spanner equivalent of the hotspotting problem described below for Bigtable.
• Multi-region configurations increase availability and write latency simultaneously, since writes must coordinate more widely.

Spanner is usually the wrong first answer for a typical application. It is more expensive and more constrained than Cloud SQL. It becomes right when scale or global consistency genuinely exceed what Cloud SQL can do, not merely when a system is important.

Firestore in more depth#

Firestore stores documents in collections, with a few characteristics that shape its use:

• Real-time listeners push changes to clients, which is why it is popular for mobile and collaborative applications.
• Security rules allow client applications to talk to the database directly with per-document authorization, rather than requiring every read to pass through your own backend.
• Queries require indexes, and complex queries need composite indexes defined in advance. Firestore's query model is deliberately restricted so that query cost stays proportional to result size rather than dataset size.
• It comes in two modes, one native and one for Datastore compatibility, chosen per project and not casually changed. Verify current mode behavior in docs.

Bigtable in more depth#

Bigtable is built for very high throughput on simple access patterns, and it has one design consideration that dominates everything else:

Row key design determines Bigtable performance. Data is stored in row-key order and distributed by key ranges. Sequential keys, such as timestamps, funnel all new writes onto one node, producing a hotspot that no amount of added capacity fixes. Key design has to distribute writes deliberately.

Other properties worth knowing: there are no secondary indexes, queries are row-key based rather than expressive like SQL, and storage comes in SSD or HDD variants depending on latency needs.

Memorystore, for caching#

Caching is a distinct need from persistence, and Memorystore provides managed in-memory data stores (Redis-compatible, and Memcached) for it. This is the component used in the Tier 4 architecture to keep read-heavy traffic off the database. Verify which engines and versions are currently offered in docs.

5.4 Analytics#

BigQuery is a serverless data warehouse with a SQL interface, functioning as both storage and an analytics engine. Data can be loaded via Console upload, the bq CLI, directly from Cloud Storage, or via Storage Transfer Service for larger or recurring transfers.

BigQuery differs from the databases above in a way that matters for choosing it: it is built for scanning and aggregating very large datasets, not for serving many small, low-latency reads and writes. Using it as an application backend produces disappointing latency; using a transactional database for analytics produces disappointing scale.

The cost model, and why it drives design#

BigQuery's pricing has historically been driven substantially by how much data a query scans, with alternative capacity-based models also available. That single fact explains most BigQuery best practices:

Verify current BigQuery pricing models in docs. Both on-demand (scan-based) and capacity-based options exist, and the specifics of each have changed over time. The optimization techniques above remain sound regardless of which model is in use.

A useful safety feature: queries can be given a maximum bytes billed limit, which causes an over-budget query to fail rather than run. That converts an expensive surprise into an error message.

5.5 Operational Tasks Across Databases#

Queries can be executed against each database type via Console or CLI. Cloud SQL and Firestore have managed backup features; know how to trigger and restore from them. For cost, practice with the pricing calculator conceptually rather than memorizing numbers.

A backup is not a backup until it has been restored#

The single most valuable operational habit in this whole section: test the restore path, not just the backup configuration. Backups that exist but have never been restored are an assumption, not a capability. Common discoveries during a first real restore attempt include missing permissions, an unexpectedly long restore duration that breaks the recovery time objective, and a backup that does not actually include everything needed.

Two terms worth having precise:

These two numbers determine which features are actually required. Point-in-time recovery exists because a nightly backup implies losing up to a day of data, which many systems cannot accept.

Estimating cost before building#

The pricing calculator is genuinely useful before committing to an architecture, particularly for comparing options whose cost profiles differ in shape rather than degree. Cloud SQL versus Spanner, or on-demand versus capacity-based BigQuery, are decisions where a rough model beforehand prevents an unpleasant surprise later.

6. Networking#

This section maps to ACE exam domains 2.3, 3.5, and 4.5, and is historically the area where developers without an infrastructure background feel least confident, exam or not.

The reason it feels hard is that networking is the one layer where nothing is implicit. Compute and storage have sensible defaults that work; networking has defaults that work only until a system needs isolation, private connectivity, or controlled egress, at which point every piece has to be configured deliberately.

6.1 VPC Fundamentals#

A Virtual Private Cloud is your private network inside GCP. It provides the address space, routing, and firewall context in which resources communicate.

An auto-mode VPC creates one subnet per region automatically: simple, with less control. A custom-mode VPC requires manually defined subnets: the production-recommended setup, and generally the correct answer when a scenario is choosing between the two.

VPCs are global; subnets are regional.

The VPC itself is one global object, but every subnet inside it is pinned to a single region. A resource in app-subnet and a resource in data-subnet can still communicate over the VPC's internal routing, even though the subnets live in different regions.

The globality of VPCs is a genuine differentiator. On some other platforms, a network is regional and cross-region communication requires explicit peering. In GCP, one VPC spans regions natively, which simplifies multi-region designs considerably.

Why auto-mode is discouraged for production#

Auto-mode VPCs create subnets in every region using a predefined address range. That is convenient, and it creates two problems:

• Address space you did not choose. The predefined ranges may collide with on-premises networks or other clouds you later need to connect to, and overlapping ranges cannot be peered.
• Subnets you did not ask for. Every region gets one, which is more surface area than most designs want.

Custom mode means deciding the address plan deliberately, which is exactly what you want before connecting anything to anything else.

The default network#

New projects often come with a default VPC that has permissive firewall rules pre-created, including allowances for common inbound protocols. That is helpful for a first experiment and inappropriate for production. Deleting the default network, or preventing its creation through org policy, is a common hardening step.

6.2 Shared Infrastructure Patterns#

Seeing all three side by side makes the distinction easier to keep straight than reading the table rows in isolation:

The distinguishing question for each: Shared VPC asks "is this one org centralizing its own network?" Peering asks "are these two otherwise-independent networks that just need to talk?" Cloud VPN asks "is one side of this connection not in GCP at all?"

Shared VPC, and why organizations adopt it#

Shared VPC lets a central network team own the VPC in a host project, while application teams deploy resources into it from their own service projects. The appeal is a clean separation of duties: network engineers control subnets, firewall rules, and routing, while application teams retain control over their own compute and data resources.

Access can be delegated at subnet granularity, so one team can be permitted to deploy into a specific subnet without gaining rights over the whole network.

VPC Peering, and its two significant limitations#

Peering connects two VPCs so they route to each other privately. Two constraints cause most of the surprises:

Peering is not transitive. If VPC A peers with B, and B peers with C, then A and C cannot reach each other. Each pair needs its own peering relationship, which means a fully connected mesh of N networks grows quadratically. This is a common reason designs move toward Shared VPC or a hub-and-spoke pattern with an explicit routing appliance instead.

Overlapping IP ranges cannot be peered. If both networks use the same address space, peering is impossible without renumbering one side. This is the concrete reason address planning matters before anything is deployed, and the reason auto-mode VPCs cause problems later.

Connecting to on-premises#

Cloud VPN carries traffic over the public internet inside an encrypted tunnel, which is fast to set up and limited by internet performance and reliability. For workloads needing more bandwidth or more predictable latency, Cloud Interconnect provides a dedicated physical connection into Google's network, either directly or through a partner.

Both typically use Cloud Router to exchange routes dynamically with the on-premises network using BGP, rather than requiring static route configuration on both sides.

Verify current SLA figures and bandwidth options in docs. Different VPN and Interconnect configurations carry different availability commitments, and those specifics change.

6.3 Subnets#

Subnet IP ranges can be expanded but not shrunk, since shrinking could orphan existing addresses. Static internal or external IP addresses can be reserved for specific resources.

Primary and secondary ranges#

A subnet has a primary IP range, used for the internal addresses of VMs, and can have additional secondary ranges. Secondary ranges exist mainly to support alias IP ranges, which is how GKE assigns addresses to Pods and Services natively within the VPC rather than through an overlay network.

This matters for capacity planning in a way that catches teams off guard: a GKE cluster consumes address space from these secondary ranges, and a range sized too small caps how many Pods the cluster can ever run. Address planning for a GKE cluster is not just about node count.

IP address types#

A reserved static external address costs money while it is not attached to anything. This is a small but genuinely common source of unexplained line items on a bill: addresses reserved for a project that was later deleted, still sitting there.

Reaching Google services from private instances#

An instance with no external IP cannot reach Google APIs over the public internet, which becomes a problem when it needs Cloud Storage or another managed service. Private Google Access solves this by allowing instances with only internal IPs to reach Google APIs through internal routing.

This is distinct from Cloud NAT, and the difference is worth keeping straight: Private Google Access is for reaching Google services; Cloud NAT is for reaching the general internet.

6.4 Firewall Rules#

Rules apply by direction, ingress or egress.

The default implied rules. GCP allows all egress and denies all ingress by default, until rules are added. This is one of the most commonly checked facts, both in real security reviews and on the exam.

Priority works with lower numbers taking higher priority, and rules are evaluated in order. Rules can target by IP range, by network tag, or by service account; service-account targeting is more precise and secure, and the increasingly preferred pattern over tags.

Evaluation stops at the first matching rule, which is why the numbering matters: a broad, low-priority-number rule placed above a narrower one can silently make the narrower rule unreachable.

What a rule is actually made of#

Each rule combines several elements, and understanding them as a set makes troubleshooting far easier:

Why service-account targeting beats network tags#

Both mechanisms let a rule apply to a subset of instances rather than everything. The difference is who can change the association:

Anyone who can edit an instance can change its network tags. Tags are just metadata labels, so a rule that grants access to instances tagged web-tier can be joined by anyone able to add that tag to their own instance. Attaching a service account to an instance, by contrast, requires IAM permission on that service account. Service-account-based rules therefore cannot be self-granted the same way.

Hierarchical and network firewall policies#

Beyond individual VPC firewall rules, GCP offers policy objects that can be applied at the organization or folder level and inherited downward, in the same spirit as org policies. This is how a security team enforces "these ports are never open anywhere" without editing every project's rules.

Verify current policy types and their precedence relative to VPC-level rules in docs, since this area has expanded over time.

When traffic is blocked and you cannot tell why#

A practical troubleshooting order that resolves most cases:

1. Confirm the direction being tested. Egress is allowed by default; ingress is not.
2. Check for a higher-priority rule matching before the one you expect.
3. Verify the target actually matches, especially if targeting by tag or service account.
4. Confirm the traffic is what you think it is: right protocol, right port.
5. Enable firewall rules logging to see which rule actually matched, rather than inferring it.

6.5 Load Balancing#

Selecting the right type depends on traffic scope (global versus regional) and protocol (HTTP(S), TCP/SSL, UDP), and whether the load balancer is internal or external.

The decision itself is a straightforward two-question tree, even though the product names attached to each branch shift over time:

Product names shift often here. Treat the exact current product-name matrix, for example "Global external Application Load Balancer," as something to verify directly in docs. Google has renamed and restructured this product family multiple times, and outdated names are a real risk. The decision logic above (scope, then protocol, then internal versus external) has stayed stable even as the specific product names attached to each branch have changed.

The shared anatomy underneath#

Whichever variant is chosen, the same conceptual pieces appear, and knowing them makes the configuration comprehensible rather than arbitrary:

Health checks deserve specific attention, because they are the mechanism that makes load balancing useful rather than merely distributing. A backend failing its health check is removed from rotation automatically. A misconfigured health check produces two characteristic failure modes: traffic sent to broken instances (check too lenient), or healthy instances pulled out of service (check too strict, or pointed at the wrong path).

Two closely related services#

• Cloud CDN caches responses at Google edge locations, in front of a load balancer, reducing both latency and backend load for cacheable content.
• Cloud Armor applies web application firewall and DDoS protection policies in front of a load balancer, which is the component used in the Tier 5 architecture.

Both attach to the load balancing layer rather than existing independently, which is why the load balancer is often the natural place to enforce edge concerns.

6.6 DNS and NAT#

Cloud DNS manages public and private DNS zones. Cloud NAT gives private, no-external-IP instances outbound internet access without exposing them to inbound traffic, commonly paired with private GKE clusters.

The arrow only flows one direction in terms of who can initiate: the private instance can reach out through Cloud NAT, but nothing on the public internet can reach in and start a connection to that instance. That asymmetry is the entire point of NAT here.

Public versus private DNS zones#

Private zones enable a split-horizon setup, where the same name resolves differently inside your VPC than it does publicly. That is useful for pointing internal traffic at internal addresses while external traffic reaches a public endpoint.

Cloud DNS also supports forwarding and peering configurations for hybrid setups where some names are resolved by an on-premises DNS server. Verify current configuration options in docs.

6.7 Network Service Tiers#

Premium tier uses Google's global network backbone. Standard tier is regional, cheaper, and uses the public internet more. The choice is a straightforward cost-versus-performance trade-off.

Premium tier keeps traffic on Google's own network for as much of the path as possible, entering and leaving near the user. Standard tier hands traffic to the public internet earlier, which costs less and gives up control over the path.

A consequence worth knowing: certain capabilities, notably global load balancing, depend on Premium tier. Choosing Standard tier to save money can therefore rule out an architecture rather than just making it slower. Verify which features currently require Premium tier in docs.

7. Data Movement and Pipelines#

This section maps to ACE exam domains 3.4 and 4.4, a lighter section, mostly recognition-level knowledge. The goal here is knowing which tool fits which movement pattern, not building pipelines.

7.1 Loading Data#

Data can be loaded via command-line upload (gsutil or gcloud storage cp, bq load, and similar), directly from Cloud Storage into BigQuery or Cloud SQL, or via Storage Transfer Service for large-scale or recurring transfers, including from other clouds or on-prem, which is distinct from a one-off manual upload.

Choosing among them comes down to scale, repetition, and source:

The physical-shipment option is not a joke. For multi-petabyte migrations, transferring over any realistic network connection can take months. Google offers a physical appliance that gets shipped, loaded, and returned. If a migration estimate produces an absurd duration, this is the category of answer to look for.

7.2 Pub/Sub#

Pub/Sub is publish/subscribe messaging, commonly the trigger source for Cloud Functions, Cloud Run, or Eventarc-based workflows. For general GCP fluency, and for ACE, focus on recognizing it as an event and messaging backbone rather than mastering complex pipeline topologies; that is deeper Data Engineer territory.

The core concepts are few:

A topic receives messages. A subscription is an independent stream of those messages to a consumer. Multiple subscriptions on one topic each receive their own copy, which is what makes fan-out patterns straightforward: adding a new consumer does not affect existing ones.

Two delivery styles exist:

Push suits serverless targets like Cloud Run. Pull suits consumers that want to control their own consumption rate.

Design for at-least-once delivery and possible duplicates. Messaging systems of this kind generally guarantee that a message arrives at least once, which means a consumer may see the same message twice. Handlers should be idempotent, meaning processing the same message twice produces the same result as processing it once. This is the single most important practical implication of using Pub/Sub, and the source of many subtle production bugs when ignored.

Dead-letter topics capture messages that repeatedly fail processing, so a single malformed message does not retry forever and block progress.

7.3 Dataflow#

For a generalist or DevOps role, and for ACE, the relevant skill is reviewing job status, not authoring pipelines; pipeline design is more a Data Engineer specialty. Know how to check a Dataflow job's state via Console or CLI, and interpret basic failure signals.

Dataflow runs data processing pipelines, and handles both batch processing (a bounded dataset, processed and finished) and streaming processing (an unbounded flow, processed continuously). It provisions and scales its own workers, so the operational surface is the job rather than the machines.

What to look at when a job is unhealthy:

Seeing all three subsections together shows how they typically chain into one pipeline, even though each was described in isolation:

A generalist or DevOps engineer's job in this pipeline is usually the two ends: getting data into Cloud Storage in the first place, and checking whether the Dataflow job in the middle succeeded or failed. Designing what the Dataflow job actually does internally is the specialist part this guide intentionally does not go deep on.

8. Infrastructure as Code and Deployment#

This section maps to ACE exam domain 3.6: high-level "what is this tool for," not deep syntax. Deeper Terraform or IaC mastery goes beyond both this guide and ACE's scope.

The reason this matters even at overview level: everything described in Sections 1 through 6 can be clicked together in the Console, and doing so at any scale is unmanageable. Infrastructure as code makes environments reproducible, reviewable, and recoverable.

8.1 The Tooling Landscape#

Cloud Deployment Manager is Google-native IaC using YAML, JSON, or Python templates; older, and being de-emphasized in favor of Terraform in Google's own guidance generally. Terraform is the industry-standard IaC tool with first-class GCP provider support, and likely the most relevant tool given industry direction, though the exam guide lists it alongside the others without stated preference.

Cloud Foundation Toolkit provides Google-provided reference Terraform modules and blueprints for common patterns. Config Connector lets you manage GCP resources as Kubernetes custom resources, declarative and GitOps-friendly for teams already in Kubernetes.

Helm is a Kubernetes package manager that packages and templates Kubernetes manifests; it is not GCP-resource-specific.

The tools split cleanly by what they actually manage:

Config Connector is the odd one out: it lets a team that already works entirely in kubectl apply manifests also provision GCP resources, like a Cloud SQL instance, the same way, rather than switching tools to do it.

The concept that matters most: state#

Declarative infrastructure tools work by comparing desired configuration against recorded actual state, then computing the difference. That state record is the critical artifact:

Two practical consequences of state. First, state must be stored somewhere shared and locked when a team collaborates, otherwise two engineers applying simultaneously can corrupt it. A Cloud Storage bucket is the usual choice for Terraform. Second, changes made by hand in the Console create drift, where reality and state disagree, and the next apply may try to "correct" the manual change or fail confusingly. Pick one path for making changes and stay on it.

Google also offers a managed service for running Terraform within GCP, which removes some of the state-hosting and execution burden. Verify its current name and capabilities in docs, since this offering is relatively recent.

8.2 Artifact Registry#

Artifact Registry is a universal package and container registry, connecting to GKE, Cloud Run, and Cloud Build. Know the IAM permissions needed for GKE nodes or service accounts to pull images from it.

It stores more than container images: language package formats are supported too, which lets one system hold both application dependencies and deployable artifacts.

Artifact Registry superseded the older Container Registry. If you encounter Container Registry in existing infrastructure or older documentation, it is the previous generation, and migration guidance exists. Verify current migration status and timelines in docs.

Where it sits in a deployment pipeline#

Two adjacent capabilities are worth recognizing by name:

• Vulnerability scanning inspects stored images for known vulnerable packages, which is the mechanism referenced in Tier 5's CI/CD notes.
• Binary Authorization can require that images be signed or attested before a deployment is permitted, which turns "we intend to only deploy scanned images" into an enforced control.

9. Operations: Monitoring and Logging#

This section maps to ACE exam domain 4.6, roughly 20% weight, and is one of the areas where real production competence and exam competence overlap most directly, worth real hands-on time regardless of certification goals.

A framing that makes this section cohere: logs tell you what happened, metrics tell you how much and how often, and traces tell you where the time went. Most operational questions need at least two of the three.

9.1 Cloud Monitoring#

Alerting policies are based on resource metrics such as CPU, latency, or error rate. Custom metrics can be ingested from application code, or extracted from logs as log-based metrics. Dashboards are useful for visualization, though less critical to master deeply.

The policy itself never touches the destination directly; it always goes through a notification channel, which is the same separation of concerns seen in Section 3's budget alerts: the trigger and the response are two different, independently configured pieces.

Metric types, and where they come from#

The most commonly missed metrics are memory and disk on VMs. These are not visible from outside the guest operating system, so a VM without the Ops Agent installed has no memory metrics at all. Teams discover this during an incident, which is the worst possible time.

Uptime checks and service-level objectives#

Two capabilities worth knowing beyond raw metrics:

• Uptime checks probe an endpoint from multiple locations and alert if it stops responding, which catches whole-service outages that internal metrics might not reflect.
• Service-level objectives let you define a reliability target (for example, a percentage of requests served successfully over a window) and track error budget consumption against it, which shifts alerting from "a metric moved" toward "we are at risk of missing our commitment."

Alerting that people actually respond to#

An operational point worth stating plainly, since it is where monitoring efforts usually fail: an alert that fires often and rarely requires action trains everyone to ignore it, including on the day it matters. Alerts should correspond to conditions a human needs to act on. Everything else belongs on a dashboard.

9.2 Cloud Logging#

Log buckets are storage containers for logs, with configurable retention. Log routers and sinks route logs to destinations, including BigQuery, Cloud Storage, Pub/Sub, or another log bucket, and support cross-project or external export. Log Analytics allows SQL-based querying over log data. Logs can be viewed and filtered in the Logs Explorer, including individual field details such as severity, resource labels, and payload.

Every log entry passes through the router once, and the router decides where copies of it go based on the sinks configured. A single log entry can end up in several destinations at once if multiple sinks match it.

Choosing a sink destination by purpose#

Exclusions, and why they save money#

Logging volume drives logging cost, and a substantial share of log volume is often routine noise such as health check requests. Exclusion filters drop matching entries before they are stored, which is the main lever for controlling logging spend without losing the entries that matter.

Two special buckets exist with different rules. Projects have a default bucket used when no other sink matches, and a separate required bucket that holds certain audit logs with a fixed retention period that cannot be shortened. Verify the current names and exact retention values in docs; the important structural point is that some audit retention is not adjustable.

Structured logging#

A log entry can be plain text or structured JSON. Structured entries are far more useful, because individual fields become filterable and can feed log-based metrics. Writing structured logs from application code is one of the highest-return habits for operability, and it costs almost nothing to adopt early.

9.3 Diagnostics Tooling#

Using logs and monitoring together to research an application issue is more scenario-reasoning than a distinct tool. The Google Cloud Status Dashboard helps distinguish a Google outage from your own configuration issue.

A workable triage order during an incident:

Checking the status dashboard first is not laziness; it prevents a team from spending an hour debugging their own healthy code during a platform incident. Checking recent changes second reflects that most self-inflicted outages follow a change.

9.4 Agents and Managed Collection#

The Ops Agent installs on VMs to collect in-guest metrics, such as memory and disk, that hypervisor-level monitoring cannot see, along with logs. Managed Service for Prometheus is the answer for teams already using Prometheus-format metrics, especially common with GKE workloads.

These solve different gaps rather than competing for the same job: the Ops Agent fills in what hypervisor-level monitoring cannot see on a VM, while Managed Service for Prometheus meets an application where it already is, without asking it to change its metrics format.

A practical note on rollout: installing an agent on every VM by hand does not scale, so agent installation belongs in the image or the instance template, as described in Section 4.1. A fleet where only some VMs have the agent produces monitoring gaps that are easy to miss until they matter.

9.5 Audit Logs#

Audit logs answer a different question from application logs: not "what did our software do" but "who did what to our infrastructure." They are the primary evidence trail for security review and incident investigation.

Admin Activity audit logs are always on and cannot be disabled; they record configuration and permission changes. Data Access audit logs record read and write of data itself, off by default for most services due to volume and cost, and must be explicitly configured.

There are four categories rather than two, and the two less-discussed ones are genuinely useful:

A common mistake, in production and on the exam. Do not assume Data Access logs are automatically available. They are often not.

That default has a real investigative consequence: after a suspected data exposure, the question "what did this account actually read?" may be unanswerable retroactively if Data Access logging was never enabled. Enabling it for sensitive datasets is a decision to make in advance, weighed against its volume and cost.

9.6 Lighter-Touch Tools#

Error Reporting aggregates and groups application errors. Cloud Trace provides latency and tracing across distributed requests. Cloud Profiler offers CPU and heap profiling for performance analysis. Know what each is for; deep mechanics are not necessary here.

Matching tool to question:

Cloud Trace earns particular attention in microservice architectures like Tier 4 and Tier 5. When a request passes through several services, aggregate latency metrics show that something is slow but not where. Distributed tracing attributes the time to a specific hop, which is the difference between a guess and a diagnosis.

10. CLI and Tooling Fluency#

This is not a distinct ACE exam section, but it is tested throughout via "which command is correct" questions, and it is genuinely how you will operate day-to-day. Practice continuously rather than as a one-time block.

10.1 gcloud#

The general structure is gcloud [GROUP] [SUBGROUP] [COMMAND] [FLAGS], for example gcloud compute instances create. Practice reading command output and recognizing wrong-but-plausible flags; that is the real-world skill, and the exam skill, not memorizing every flag. Config management includes gcloud config set project and working with multiple configurations.

Recognizing the grammar is more valuable than memorizing commands, because the pattern generalizes:

gcloud  compute      instances    create    my-vm    --zone=us-central1-a
        └─ group     └─ subgroup  └─ verb   └─ name  └─ flags

Once that shape is internalized, unfamiliar commands become guessable and, more importantly, wrong ones become recognizable.

Flags that pay for themselves#

The combination of --format and --filter is what makes gcloud scriptable. Extracting a single value cleanly, rather than parsing human-readable table output, is the difference between a reliable script and a fragile one.

Configurations, for working across projects#

gcloud supports named configurations, each holding its own active project, region, and account. Switching configurations switches all of it at once, which prevents the classic mistake of running a command against production while believing you were in staging.

Two different authentication commands exist and are easy to confuse. One logs in your own identity for gcloud commands. The other establishes credentials that application code running locally will pick up through Application Default Credentials. They serve different purposes, and using the wrong one produces confusing "works in the CLI but not in my code" symptoms. Check the current command names in docs.

10.2 gcloud storage and gsutil#

Google has been migrating documentation and tooling toward gcloud storage as the modern CLI surface over the older standalone gsutil. Confirm which is currently emphasized in official docs and any current exam materials, since this transition has been ongoing.

Both address Cloud Storage objects using a gs://bucket/object URI scheme. Common operations are copy, move, remove, list, and recursive variants of each for whole prefixes.

Recursive delete against a bucket path is exactly as dangerous as it sounds. There is no recycle bin unless object versioning is enabled. Verify the path twice, and prefer enabling versioning on buckets holding anything you would miss.

10.3 kubectl#

Core verbs are get, describe, apply -f, delete, logs, and exec. Context switching between clusters uses kubectl config.

kubectl is not a GCP tool; it is the standard Kubernetes client, which is why its patterns look different from gcloud. The connection point between the two is gcloud container clusters get-credentials, covered in Section 4.2.

Always know which context and namespace you are in. kubectl commands silently apply to the current context, so a command intended for a staging cluster will happily run against production if that is what the context points at. Checking context before acting is a habit worth building early.

10.4 Cloud Shell and Console#

Cloud Shell is a free, pre-authenticated environment with gcloud and kubectl pre-installed, often the fastest path through hands-on labs. General Console navigation fluency, knowing where IAM, billing, and monitoring live, matters more for labs than for the exam itself.

Cloud Shell is genuinely useful beyond convenience: it comes already authenticated, has the tooling installed, and includes a small amount of persistent home-directory storage. For a quick administrative task, or for verifying something without configuring a local environment, it removes all the setup friction.

Cloud Shell sessions are ephemeral apart from the home directory. Software installed outside your home directory does not survive a session ending. Treat it as a convenient terminal, not as a place to build long-lived tooling.

A note on the Console versus the CLI: the Console is excellent for exploration, for understanding what options exist, and for reading dashboards. It is a poor foundation for anything repeatable, which is where the CLI and the infrastructure-as-code tooling from Section 8 belong. A useful habit is exploring in the Console, then codifying what worked.

11. Practice and Reinforcement#

Reading this guide builds recognition. Operating GCP requires something closer to muscle memory, and the gap between the two closes only through hands-on work.

11.1 Hands-On Lab Mapping#

Pair each section above with at least one lab before moving on. Prioritize labs for Section 1, Section 2, Section 6, and Section 9 if those are your least-familiar areas, and use the GCP free tier or free credits rather than reading-only prep for them.

The reason those four in particular: IAM, service accounts, networking, and operations are the areas where reading produces the strongest false confidence. The concepts are simple to state and genuinely fiddly to execute, and the gap only becomes visible when something does not work.

Watch for costs while learning. Free tier and credits cover a lot, and a few resources are easy to leave running expensively, particularly GKE clusters, reserved static IP addresses, and provisioned database instances. Delete lab resources when finished, and set a budget alert on the learning project as an early safeguard.

11.2 Building Real Judgment#

The fastest way to internalize the compute, storage, and database decision frameworks in Sections 4 and 5 is to actually build the progressive architecture from Section 0.6 yourself, tier by tier, rather than just reading it.

Try breaking your own setup on purpose (revoke a permission, misconfigure a firewall rule, delete a service account) and diagnosing it with Cloud Logging and Monitoring; this builds the operational instinct that reading alone does not.

Deliberate breakage is worth structuring rather than doing at random. Each of these produces a distinct and instructive failure signature:

The goal is pattern recognition. During a real incident, the useful skill is not knowing every answer but recognizing a failure shape quickly enough to narrow the search.

11.3 If You Are Also Pursuing ACE Certification#

Use Google's official Associate Cloud Engineer sample questions (20 items, unlimited retakes), the "Preparing for the Associate Cloud Engineer Examination" course on Google's learning platform, and the Cloud Engineer learning path for structured hands-on labs.

Save full-length timed practice exams for the final one to two weeks of prep, once all sections above have had at least one pass, and use results to identify which domain, not just which question, is weak, routing back to the relevant section.

A few observations on how this exam tends to be written, useful for calibration:

• Questions are usually scenario-shaped rather than definitional. The skill being tested is matching a described situation to the right service or configuration, which is exactly what the decision trees in Sections 4 through 6 are for.
• When several answers would technically work, the intended one is usually the most managed, most least-privilege, or most Google-recommended option. Basic roles, downloaded key files, and manual VM management are rarely the intended answer.
• Distractors often use plausible but wrong product names or flags, which is why CLI familiarity from Section 10 pays off even though no section of the exam is explicitly about the CLI.

Do not rely on remembered numbers for the exam. Storage class durations, quota defaults, timeout maximums, and pricing figures all change, and this guide deliberately flags rather than asserts them. Confirm current values in official documentation as part of final preparation.

This guide reflects a snapshot in time. It follows official GCP documentation and the ACE exam guide as published on Google's certification page at the time of writing. Google revises product names, limits, and the ACE exam guide itself periodically (the guide explicitly mentions a recent branding-related update), and specifics like storage-duration numbers or CLI tooling emphasis shift even more often.

Before relying on anything above: if using this for certification prep specifically, re-check the live guide at cloud.google.com/learn/certification/guides/cloud-engineer before the exam date. For general production use, treat anything flagged "verify in docs" above as exactly that.