Associate Cloud Engineer exam map

This map is built from Google's Associate Cloud Engineer exam guide (retrieved 2026-09-22) and from this hive's own contents. Google publishes no exam code, no guide version and no passing score for this certification; "GCP-ACE" is this hive's internal label, not Google's.

The exam, as Google publishes it

• Format: 50-60 multiple choice and multiple select questions
• Time: 120 minutes
• Validity: 3 years
• Languages: English, Japanese, Spanish, Portuguese
• Passing score: not published by Google

Sections and weights

Google attaches an approximate percentage to each section and to nothing below it. The counts are this hive's.

How this hive is organised

• A lecture deck for every topic — 19 decks, one per topic in the exam guide, each teaching every objective under it. Every factual claim on a slide is pinned to an exact excerpt from an official Google Cloud page.
• 490 practice questions, each citing the Google Cloud documentation page its answer comes from, with the supporting quote recorded.
• 8 blueprint-weighted mock exams of 54 questions, dealt in proportion to the section weights (11/9/13/11/10 seats per section). No question appears in more than one mock.
• 375 flashcards, one collection per objective, each card traceable to Google's documentation.
• A study guide per topic (below): the topic's lecture in reading form.

Names in the exam guide that Google has since changed

The exam guide still uses these names, so expect them on the exam. Google's current documentation uses the second column, and the decks teach both.

Unit 1 roadmap — Setting up a cloud solution environment

Every objective below is quoted from Google's Associate Cloud Engineer exam guide, retrieved 2026-09-22. Under each topic is that topic's own summary of what the exam actually tests, taken from its lecture.

Topic 1 — Setting up cloud projects and accounts

ACE-U1.T1 · 7 objectives · lecture deck of 16 slides

1. Creating a resource hierarchy
2. Applying organizational policies to the resource hierarchy
3. Granting members IAM roles within a project
4. Managing users and groups in Cloud Identity (manually and automated)
5. Enabling APIs within projects
6. Provisioning and setting up products in Google Cloud’s operations suite
7. Assessing quotas and requesting increases

What this topic actually tests. Where does it attach? a role or a policy on a folder reaches every project inside it. Who or what? IAM grants who; Organization Policy restricts what. Which identity path? Admin console by hand, GCDS from a directory — one way, no passwords. Which limit? a quota can be raised; a system limit cannot.

Topic 2 — Managing billing configuration

ACE-U1.T2 · 4 objectives · lecture deck of 14 slides

1. Creating one or more billing accounts
2. Linking projects to a billing account
3. Establishing billing budgets and alerts
4. Setting up billing exports

What this topic actually tests. Create: one currency per account, Billing Account Creator on the organization, close but never delete. Link: exactly one account per project, a role on EACH side, a closed account switches billing off. Budget: thresholds on actual or forecast, alerts never cap, Pub/Sub if something must happen. Export: BigQuery, same billing account, turn it on early — only multi-region cost data back-fills.

Setting up cloud projects and accounts

Study guide for Associate Cloud Engineer, Unit 1 · Topic 1. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Setting up cloud projects and accounts. Considerations include:

1. Creating a resource hierarchy
2. Applying organizational policies to the resource hierarchy
3. Granting members IAM roles within a project
4. Managing users and groups in Cloud Identity (manually and automated)
5. Enabling APIs within projects
6. Provisioning and setting up products in Google Cloud’s operations suite
7. Assessing quotas and requesting increases

Setting up cloud projects and accounts

Seven jobs an engineer does before anything is deployed

Structure — the resource hierarchy and the organization policies attached to it. People — IAM roles in a project, and the users and groups in Cloud Identity who receive them. Readiness — enable the APIs, set up observability, and check the quotas before a workload needs them.

This is the first topic of the Associate Cloud Engineer exam, and every objective in it is something you do rather than something you explain. The guide lists seven considerations for setting up cloud projects and accounts. They fall into three groups. Structure: creating the resource hierarchy, and applying organization policies to it. People: granting identity and access management (IAM) roles within a project, and managing the users and groups in Cloud Identity who receive those roles, both by hand and automatically. And readiness: enabling the application programming interfaces (APIs) a project needs, setting up the observability products, and checking quotas before a workload runs into one. The exam asks these as tasks — which command, which console page, which resource to attach something to — so this deck shows the commands Google documents for each job, and the reason each one is shaped the way it is.

Creating a resource hierarchy

Organization at the root, folders to group, projects to hold resources

• The organization resource is the root node — it stands for the company
• Folders are optional; they hold projects, other folders, or both
• Projects hold the actual resources: VMs, buckets and the rest
• Every resource except the root has exactly one parent

Worked example (synthetic). A retailer creates folders for Production, Development and Shared, then creates each new project inside the folder it belongs to — so a later rule attached to Production reaches every production project at once.

The first objective is building the hierarchy, and Google describes its shape in one sentence: the organization at the top as the root, folders as an optional grouping layer, and then projects, which contain the actual service resources such as Compute Engine virtual machines (VMs) and storage buckets. The organization resource represents an entity such as a company and serves as the root node. A folder can contain projects, other folders, or a combination of both, and Google names three reasons to use them: to delegate administrative duties, to enforce environment-specific organization policies, and to streamline cost management across departments. The one structural rule that makes everything else work is this: all resources except the highest one in a hierarchy have exactly one parent. That single parent is why inheritance is predictable — a role or a policy attached higher up reaches everything below it. And the organization changes who owns the work: with an organization resource, your projects belong to your organization, not to the employee who created them. Managed users in the company's domain must create projects inside the organization; they cannot create a project that is not associated with it.

Three identifiers for one project

Only one of them is chosen by you and can never change

Worked example (synthetic). A team creates acme-web-prod as its project ID, then the product is renamed. The project name can follow the rename; the project ID stays acme-web-prod for the life of the project.

Every project carries three identifiers, and the exam likes to swap them. The project name is the human-readable one: Google says you can edit it at any time during or after project creation, and project names don't need to be unique. The project identifier, the project ID, is different in both respects. It is a unique string that differentiates your project from all others in Google Cloud, and after project creation it is permanent. The third, the project number, is an automatically generated unique identifier that you never choose. So when a scenario says a team wants to rename its project, the answer turns on which of the three it means — the name can follow a rebrand, the ID cannot, and the number was never the team's to pick.

Building the hierarchy from the command line

Create the folder, then create the project inside it

Figure. Three command cards: creating a folder under the organization with gcloud resource-manager folders create, creating a project inside a folder with gcloud projects create and the folder flag, and creating a project with no parent flag.

Worked example (synthetic). An engineer scripts a new environment: one folders create call, then a projects create … --folder call per project. Passing both --folder and --organization fails, because a project has one parent.

Here is the same hierarchy built with the gcloud command-line tool. Google's folder page says that to create a folder under the organization resource using the gcloud command-line tool, you run gcloud resource-manager folders create, with a display name and the organization's identifier. Projects are created with gcloud projects create followed by the project identifier. To give the project a parent, the projects page says to use the organization flag or the folder flag — and then the rule from the previous slide appears as a command-line restriction: as a resource can only have one parent, only one of these flags can be used. So a project inside a folder is gcloud projects create, the project identifier, and the folder flag with the folder's identifier. The exam's favourite wrong answer is a command passing both flags, or a folder command used to create a project.

Applying organization policies to the hierarchy

Attach once, and every descendant inherits it

Figure. An organization resource at the root with three folders — Production, Development and Shared — each holding one project. An organization policy is attached to the Production folder, and the callout says it is inherited by every project inside that folder and by no project outside it.

Worked example (synthetic). Security wants every production project limited to approved locations. One organization policy on the Production folder does it — including for production projects created next year.

The second objective puts constraints onto that hierarchy. Google says the Organization Policy Service gives you centralized and programmatic control over your organization's resources, and it is built on constraints: a constraint is a particular type of restriction against a Google Cloud service or a list of services — restricting the physical location of newly created resources is one of Google's own examples. An organization policy is set on an organization, folder or project resource, and it enforces the constraint on that resource and any child resources. The figure shows why the attachment point is the whole decision. The policy sits on the Production folder, so descendants of the resource to which the organization policy is attached inherit it: every production project, including ones created later, and none of the development or shared ones. Each organization policy enforces exactly one constraint, in active mode, dry-run mode, or both — so a folder with three restrictions carries three policies, not one.

Organization Policy against IAM, and the commands

IAM decides who; Organization Policy decides what

Worked example (synthetic). A developer holds the Owner role on a project but cannot create a resource outside the approved locations. Nothing is wrong with the IAM grant: an organization policy limits what can be configured, whoever asks.

The distinction the exam tests most is between organization policy and identity and access management (IAM), and Google draws it in two sentences. IAM focuses on who, and lets the administrator authorize who can take action on specific resources based on permissions. Organization Policy focuses on what, and lets the administrator set restrictions on specific resources to determine how they can be configured. That is why an Owner can still be refused: the role answers who, and the policy answers what. The commands follow the same lifecycle. You write the policy to a file and run gcloud org-policies set-policy with that file. Because a policy set on a resource can merge with any policy inherited from its parent, you check the result with describe and the effective flag, which returns the organization policy as it is evaluated at that point in the hierarchy with inheritance included. And the reset command resets the policy to use the constraint's default behavior.

Granting members IAM roles within a project

An allow policy binds principals to roles, on a resource and below it

• Access is granted through allow policies, also called IAM policies
• Each role binding ties principals — users, groups, service accounts — to a role
• A grant on a project also reaches every resource inside it
• Console: the IAM page; command line: add-iam-policy-binding

Worked example (synthetic). An engineer grants a support group a role on the web-prod project: gcloud projects add-iam-policy-binding web-prod --member=group:support@example.com --role=ROLE_NAME. Every resource in the project is now covered.

The third objective is the grant itself. In identity and access management (IAM), Google says, access is granted through allow policies, also known as IAM policies. Each allow policy contains a collection of role bindings that associate one or more principals, such as users or service accounts, with an IAM role — and common types of principals include Google Accounts, service accounts, Google groups and domains. The binding works downward: role bindings grant the roles both on the resource the allow policy is attached to and on all of that resource's descendants. So a role granted on a project reaches every resource in the project. There are two everyday ways to make the grant. In the console, go to the IAM page. On the command line, the add-iam-policy-binding command lets you quickly grant a role to a principal — gcloud projects add-iam-policy-binding, the project, a member such as a user or a group, and the role. Granting to a group rather than to each person is what makes the next objective, managing users and groups, pay off.

Which kind of role to grant

Broad, granular, or exactly the permissions you list

Worked example (synthetic). A network team needs to manage networking in production. Granting Editor would also let it delete databases; the predefined Compute Network Admin role gives it the networking job and nothing else.

Which role to put in the binding is the second half of the objective. Google names three types. Basic roles provide broad access to Google Cloud resources — the legacy basic roles are Owner, Editor and Viewer — and Google's guidance on them is blunt: in production environments, do not grant basic roles unless there is no alternative. Predefined roles provide granular access for a specific service and are managed by Google Cloud; Google's own example of a user holding several is the Compute Network Admin and Logs Viewer roles on a project. Custom roles provide granular access according to a user-specified list of permissions, and Google says they help you enforce the principle of least privilege, so principals have only the permissions they need. On the exam, a scenario that says production and names a narrow job almost always wants the predefined role for that job, and treats Editor as the distractor.

Managing users and groups in Cloud Identity

By hand in the Admin console, or synchronized from your directory

• Cloud Identity centrally manages users and groups; IAM then grants them access
• Manually: add users and create groups in the Google Admin console
• Automated: GCDS synchronizes users and groups from Active Directory
• Dynamic groups keep membership current from employee attributes

Worked example (synthetic). A startup with twelve staff adds each person in the Google Admin console. A bank with thousands of staff in Active Directory runs Google Cloud Directory Sync instead, so a leaver disabled in its directory is disabled for Google Cloud too.

The fourth objective asks for users and groups in Cloud Identity, and the guide specifies both manual and automated. Cloud Identity is an identity-as-a-service solution that centrally manages users and groups, and you can then use identity and access management (IAM) to manage access for each Cloud Identity account. The reason to bother is control: if developers use personal accounts, such as Gmail accounts, those accounts are outside of your control. The manual path is the Google Admin console — Google's setup guide notes that you might later return to the Admin console to add more users and create groups. The automated path matters once a directory already exists. Google says manually maintaining Google identities for each employee can add unnecessary management overhead when all employees already have an account in Active Directory, and that by federating, you can automate the maintenance of Google identities and tie their lifecycle to existing users. The tool is Google Cloud Directory Sync (GCDS), a free Google-provided tool that implements the synchronization. Two details are tested: provisioning works one way, from Active Directory to Google Cloud, and provisioning does not include passwords. Dynamic groups add a middle path — memberships managed automatically from a query on employee attributes such as job role.

From the directory to a role binding

Identities flow one way; access is granted on the Google side

Figure: A flow chart: Active Directory users and groups are synchronized one way, without passwords, by GCDS into Cloud Identity; users can also be added manually in the Google Admin console. A Cloud Identity group then receives an IAM role binding on a project.

Worked example (synthetic). An administrator grants the web-admins group a role on web-prod once. Every new hire synchronized into that group from Active Directory gets the access with no IAM change at all.

Drawn out, the fourth objective connects to the third. Identities enter Cloud Identity by one of two doors: synchronized from Active Directory by Google Cloud Directory Sync (GCDS), or added by hand in the Google Admin console. The synchronization arrow only points one way — Google says changes in Active Directory are replicated to Google Cloud but not the other way around — and it carries users and groups, not passwords. Access is not synchronized at all. It is granted on the Google side, as an identity and access management (IAM) role binding, and the figure shows the binding going to a group rather than to people. That is the practical pay-off: once the group holds the role, provisioning a new member into the group from the directory is all it takes to give that person access, and removing them from the group in the directory removes it.

Enabling APIs within projects

Most APIs are off until you turn them on, per project

Figure. Four cards: enabling an API in the console under APIs and Services, the gcloud services enable and disable commands, the Service Usage Admin role needed to do it, and the guidance to use the console for one-off changes and the command line for scripts.

Worked example (synthetic). A deployment script fails on its first Compute Engine call in a new project. The fix is one line before it — gcloud services enable compute.googleapis.com — run by someone holding Service Usage Admin.

The fifth objective is short and it catches people. Google's Service Usage overview says that before you can use most Google application programming interfaces (APIs), you must first enable them in a Google Cloud project. The service that does it is Service Usage itself, which you can use to enable or disable any available service for your projects. In the console you select the project, find the API and click Enable. On the command line, the gcloud services enable command enables a service with the name specified for the current project, and gcloud services disable does the reverse. Google's own guidance on which to use is practical: most users can enable and disable services with the console, and for scripts, use the command line. The permission matters too — to enable and disable services you need the Service Usage Admin role on the project. So when a new project's first API call fails, the first question is not the code; it is whether the API was ever enabled in that project.

Setting up Google Cloud Observability

The guide's “operations suite” is Google Cloud Observability today

• Monitoring, Logging and Trace are on by default in every new project
• Telemetry for most Google Cloud services is collected automatically
• Inside Compute Engine VMs, install the Ops Agent to collect telemetry
• To watch several projects from one, configure a metrics scope

Worked example (synthetic). A team wants memory and disk metrics from inside its Compute Engine VMs and one dashboard across three projects. It installs the Ops Agent on the VMs and adds the other two projects to its project's metrics scope.

The sixth objective uses the guide's old name, Google Cloud's operations suite. Google's documentation now calls it Google Cloud Observability — observability services that help you understand the behavior, health and performance of your applications — so expect either name. Setup is lighter than candidates expect, because most of it is already on: Google says Monitoring, Logging and Trace are enabled by default when you create a Google Cloud project, and telemetry data is collected automatically for most Google Cloud services. Two setup tasks remain, and both are tested. The first is inside virtual machines (VMs): the Ops Agent is the primary agent for collecting telemetry from your Compute Engine instances. The second is scope. By default, the metrics scope of a project only includes that project; if you want to chart and monitor data collected by multiple projects, some configuration is required. Cloud Logging, for its part, is a real-time log-management system with storage, search, analysis and monitoring support, and Trace follows the flow of a request through spans.

What is on already, and what you set up

Three services arrive enabled; two tasks are yours

Worked example (synthetic). An exam item offers "enable the Cloud Monitoring API" as the first step for a brand-new project. It is already enabled; the real first step for in-VM metrics is the Ops Agent.

This table is the objective reduced to what an engineer actually has to do. Monitoring, Logging and Trace are enabled by default when a project is created, so any answer that begins by switching them on is a distractor. Telemetry for most Google Cloud services is collected automatically. What is not automatic is telemetry from inside your own virtual machines (VMs), which is the Ops Agent's job — Google calls it the primary agent for collecting telemetry from Compute Engine instances. And what is not automatic is a view across projects: the metrics scope of a project defines the set of resource containers whose time-series data the project can chart and monitor, and by default it holds only that project. So a central operations project that must watch production and development needs its metrics scope configured to include them.

Assessing quotas and requesting increases

Quotas can be raised on request; system limits cannot

• Allocation quotas cap how much you hold; rate quotas cap how fast you use
• System limits are fixed — they cannot be increased or decreased
• Assess on IAM & Admin > Quotas & System Limits
• Request increases per project; the quota adjuster can request them for you

Worked example (synthetic). A project cannot create another VM because it has reached its allocation quota. The engineer finds the quota on the Quotas & System Limits page and requests an increase for that project.

The last objective is quotas, and Google explains their purpose first: quotas protect the community of Google Cloud users by preventing the overloading of services. There are two kinds the exam separates. Allocation quotas restrict how much of a resource Google Cloud allocates to you — the number of virtual machines in a project is Google's example. Rate quotas restrict the rate at which you can consume a resource. And beside both sit system limits, which Google calls fixed constraints, such as maximum file sizes, which cannot be increased or decreased. That last sentence is the trap: a scenario that hits a system limit is not solved by any request. Assessing quotas happens in the console's identity and access management (IAM) and Admin section, on the Quotas and System Limits page, which lists quota usage and values for the project, and quotas can also be managed through the Cloud Quotas application programming interface (API) and the command line. Requests are mostly per project — Google says that in most cases, quota increase adjustments must be made at the project level. And the quota adjuster can do the watching for you: it observes your consumption and proactively submits adjustment requests on your behalf, while you can still request increases manually at any time.

A request is refused: which limit was it?

Name the limit before you ask for more

Figure: A decision flow: when a request is refused for exceeding a limit, first ask whether it is a system limit, which is fixed and must be designed around. If it is a quota, ask whether it is an allocation or a rate quota, and request an increase for the project on the Quotas and System Limits page, or let the quota adjuster request it.

Worked example (synthetic). Two failures reach an on-call engineer: a VM count reached and a file too large for a service. The first is a quota to raise; the second is a system limit, and no request will move it.

The figure turns the objective into the order an engineer should think in. The first question is not how to ask for more, but which kind of limit refused the request. If it is a system limit, it is fixed — Google says system limits cannot be increased or decreased — and the only answer is to design around it. If it is a quota, the next question is its kind. An allocation quota, such as the number of virtual machines in a project, is raised by requesting an increase for that project on the Quotas and System Limits page. A rate quota restricts how fast a resource is consumed, so an increase request is one answer and spreading the calls over time is another. And for quotas that approach their values regularly, the quota adjuster observes consumption and submits the requests proactively, without anyone watching a dashboard.

What this topic actually tests

Where it attaches, who versus what, and which limit

Where does it attach? a role or a policy on a folder reaches every project inside it. Who or what? IAM grants who; Organization Policy restricts what. Which identity path? Admin console by hand, GCDS from a directory — one way, no passwords. Which limit? a quota can be raised; a system limit cannot.

Close the topic on the four decisions the exam keeps returning to. First, attachment: every resource has one parent, so a role or an organization policy attached to a folder reaches every project inside it and none outside it — choose the attachment point, not the list of projects. Second, who against what: identity and access management (IAM) authorizes who can act, Organization Policy restricts how resources can be configured, which is why an Owner can still be refused. Third, the identity path: users and groups are added by hand in the Google Admin console, or synchronized one way from Active Directory by Google Cloud Directory Sync (GCDS), without passwords, and then granted roles as groups. Fourth, the limit: allocation and rate quotas can be raised by a request for the project, while system limits are fixed. Add the two readiness habits — enable the application programming interface (API) before the first call, and install the Ops Agent for metrics from inside a virtual machine (VM) — and this topic's commands will read as tasks rather than trivia.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 1
• Resource hierarchy — Resource Manager
• Creating and managing folders — Resource Manager
• Introduction to the Organization Policy Service
• Manage access to projects, folders, and organizations — IAM
• Overview of Cloud Identity
• Set up Cloud Identity as a Google Cloud admin
• Federating Google Cloud with Active Directory
• Groups API overview — Cloud Identity
• Service Usage overview
• Enabling and disabling services — Service Usage
• Google Cloud Observability overview
• Ops Agent overview — Cloud Monitoring
• Metrics scopes overview — Cloud Monitoring
• Cloud Logging overview
• Cloud Quotas overview
• View and manage quotas — Cloud Quotas
• Quota adjuster — Cloud Quotas
• Creating and managing projects — Resource Manager
• Creating and managing organization policies
• Roles and permissions — IAM

Managing billing configuration

Study guide for Associate Cloud Engineer, Unit 1 · Topic 2. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Managing billing configuration. Considerations include:

1. Creating one or more billing accounts
2. Linking projects to a billing account
3. Establishing billing budgets and alerts
4. Setting up billing exports

Managing billing configuration

Four tasks: create, link, budget, export

Create a Cloud Billing account — or more than one. Link each project to exactly one. Budget it, knowing an alert is not a cap. Export it to BigQuery, early, because not all of it back-fills.

This topic is four tasks an engineer actually performs, and the exam asks them as tasks: which account, which role, which command, which setting. Creating one or more Cloud Billing accounts. Linking projects to a billing account. Establishing billing budgets and alerts. And setting up billing exports. The Cloud Digital Leader exam asked why these controls matter; the Associate Cloud Engineer exam asks you to do them, so this deck is about mechanics — who holds which identity and access management (IAM) role on which side of the link, what the command-line interface (CLI) command is, and what the console does by default that you might not expect. Two defaults are worth holding before we start. A budget alert does not stop spending. And the billing export does not always reach back in time.

Creating a Cloud Billing account

Self-serve or invoiced, one currency, and who may create it

• Self-serve: created online, paid automatically; invoiced: configured by Google
• One currency per account, fixed by the country chosen — and never changeable
• Inside an organization, creating one needs Billing Account Creator
• The creator becomes its Billing Account Administrator; accounts close, never delete

Worked example (synthetic). An engineer in an organization clicks Create account and is refused. Nothing is wrong with the payments profile: the engineer lacks Billing Account Creator on the organization node.

Every project that uses Google Cloud needs a Cloud Billing account behind it — Google says you need a Cloud Billing account to use Google Cloud at all. There are two kinds. Self-serve accounts you create online, and they pay usage costs automatically from a payment method. Invoiced accounts pay by monthly invoice, and Google configures those for you — you cannot click one into existence. Three facts about creating an account are exam material. First, an account operates in a single currency and is linked to a Google payments profile, and the currency follows the country you choose, which cannot be changed later; if the country is wrong, the fix is a new billing account. Second, permission: if your resources are managed under an organization node and you are a member of it, you must hold Billing Account Creator on the organization node to create a Cloud Billing account. Third, whoever creates the account is by default its Billing Account Administrator. And one fact about the end of an account's life: Cloud Billing accounts cannot be manually deleted. You can close one, which stops all billable services in every project linked to it — virtual machine (VM) instances and storage buckets included.

When one billing account is not enough

The guide says "one or more" — here is what forces the second

Worked example (synthetic). A company opens an office in a second country and wants that office's cloud costs paid in its local currency. That is a second Cloud Billing account, not a setting on the first.

The guide's wording is creating one or more billing accounts, so the exam will test when one is not enough. Google's pages give four concrete triggers. A second country or currency needs a second account, because each account operates in a single currency. A wrong country needs a new account, because Google says that to edit the country on an existing account you will need to create a new billing account. Monthly invoicing needs an invoiced account, which Google configures rather than you. And a reseller uses subaccounts: Google says subaccounts are intended for resellers, and they group charges from projects on a separate section of the invoice. To see which accounts you can already use, the command is gcloud billing accounts list, which lists all billing accounts and subaccounts owned by the currently authenticated user.

The billing roles, by what each lets you do

Creating, administering, linking and viewing are four different grants

Figure. Six cards naming the Cloud Billing roles and what each allows: Billing Account Creator creates accounts, Billing Account Administrator manages them, Billing Account User and Project Billing Manager together link projects, Billing Account Costs Manager manages budgets and exports, and Billing Account Viewer reads costs.

Worked example (synthetic). Finance wants to see monthly costs but must never move a project between accounts. Billing Account Viewer gives exactly that; Billing Account User would give more than asked.

These six roles are the vocabulary of every question in this topic, so learn them by what they let you do rather than by name. Billing Account Creator creates accounts, and inside an organization it is required on the organization node. Billing Account Administrator manages an account, and Google says the person who creates an account holds it by default. Linking takes two roles, one on each side: Billing Account User on the billing account, combined with Project Billing Manager on the project, lets users link and unlink projects — and the Project Owner role is a superset of Project Billing Manager, so an owner already has the project side. Billing Account Costs Manager is for people who run budgets and exports without touching links. And Billing Account Viewer, which Google says is usually granted to finance teams, reads costs and nothing more. When a question asks for the least role that does a job, the answer is almost always the narrower of two that both work.

Linking projects to a billing account

One account per project; many projects per account; two sides to permit

Worked example (synthetic). A developer is Project Owner but cannot link the project to the team's billing account. The missing half is on the other side: Billing Account User on the billing account.

Linking has a small set of rules, and each one has been an exam question. A project is linked to exactly one Cloud Billing account at a time, while an account is linked to one or more projects. Billing is enabled when the project is linked to an active account, and the converse bites: if the account is later closed or suspended, billing is no longer enabled on any of its projects. To link or move a project you need both project permissions and billing account permissions — the combination on the previous slide, Billing Account User on the account and Project Billing Manager or Project Owner on the project. And moving a project between accounts is safe: Google says switching a project to a different account should not result in any service interruption or server downtime. Once linked, you can optionally lock the link to stop a project being moved or unlinked by accident.

Two relationships over the same projects

The organization owns the project; the billing account pays for it

Figure: A diagram of two separate relationships over three projects. Solid arrows show the organization owning each project as its IAM parent. Dashed arrows show a Cloud Billing account paying for each project through payment linkage. The billing account is also connected to a Google payments profile.

Worked example (synthetic). A project is moved to another folder in the hierarchy. Its permissions change; who pays for it does not, because payment linkage is a different relationship.

This is the idea that makes the linking rules make sense. Google says two types of relationships govern organizations, billing accounts and projects: ownership and payment linkage. Ownership refers to identity and access management (IAM) permission inheritance — the organization is the parent from which a project's permissions flow. Payment linkage defines which Cloud Billing account pays for a given project. They are drawn as two kinds of arrow over the same three projects because they are independent. Moving a project in the resource hierarchy changes who can act on it and leaves who pays untouched; re-linking a project to another billing account changes who pays and leaves permissions untouched. That independence is why linking needs a role on each side — one relationship's permissions cannot grant the other.

Linking from the command line

One command links, moves — or, pointed at a closed account, switches off

Figure. A code panel with three commands: gcloud billing accounts list to see available accounts, gcloud billing projects link with a project ID and a billing account ID to link or move a project, and gcloud beta billing projects describe to check the result. A note beneath says link moves an already-linked project, and linking to a closed account disables billing.

Worked example (synthetic). A script re-links forty projects after a reorganisation and one account ID in its list belongs to a closed account. Those projects' paid resources shut down — the command did exactly what it says.

On the command line the task is three commands. gcloud billing accounts list shows the accounts and subaccounts you own. gcloud billing projects link sets or updates the billing account associated with a project — and Google's reference is explicit that if the project is already linked, the command moves it to the account you specify, so link and move are the same command. Then, to check, Google's verification page uses gcloud beta billing projects describe to show a project's billing information. The warning on the reference page is the one to remember: associating a project with a closed billing account has the same effect as disabling billing on the project — any paid resources in use are shut down, and the application stops functioning. The command does not ask whether you meant it.

Establishing billing budgets and alerts

Scope, amount, period, thresholds — and it does not stop spending

• Scope: the whole account, or projects, services or labelled resources
• Amount: a figure you set, or last period's spend; period monthly to custom
• Threshold rules on actual or forecasted cost trigger the alert emails
• By default, alerts go to the account's billing administrators and users
• An alerts-only budget never caps spending; Pub/Sub can automate a response

Worked example (synthetic). A team sets a budget with a threshold at its full monthly amount, gets the email, and spending keeps rising. The budget behaved as documented: it alerts, it does not cap.

A budget is four settings and one caveat. Scope: a budget can apply to the entire Cloud Billing account or be scoped to specific projects, services or labelled resources — though labels applied to a project are not available as a budget scope. Amount: a total you specify, or the previous calendar period's spend. Period: monthly, quarterly, yearly or a custom range. And threshold rules, which trigger the alert emails when actual costs or forecasted costs exceed a share of the budget — forecasted is the one that warns you before the money is gone. Recipients default to the billing administrators and users on the account. Now the caveat, which Google prints as a caution: setting an alerts-only budget doesn't automatically cap usage or spending. If you need something to happen, Pub/Sub carries programmatic notifications, and Google's own example of what to automate is programmatically disabling Cloud Billing on a project. One more permission detail: someone with little or no access to the billing account can still create budgets for each project they own, using billing-specific project permissions.

What a crossed threshold actually does

An email always; an action only if you wired one

Figure: A flow chart: actual or forecasted cost is checked against a threshold rule. When crossed, an alert email goes to billing administrators and users, after which spending continues until someone acts. If a Pub/Sub topic is connected, the notification also reaches automation such as disabling billing on the project.

Worked example (synthetic). A sandbox project must never exceed its budget. An email alone cannot guarantee that; a Pub/Sub topic feeding an automated response to disable billing can.

Drawn out, the budget's behaviour has two branches, and only one of them happens by default. When actual or forecasted cost crosses a threshold rule, an alert email goes to the recipients — by default the billing administrators and users. After that, the diagram's bottom right is the point: spending continues until someone acts, because an alerts-only budget does not cap anything. The other branch exists only if you build it. Google says you can set up and use programmatic notifications to automate cost control responses, delivered through Pub/Sub; the automation at the end is yours, and disabling billing on the project is Google's own example of it. So when a scenario says spending must stop, not merely be reported, the answer involves the second branch.

A budget from the command line

Thresholds are fractions of 1.0, and forecast is a basis

Figure. A code panel showing gcloud billing budgets create with a billing account, a display name, a budget amount, a project filter, one threshold rule at 0.5 on actual spend and one at 0.9 on forecasted spend. A note explains that percent is 1.0-based and that --last-period-amount can replace --budget-amount.

Worked example (synthetic). An engineer writes percent=50 expecting half the budget and the command is rejected. The flag takes a number between 0.0 and 1.0 — half is 0.5.

The command-line version makes every setting visible. gcloud billing budgets create takes the billing account and a display name, then either a budget amount or the flag to use last period's amount. The filter flags set the scope — here, one project. Then the threshold rules: Google's reference describes a threshold rule as the rule that triggers alerts when spend exceeds the specified percentages of the budget, and it adds the detail that catches people — the value is a one-point-zero-based percentage, so zero point five equals fifty percent. The second rule adds basis equals forecasted spend, which fires on the forecast rather than on money already spent. The flag can be repeated for as many thresholds as you want.

Setting up billing exports

BigQuery, a project on the same account, and turn it on early

• Export sends billing data to a BigQuery dataset throughout the day
• The dataset's project should be linked to the SAME billing account
• Needs Costs Manager or Administrator on billing, BigQuery User on the project
• Only multi-region datasets back-fill; pricing data never does

Worked example (synthetic). A team enables the export in a single-region dataset in March and asks for January's costs in BigQuery. They are not there: regional datasets start from the day export was enabled.

Google's billing export today means Cloud Billing export to BigQuery: it exports detailed billing data — usage, cost estimates and pricing data — automatically throughout the day to a BigQuery dataset, and the same method can write a JSON file. Setup is a short sequence: create or choose a project for the data and enable billing on it, configure permissions, enable the BigQuery Data Transfer Service application programming interface (API) if you want pricing data, create the dataset, then enable the export. Two setup details are tested. The project holding the dataset should be linked to the same Cloud Billing account whose data you are exporting, and Google recommends a separate project for all your billing administration. Permissions are split again: Billing Account Costs Manager or Billing Account Administrator on the billing account, and BigQuery User on the project. Then timing, which is why Google recommends enabling export at the same time you create the account. In a multi-region dataset, billing data is added retroactively for the current and previous month. In a single-region dataset it is not added retroactively at all. And pricing data is never added retroactively. Storing and querying the export also incurs BigQuery charges of its own.

Four exports, four different questions

Pick the export by the question you need to answer

Worked example (synthetic). A platform team must charge back costs to the individual virtual machines each team runs. The standard export stops at project and service; the detailed export carries resource-level cost.

There is more than one export, and a question will name a need and ask which. The standard usage cost export carries account, invoice date, services, stock keeping units (SKUs), projects, labels, cost, usage and credits — enough to answer what each project and service cost. The detailed export includes everything in the standard export plus resource-level cost data, such as a virtual machine or a disk that generated usage. The pricing export carries the account's own pricing information by stock keeping unit, with units and tiers. And the FinOps Open Cost and Usage Specification (FOCUS) export is an immutable dataset of detailed usage cost normalized to that open standard, which is what you want when billing data from several providers has to line up.

When exported data begins

The dataset's location decides whether the past arrives

Figure: A decision flow after enabling billing export. Cost data in a multi-region dataset is back-filled for the current and previous month. Cost data in a single-region dataset, and pricing data in any dataset, start from the day export was enabled. In every case older data is never exported.

Worked example (synthetic). An auditor asks for eight months of detailed cost history from a billing account whose export was switched on last week. No setting recovers it; the lesson is to enable export with the account.

The timing rules are worth drawing because they are a decision, not a list. For cost data in a multi-region dataset, Google adds billing data retroactively for the current and previous month. For cost data in a single-region dataset, it is not added retroactively, so you won't see data from before you enable export. Pricing data is never added retroactively, whatever the dataset. In every branch there is a floor, and nothing older than it ever arrives. That is the reasoning behind Google's recommendation to enable the export at the same time you create the Cloud Billing account: it is the only moment at which the export can be complete.

What this topic actually tests

Four tasks, four traps

Create: one currency per account, Billing Account Creator on the organization, close but never delete. Link: exactly one account per project, a role on EACH side, a closed account switches billing off. Budget: thresholds on actual or forecast, alerts never cap, Pub/Sub if something must happen. Export: BigQuery, same billing account, turn it on early — only multi-region cost data back-fills.

Close on the trap inside each task. Creating: an account runs in one currency fixed by its country, creating one in an organization needs Billing Account Creator on the organization node, and accounts can be closed but never deleted. Linking: a project has exactly one billing account at a time, linking needs a role on each side — Billing Account User on the account, Project Billing Manager or Owner on the project — and linking to a closed account switches billing off. Budgets: thresholds fire on actual or forecasted cost, the default recipients are the billing administrators and users, and an alerts-only budget never caps spending; if something must happen, connect Pub/Sub. Exports: BigQuery, a project on the same billing account, and enable it early, because only multi-region cost data back-fills and pricing data never does.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 1
• Create, edit, or delete budgets and budget alerts
• Manage your Cloud Billing account
• Create a new self-serve Cloud Billing account
• Overview of Cloud Billing access control
• Set up Cloud Billing data export to BigQuery
• Verify the billing status of your projects
• Enable, disable, or change billing for a project
• Export Cloud Billing data to BigQuery
• Cloud Billing concepts
• gcloud billing accounts list
• gcloud billing projects link
• Set up programmatic notifications
• gcloud billing budgets create

Unit 2 roadmap — Planning and configuring a cloud solution

Every objective below is quoted from Google's Associate Cloud Engineer exam guide, retrieved 2026-09-22. Under each topic is that topic's own summary of what the exam actually tests, taken from its lecture.

Topic 1 — Planning and configuring compute resources

ACE-U2.T1 · 2 objectives · lecture deck of 11 slides

1. Selecting appropriate compute choices for a given workload (e.g., Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions)
2. Using Spot VM instances and custom machine types as appropriate

What this topic actually tests. Stateless or stateful? Cloud Run, or GKE. Autopilot or Standard? Autopilot unless the workload needs node-level control. Can it be interrupted? Then Spot, with a termination action. Does any predefined shape fit? If not, a custom type — in the N or E series.

Topic 2 — Planning and configuring data storage options

ACE-U2.T2 · 2 objectives · lecture deck of 10 slides

1. Product choice (e.g., Cloud SQL, BigQuery, Firestore, Spanner, Bigtable)
2. Choosing storage options (e.g., zonal Persistent Disk, regional Persistent Disk, Standard, Nearline, Coldline, Archive)

What this topic actually tests. Analysis or application? BigQuery, or one of the four others. Relational at what scale? Spanner globally, Cloud SQL otherwise. Survive a zone? a regional disk replicates to two zones. How often is it read? that picks the class — and a new default class leaves existing objects where they are.

Topic 3 — Planning and configuring network resources

ACE-U2.T3 · 3 objectives · lecture deck of 12 slides

1. Load balancing
2. Availability of resource locations in a network
3. Network Service Tiers

What this topic actually tests. What traffic, from where, to how many regions? — that names the load balancer, and global is external only. What scope is each resource? — a zonal disk needs its VM's zone, a regional IP its VM's region. Which tier, set where? — Premium for performance, Standard for cost; the resource's tier beats the project default, and global external load balancers need Premium.

Planning and configuring compute resources

Study guide for Associate Cloud Engineer, Unit 2 · Topic 1. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Planning and configuring compute resources. Considerations include:

1. Selecting appropriate compute choices for a given workload (e.g., Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions)
2. Using Spot VM instances and custom machine types as appropriate

Planning and configuring compute resources

Where the workload runs, and what it runs on

Which platform? Compute Engine, Google Kubernetes Engine, Cloud Run or Cloud Run functions — read from what the workload needs. Which machine? A Spot VM when interruption is acceptable, a custom machine type when no predefined shape fits.

This is the Associate Cloud Engineer's first planning topic, and the guide frames it as considerations rather than products. It has two objectives. The first is selecting the right compute choice for a given workload — Compute Engine, Google Kubernetes Engine, Cloud Run or Cloud Functions. The second is using Spot virtual machine (VM) instances and custom machine types as appropriate. The Cloud Digital Leader exam asked what each platform is worth to a business; this exam asks the engineer's question, which is what the workload requires and what that rules out. So every slide here ends in a decision, and where the decision is carried by a command-line flag, you will see the exact flag Google documents.

Four platforms, one question: what does the workload need?

From self-managed machines to code that only runs on an event

• Compute Engine: self-managed VMs and bare metal instances
• GKE: containers on Kubernetes clusters you configure and operate
• Cloud Run: containers run directly on Google Cloud infrastructure
• Cloud Run functions: code bound to an event or an HTTPS endpoint

Worked example (synthetic). A retailer has four workloads: a licensed ERP package, a stateful recommendation engine, a stateless storefront API, and a thumbnail resizer that fires on each upload. That is four answers — Compute Engine, GKE, Cloud Run, Cloud Run functions — not one.

The guide names four compute choices, and the fastest way to separate them is by what you have to manage. At one end is Compute Engine, which Google calls an infrastructure as a service product that offers self-managed virtual machine instances and bare metal instances, with operating systems for both Linux and Windows. You choose and run the operating system. In the middle are the two container platforms. Google puts it in one sentence: it offers two major platforms for running containerized applications — Google Kubernetes Engine, or GKE, for running containers on Kubernetes clusters, and Cloud Run for running containers directly on Google Cloud infrastructure. On GKE you still manage the Kubernetes clusters — node configuration, networking, scaling and upgrades. On Cloud Run, all you provide is source code or a container image. At the far end are functions. The guide says Cloud Functions, but that product has been renamed Cloud Run functions, and that is the name you will see in the console today. A function is code bound to an event — Google's examples include responding to Cloud Storage events when a file is created, changed or removed.

What each platform is best suited for

Read the workload's shape, then the column

Worked example (synthetic). An inventory service must keep data on an attached volume between restarts. "Stateful" moves it out of the Cloud Run column and into GKE's.

Google's own comparison supplies the middle two rows almost word for word. Google Kubernetes Engine supports both stateless and stateful applications and is ideal for complex applications with specific resource needs; Google adds that it is best suited for complex microservices architectures, stateful applications, workloads requiring custom infrastructure or network configurations, and scenarios where deep control over Kubernetes is essential. Cloud Run is best suited for stateless, request or event-driven services, web services and functions. The word that most often decides an exam item is the one in bold: stateless or stateful. Functions sit at the end because they are the narrowest shape — Google describes the automatic provisioning of an HTTPS endpoint as making functions a perfect candidate for webhooks. And Compute Engine sits at the start because it is the answer when the workload needs the machine itself: a self-managed virtual machine, its operating system, or a bare metal instance.

Google's test for a Cloud Run service

Meet every criterion, or look at GKE

Figure. Three criteria for a Cloud Run service: how it is invoked (requests, streams or events, or running to completion), where it keeps files (no local persistent file system), and how many copies (built for multiple simultaneous instances). A band beneath says an app meeting all three fits Cloud Run, and one missing any should look at GKE.

Worked example (synthetic). A legacy app writes its session state to local disk and assumes it is the only copy running. It fails two of the three criteria, so the planning answer is GKE, not Cloud Run.

Google publishes an explicit test for Cloud Run, and it is worth memorising as three questions, because the exam writes scenarios that fail exactly one of them. Google's wording is that to be a good fit as a Cloud Run service, your app needs to meet all of the following criteria. First, it serves requests, streams or events delivered using HTTP, HTTP/2, WebSockets or gRPC — or it executes to completion. Second, it does not require a local persistent file system, only a local ephemeral file system or a network file system. Third, it is built to handle multiple instances of the app running simultaneously. The page also sets a per-instance resource ceiling, which changes over time and is not shown here. If an app meets the criteria and runs to completion rather than serving, that is a Cloud Run job — Google says jobs are well-suited to code that performs work and quits when the work is done. And if an app does not meet all of the criteria, Google's own advice is to check out Google Kubernetes Engine as a hosting option.

The selection, as a sequence of questions

Stop at the first answer that fits

Figure: A decision flow. If the workload is code that runs when an event arrives, choose Cloud Run functions. Otherwise, if it is a container meeting all Cloud Run criteria, choose Cloud Run, as a service or as a job if it runs to completion. Otherwise, if it needs Kubernetes, stateful storage or custom network configuration, choose GKE, in Autopilot mode unless it needs Standard. Otherwise choose Compute Engine with a self-managed VM.

Worked example (synthetic). A nightly report generator is containerized and exits when done. It stops at the second question: a Cloud Run job.

Drawn as a sequence, the selection becomes a short walk from the most managed option to the least, and you stop at the first one that fits. Is it code that should run when an event arrives, such as a file landing in Cloud Storage? Then it is Cloud Run functions. If not, is it a container that meets all of the Cloud Run criteria? Then it is Cloud Run — a service if it serves requests, a job if it runs to completion. If not, does it need Kubernetes, stateful storage, or custom infrastructure or network configuration? Those are the cases Google names for Google Kubernetes Engine. And if the workload needs the machine itself — a self-managed virtual machine and its operating system — it is Compute Engine. The order matters because moving between the two container platforms is cheap: Google notes you can use the same image in either platform without any modifications, so starting on Cloud Run is not a trap if the workload later outgrows it.

Choosing GKE is two decisions: Autopilot or Standard

Google's default is Autopilot

Worked example (synthetic). A team needs a privileged container to load a kernel module on each node. That is outside Autopilot's constraints, so this workload goes on a Standard cluster.

Once Google Kubernetes Engine is the answer, the exam asks a second question: which mode of operation. Google marks Autopilot as recommended — a managed experience in which GKE handles most of your infrastructure for you so that you can focus on your applications. Standard mode hands that work back to you: you must plan the capacity of nodes in Standard node pools based on your workload requirements, and you manage resource allocation and the placement of Pods on specific nodes. Google's stated best practice decides most items: use Autopilot for most workloads, unless your application requires privileges or configuration options that don't meet the Autopilot constraints. So the exam signal for Standard is a requirement for control over nodes — privileged workloads, specific node configuration — and without that signal, Autopilot is the planning answer.

Spot VMs: cheaper capacity that can be taken back

For workloads that can be interrupted — and only those

• Fault-tolerant workloads: Spot can reduce Compute Engine costs significantly
• Compute Engine can preempt them at any time to reclaim capacity
• No live migration, no automatic restart, and no SLA
• Create with --provisioning-model=SPOT; Spot replaces preemptible VMs

Worked example (synthetic). A genomics lab runs thousands of independent alignment tasks overnight. A preempted VM only slows the run, so Spot fits. Its public results portal, which customers expect to be up, stays on standard VMs.

The second objective starts with Spot virtual machine instances. The trade is stated plainly by Google: if your workloads are fault-tolerant and can withstand possible VM preemption, Spot VMs can reduce your Compute Engine costs significantly — and batch processing jobs are Google's example. The price of that saving is that Compute Engine can preempt a Spot VM at any time. Google lists what else you give up: Spot VMs can't live migrate to become standard VMs while running, and can't be set to automatically restart on a host event, and because of those limitations they are not covered by any service level agreement, or SLA, and are excluded from the Compute Engine SLA. They are also finite capacity, so they might not always be available. Configuration is one flag: to create Spot VMs, you must include the provisioning model flag set to SPOT. And if the exam says preemptible, treat it as the older name — Google says Spot VMs are the latest version of preemptible VMs, and recommends Spot instead. The difference you may be tested on is runtime: preemptible VMs can only run for up to twenty-four hours at a time, and Spot VMs have no maximum unless you set one.

What happens when a Spot VM is preempted

The termination action decides the end state

Figure: A flow: Compute Engine preempts the Spot VM, a best-effort shutdown period of up to 30 seconds follows, and the instance termination action decides the end state. With STOP or no action set the VM is stopped and its state is TERMINATED; with DELETE the VM is deleted.

Worked example (synthetic). A batch worker writes its checkpoint in a shutdown script, and the fleet uses DELETE so preempted workers do not pile up as stopped VMs.

What happens at preemption is a common exam item, and it turns on one setting. At preemption time, Google says, Compute Engine either stops — the default — or deletes your Spot virtual machines (VMs), depending on the termination action you specify for each one. You set it at creation: Google says you can optionally specify a termination action by including the instance termination action flag. Before either happens there is a shutdown period, and Google warns that for Spot VMs it is best effort and up to thirty seconds, shorter than for other instances — so a shutdown script must be quick. Then the end state follows from the action: if it is STOP or not specified, Compute Engine stops the VM, transitioning it to a TERMINATED state; if it is DELETE, Compute Engine deletes the VM. The planning question is what you want left behind: a stopped VM you can start again, or nothing.

Custom machine types: when no predefined shape fits

Choose the vCPU count and memory yourself

• Predefined machine types have a preset vCPU count and memory
• Custom: for workloads that fit no predefined type, or need a bit more
• Match vCPUs to per-CPU software licenses
• gcloud: --custom-cpu, --custom-memory, --custom-vm-type, --custom-extensions

Worked example (synthetic). A database licensed per CPU needs 6 vCPUs and more memory than the matching predefined type offers. A custom N2 machine type with extended memory matches the license and the workload without paying for the next size up.

The other half of the second objective is custom machine types. Google's baseline is that a predefined machine type has a preset number of virtual CPUs and amount of memory. When none fits, Compute Engine lets you create a custom machine type with customized CPU and memory resources for some of the machine series. Google names three scenarios where custom machine types are ideal: workloads that aren't a good fit for the predefined types; workloads that require more processing power or more memory but don't need all the upgrades of the next level machine type; and workloads with per-CPU software license costs, where you customize the number of virtual CPUs to avoid license costs for unused processing power or to match available license counts. Two constraints matter for planning. Custom types are available only for some families — in the general-purpose family, only the N and E machine series. And if a workload needs more memory per CPU than the default range, extended memory is available on some custom types, such as N2 and N4. On the command line, alongside naming the custom type in the machine type, Google documents the custom options: custom CPU (central processing unit), custom memory, custom virtual machine (VM) type, and custom extensions.

Where a custom type sits among the machine families

Family, then series, then type — custom only in some series

Worked example (synthetic). A team wants a custom shape on a compute-optimized machine for a simulation. The family does not offer one, so the choice is the nearest predefined compute-optimized type — or a custom N-series type if the workload does not need compute-optimized performance.

Custom machine types only make sense inside Compute Engine's naming structure. Google organizes machines into families, and each machine family is further organized into machine series and predefined machine types within each series — for example, within the N2 series in the general-purpose family, you can select the n2-standard-4 machine type. The families describe what the hardware is for. General-purpose gives the best price-performance ratio for a variety of workloads. Compute-optimized is designed for high performance computing solutions and compute-intensive workloads. Memory-optimized is ideal for memory-intensive workloads, offering more memory per core than other machine families. Accelerator-optimized is ideal for massively parallel workloads such as machine learning. Custom types sit in only a corner of that grid: the general-purpose N and E series, and the G2 series in the accelerator-optimized family. So a scenario that asks for a custom shape on another family has a trap in it — the answer is either the nearest predefined type in that family, or a custom general-purpose type if the workload does not really need the specialised hardware.

What this topic actually tests

Four decisions, two objectives

Stateless or stateful? Cloud Run, or GKE. Autopilot or Standard? Autopilot unless the workload needs node-level control. Can it be interrupted? Then Spot, with a termination action. Does any predefined shape fit? If not, a custom type — in the N or E series.

Close on the four decisions the exam turns into scenarios. First, stateless or stateful: a stateless, request-driven container that meets all the Cloud Run criteria belongs on Cloud Run, and a stateful or deeply customised one belongs on Google Kubernetes Engine. Second, once on GKE, Autopilot or Standard: Google's best practice is Autopilot for most workloads, unless the application needs privileges or configuration Autopilot does not allow. Third, can the workload be interrupted: if it is fault-tolerant, Spot virtual machines (VMs) cut the cost significantly, created with the SPOT provisioning model, and the termination action decides whether a preempted VM is stopped or deleted — but never for something that needs a service level agreement (SLA). Fourth, does any predefined machine type fit: if not, a custom machine type, remembering that in the general-purpose family only the N and E series offer one. The next topic plans storage the same way.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 2
• Compute Engine overview
• GKE and Cloud Run
• Deploy functions to Cloud Run
• Spot VMs — Compute Engine
• Create and use Spot VMs
• Preemptible VM instances — Compute Engine
• Is my app a good fit for Cloud Run?
• What is Cloud Run
• Choose a GKE mode of operation
• Create a VM with a custom machine type
• Machine families resource and comparison guide

Planning and configuring data storage options

Study guide for Associate Cloud Engineer, Unit 2 · Topic 2. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Planning and configuring data storage options. Considerations include:

1. Product choice (e.g., Cloud SQL, BigQuery, Firestore, Spanner, Bigtable)
2. Choosing storage options (e.g., zonal Persistent Disk, regional Persistent Disk, Standard, Nearline, Coldline, Archive)

Planning and configuring data storage options

Two build-time choices: which product, and which storage option

Which product holds the data — Cloud SQL, Spanner, Firestore, Bigtable or BigQuery, read from the shape of the data and how it is used. Which storage option holds the bytes — a zonal or regional Persistent Disk under a virtual machine, or a Cloud Storage class chosen by how often the data is read.

The Associate Cloud Engineer guide frames this topic as planning and configuring data storage options, and it lists only two considerations. The first is product choice, with five examples: Cloud SQL, BigQuery, Firestore, Spanner and Bigtable. The second is choosing storage options, with six examples: zonal Persistent Disk, regional Persistent Disk, and the four Cloud Storage classes Standard, Nearline, Coldline and Archive. The Cloud Digital Leader exam asks what these products are for; this exam asks you to provision the right one. So the deck teaches the signals in a scenario that pick a product, then the flags and defaults that decide what you actually get when you create a disk or a bucket.

Five products, five shapes of data

Read the data's shape and its use before you pick the product

Worked example (synthetic). An engineer is handed three requests in one week: move a PostgreSQL order system, store readings from a fleet of meters, and let analysts query five years of sales. That is Cloud SQL, Bigtable and BigQuery — three products, because three shapes of data.

Start with what each product is, because the exam gives you a scenario and expects you to hear the product in it. Cloud SQL is a fully managed relational database service for MySQL, PostgreSQL and SQL Server — it handles backups, high availability and failover, and maintenance and updates for you — and Google's advice is to use it if you want to spend less time managing your database and more time using it. Spanner is also relational, but it brings together relational, graph, key-value and search, and it offers transactional consistency at global scale with automatic, synchronous replication. Firestore is a fully managed document database that does not require any pre-provisioning of resources and auto scales to match your load. Bigtable is ideal for storing large amounts of single-keyed data with low latency, with high read and write throughput. And BigQuery combines a cloud-based data warehouse and powerful analytic tools, storing data in a columnar format optimized for analytical queries. Two of these are relational, two are not, and one is for analysis rather than for running an application.

Choosing the product: three questions

Analysis or application, relational or not, then scale and shape

Figure: A decision tree. If the job is analysing large datasets rather than serving an application, choose BigQuery. Otherwise, for relational data choose Spanner when it must be consistent across regions at global scale and Cloud SQL when it need not. For non-relational data choose Firestore for documents behind a web or mobile app, and Bigtable for single-keyed, high-throughput data.

Worked example (synthetic). A retailer's PostgreSQL inventory app serves one country and must keep its standby ready if a zone fails. Relational, not global: Cloud SQL, with its high availability option.

Here is the choice as three questions, asked in this order because each one removes products. First: is the job analysing large datasets rather than serving an application? If so, the answer is BigQuery, whose columnar storage is optimized for analytical queries. Second: is the data relational? If it is, the third question splits the two relational products — must it stay consistent across regions at global scale? Spanner offers exactly that; Cloud SQL is the managed relational database for when it need not, and its high availability option provides a standby virtual machine in another zone. If the data is not relational, ask what shape it has. Documents behind a web or mobile app point to Firestore, which also supports, but does not require, the Firebase platform. Large amounts of single-keyed data needing high throughput and low latency — time series, meter readings — point to Bigtable.

The three pairs the exam swaps

Similar names or similar data — different products

Figure. Three cards contrasting the product pairs candidates confuse: Bigtable against BigQuery, Cloud SQL against Spanner, and Bigtable against Firestore, each with the deciding difference.

Worked example (synthetic). A team proposes Bigtable for an app's user profiles because they are "big". The profiles are structured documents needing transactions — Google's Bigtable page itself points to Firestore.

Three pairs account for most wrong answers in this objective. Bigtable and BigQuery share half a name and nothing else: Bigtable serves large amounts of single-keyed data at low latency to an application, while BigQuery combines a data warehouse with analytic tools. Cloud SQL and Spanner are both relational; the difference is scale and consistency, because Spanner offers transactional consistency at global scale with automatic, synchronous replication, while Cloud SQL is the fully managed service for MySQL, PostgreSQL and SQL Server. And Bigtable against Firestore is settled by Google on the Bigtable page itself: if you must store highly structured objects in a document database, with support for ACID transactions and SQL-like queries, consider Firestore.

Choosing a storage option

Block storage under a VM, or object storage in a bucket

• Durable block storage survives the VM stopping, being deleted or failing
• Zonal disk: one zone. Regional disk: replicated across two zones
• Google now recommends Hyperdisk where the machine series supports it
• Cloud Storage class: chosen by how often the data will be read

Worked example (synthetic). A database VM's data disk must survive a zone outage, and nightly exports must be kept for audits nobody expects to run. A regional Persistent Disk for the first; Archive storage for the second.

The second objective lists two families of storage, and the first decision is which family. Block storage sits under a virtual machine, or VM. Google distinguishes durable block storage — for data you want to preserve after you stop, suspend or delete the VM, or even if it crashes — from temporary storage that is lost when the VM stops. Within durable storage, the guide names zonal and regional Persistent Disk: a disk created in only one zone is a zonal disk, and a disk replicated across two zones in the same region is a regional Persistent Disk. One thing has moved since the guide was written. Google now says Hyperdisk and Persistent Disk are the durable block storage offerings, that Persistent Disk is not available with the latest machine series, and that you should use Hyperdisk where your machine series supports it. The exam asks about Persistent Disk, so this deck teaches it — but in a real project, check the machine series first. The other family is Cloud Storage, where every object carries a storage class, a piece of metadata chosen by how often the data will be read.

Zonal against regional Persistent Disk

A regional disk writes to two zones, so a zone outage is survivable

Figure: One region containing two zones. In zone a, a virtual machine writes to a disk replica, which is synchronously replicated to a second replica in zone b. A zonal disk would have only the zone a replica.

Worked example (synthetic). Zone a has an outage. With a zonal disk the data waits for the zone; with a regional disk the replica in zone b can be accessed immediately.

This is the whole difference between the two disks the guide names. A zonal disk lives in one zone. A regional Persistent Disk keeps a replica in each of two zones in the same region, and Google says that if a primary zone becomes unavailable during an outage, the replica in the second zone can be accessed immediately. That is why regional disks are designed for workloads that need a lower recovery point objective and recovery time objective than restoring from snapshots. It has a cost, and Google names it: regional Persistent Disk is an option when write performance is less critical than data redundancy across multiple zones. And it has a limit worth remembering — disk replication only provides high availability of the disks. The virtual machine in the failed zone still has to come back somewhere else.

Creating the disk: types, defaults and flags

The console and gcloud do not default to the same disk type

Worked example (synthetic). An engineer scripts a disk with gcloud and omits the type flag, expecting what the console showed yesterday. The script creates a standard disk, not a balanced one.

Now the hands-on part. When you create a Persistent Disk you choose a type, and the names are what you type. Balanced Persistent Disk, written pd-balanced, offers performance suitable for most general-purpose applications. Solid-state drive Persistent Disk, pd-ssd, suits enterprise applications and high-performance databases needing lower latency. Standard Persistent Disk, pd-standard, suits large data processing workloads that primarily use sequential reads and writes. You create a zonal disk with the gcloud compute disks create command and a zone. For a regional disk the same command takes a region and a replica-zones flag naming the two zones where the replicas are located. The detail the exam likes is the default: if you create a disk in the Google Cloud console the default type is pd-balanced, but if you create it using the gcloud command-line tool or the Compute Engine interface for programs, the default is pd-standard. Leave the flag off in a script and you get the slower disk.

The four Cloud Storage classes

Colder class: cheaper to keep, dearer to read, longer to commit

Worked example (synthetic). Monthly analytics exports go to Nearline; quarterly compliance snapshots to Coldline; seven-year legal holds to Archive. Picking Archive for the monthly exports saves on storage and loses on every read.

The four classes are one ladder, and each step down trades the same three things. Standard storage is best for frequently accessed, hot data and for data stored only briefly, and it is what a bucket gets if you do not specify a default class. Nearline is ideal for data you read or modify on average once a month or less; Google calls it the better choice when slightly lower availability, a thirty-day minimum storage duration and costs for data access are acceptable trade-offs for lower at-rest storage costs. Coldline is for data read at most once a quarter, with a ninety-day minimum. Archive is for data you plan to access less than once a year, with higher costs for access and operations and a three-hundred-and-sixty-five-day minimum. One misconception to drop: colder does not mean slower to reach. Cloud Storage provides low latency access to data stored as Archive storage — there is no offline retrieval step.

Configuring the bucket: location, default class, and changing it

A new default class does not touch the objects already stored

Figure. Four cards: bucket location types (region, dual-region, multi-region) and that regions or dual-regions survive a zone loss; placing data near the VMs that use it; changing the default storage class with gcloud storage buckets update and the default-storage-class flag, which leaves existing objects unchanged; and changing existing objects by rewriting them or with a lifecycle SetStorageClass rule.

Worked example (synthetic). A team switches a bucket's default class to Coldline and expects last year's files to move. They do not: only new objects get Coldline until a lifecycle rule or a rewrite changes the old ones.

Two settings on the bucket itself finish the objective. The first is location. Cloud Storage offers a region, which is a specific geographic place such as Iowa; a dual-region, which is a specific pair of regions; and a multi-region, a large area containing two or more regions such as the United States. To withstand the risk of losing data within an individual zone, Google says to use regions or dual-regions — data stored in a region is redundant across multiple zones within it — and storing data in the same zone or region as the Compute Engine virtual machines that use it can provide better performance. The second is the default class, and it holds the trap this exam likes. You change it with the gcloud storage buckets update command and the default-storage-class flag. But changing the default storage class of a bucket does not affect any of the objects that already exist in the bucket. To move existing objects you either rewrite them or use Object Lifecycle Management, whose SetStorageClass action switches objects to another class — and when rules collide, the action that moves an object to the class with the lowest at-rest pricing takes precedence.

What this topic actually tests

Two choices, four discriminations

Analysis or application? BigQuery, or one of the four others. Relational at what scale? Spanner globally, Cloud SQL otherwise. Survive a zone? a regional disk replicates to two zones. How often is it read? that picks the class — and a new default class leaves existing objects where they are.

Close the topic on the four discriminations it tests. First, analysis or application: BigQuery is the warehouse for analytical queries, and the other four serve applications. Second, relational at what scale: Spanner offers transactional consistency at global scale, and Cloud SQL is the managed MySQL, PostgreSQL and SQL Server service when that is not needed; non-relational data goes to Firestore as documents or to Bigtable as single-keyed, high-throughput data. Third, must the disk survive a zone: a regional Persistent Disk replicates across two zones, a zonal disk does not — and remember the gcloud default disk type is pd-standard. Fourth, how often will the data be read: that picks Standard, Nearline, Coldline or Archive, and changing a bucket's default class does not move a single existing object.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 2
• Cloud SQL overview
• Spanner documentation
• Firestore overview
• Bigtable overview
• BigQuery overview
• Choose a disk type — Compute Engine
• About Persistent Disk — Compute Engine
• Storage classes — Cloud Storage
• Add a Persistent Disk to your VM — Compute Engine
• Create regional disks — Compute Engine
• Bucket locations — Cloud Storage
• Change the default storage class of a bucket — Cloud Storage
• Object Lifecycle Management — Cloud Storage

Planning and configuring network resources

Study guide for Associate Cloud Engineer, Unit 2 · Topic 3. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Planning and configuring network resources. Considerations include:

1. Load balancing
2. Availability of resource locations in a network
3. Network Service Tiers

Planning and configuring network resources

Three decisions: which load balancer, where things live, which tier

Load balancing — pick the type from the traffic, then external or internal, then global or regional. Resource locations — every resource is global, regional or zonal, and that scope decides what it can attach to. Network Service Tiers — Premium or Standard, set per project and overridable per resource.

The guide gives this topic three short considerations — load balancing, availability of resource locations in a network, and Network Service Tiers — and no more detail than that. For an Associate Cloud Engineer each of them is a decision you make while building something. For load balancing, the decision is which of Google's load balancer types fits the traffic, and then whether it faces the internet or stays internal, and whether its backends sit in one region or several. For resource locations, it is knowing that every Compute Engine resource is global, regional or zonal, because that scope decides what a resource can be attached to and what a single failure can take down. And for Network Service Tiers, it is choosing between Premium and Standard, knowing that a project has a default and a resource can override it. We take them in that order, and the last slide gives you the three questions to ask in a scenario.

Load balancing: what it does, and the three choices

Type from the traffic, then external or internal, then scope

• A load balancer spreads user traffic across instances of your application
• Layer 7 routes on request attributes; Layer 4 on network and transport data
• External: clients on the internet. Internal: clients inside Google Cloud
• Global: backends in several regions. Regional: backends in one

Worked example (synthetic). A retailer's storefront serves HTTPS to shoppers worldwide from backends in two regions. That is Layer 7, external and global — three answers, one load balancer type.

Start with what a load balancer is for. In Google's words, a load balancer distributes user traffic across multiple instances of your applications, and by spreading the load it reduces the risk that your applications experience performance issues. Cloud Load Balancing is a fully distributed, software-defined, managed service — not an instance or device you run — and for global load balancers a single anycast internet protocol, or IP, address is the frontend for all of your backend instances in regions around the world. Choosing one comes down to three questions. First, the layer. Layer 7 load balancing adds request routing decisions based on attributes such as the hypertext transfer protocol, or HTTP, header and the uniform resource identifier; Layer 4 directs traffic on network and transport data. Google's summary is that you choose an Application Load Balancer for HTTP or HTTPS traffic at Layer 7, and a Network Load Balancer at Layer 4 — the proxy kind for transport layer security, or TLS, offloading, the passthrough kind for protocols such as the user datagram protocol, or UDP. Second, external or internal: an external load balancer when clients reach the application from the internet, an internal one when the clients are inside Google Cloud. Third, scope: a global load balancer supports backends in multiple regions, a regional one supports backends in a single region — and even a regional load balancer is globally accessible, because its IP address sits in one region but can be reached from anywhere.

The three load balancer types

What each does to the connection, and when Google says to pick it

Worked example (synthetic). A multiplayer game server speaks UDP and bans cheaters by their source IP. Only one row keeps both: the passthrough Network Load Balancer.

Here are the three types side by side, and the column that separates them is the connection. Proxy load balancers terminate incoming client connections at the load balancer and then open new connections from the load balancer to the backends — every Application Load Balancer and every proxy Network Load Balancer works that way. Passthrough load balancers do not terminate client connections, so the backend sees the original packets. Google's selection guidance follows from that. Choose an Application Load Balancer when you need a flexible feature set for applications with hypertext transfer protocol (HTTP) or HTTPS traffic. Choose a proxy Network Load Balancer to implement transmission control protocol, or TCP, proxy load balancing to backends in one or more regions. And choose a passthrough Network Load Balancer to preserve client source internet protocol (IP) addresses, avoid the overhead of proxies, and support additional protocols like the user datagram protocol, encapsulating security payload and the internet control message protocol — UDP, ESP and ICMP. When a scenario mentions keeping the client's original address, or a protocol that is not TCP, the proxy types are already out.

Choosing a load balancer, as three questions

Global is only on offer when the load balancer is external

Figure: A decision flow. HTTP or HTTPS traffic leads to an Application Load Balancer; otherwise, needing the client source IP or UDP, ESP or ICMP leads to a passthrough Network Load Balancer, and the rest to a proxy Network Load Balancer. For the proxy types, internet clients with backends in many regions lead to a global external load balancer, internal clients with backends in many regions to a cross-region internal load balancer, and backends in one region or a requirement to keep TLS in one region to a regional load balancer.

Worked example (synthetic). An internal reporting service has clients inside the company's network and backends in two regions. The flow ends at cross-region internal — not global, which is external only.

Drawn as a flow, the choice has a trap in the last step. The first two questions pick the type: hypertext transfer protocol (HTTP) or HTTPS traffic means an Application Load Balancer; otherwise, needing the client's source address or a protocol like user datagram protocol (UDP) means passthrough, and anything else is a proxy Network Load Balancer. The third question is scope, and here Google's wording matters: only external load balancers are available as global load balancers. For internal load balancers with backends in multiple regions, you choose the cross-region load balancer instead. And you choose a regional load balancer when you need backends in one region only, when you require only IPv4 termination, or when you have jurisdictional compliance requirements for traffic to stay in a particular region. That last reason deserves a second look: global load balancers terminate transport layer security, or TLS, in locations distributed around the world to minimize latency, so a rule that TLS must end inside one region rules the global options out. One more thing the flow cannot show: the resilience of the whole application depends not only on the load balancer's scope but also on the redundancy of the backend services behind it.

Availability of resource locations in a network

Global, regional or zonal: scope decides what a resource can reach

• Global: VPC networks with their routes and firewall rules; images
• Regional: subnets and regional static external IP addresses
• Zonal: VM instances and zonal persistent disks
• Spread across zones, and regions, for failure independence

Worked example (synthetic). An engineer creates a VM in us-central1-a and a zonal disk in us-central1-b, then cannot attach the disk. Nothing is broken; zonal resources only attach within one zone.

The second consideration is where resources can live and what that means for what can reach them. Regions are independent geographic areas that consist of zones, and a zone's name carries its region — the fully qualified name for zone a in region us-central1 is us-central1-a. Google's rule is that all Compute Engine resources are either global, regional or zonal in scope. Images are global; regional static internet protocol (IP) addresses are regional; persistent disks can be either regional or zonal. Scope decides access. Regional resources are accessible only to resources within the same region, and zonal resources only within the same zone — so to attach a zonal persistent disk to an instance, both must be in the same zone, and to assign a static IP address to an instance, the instance must be in the same region as the address. The network itself follows the same pattern: virtual private cloud, or VPC, networks — with their associated routes and firewall rules — are global resources, while subnets are regional, so an instance can use any subnet in the region that contains its zone. Scope is also your availability tool. Putting resources in different zones reduces the risk of one infrastructure outage affecting them all, and different regions give an even higher degree of failure independence — which is why Google recommends deploying fault-tolerant applications across multiple zones and multiple regions.

Scope, resource by resource

What each scope lets a resource reach

Worked example (synthetic). A team reserves a regional static IP in europe-west1 for a VM it then creates in us-east1. The assignment fails — the address is regional, so the VM must be in its region.

This table is the one to have memorized before the exam, because scenario items test it by describing an attachment that fails. At the top are the global resources: virtual private cloud networks, including their associated routes and firewall rules, are global; images are global, so instances in different zones can use the same image; and global static external internet protocol (IP) addresses are a global resource used for global load balancers. In the middle are regional resources: subnets, and regional static external IP addresses, which are accessible only to resources within the same region. At the bottom are zonal resources — the instance itself and a zonal persistent disk — accessible only within the same zone. Read any 'why did this fail' question against the table: a disk and an instance in different zones, or an address and an instance in different regions, is the whole answer.

Zonal, regional and global, in one picture

The disk shares its VM's zone; the global front end is in no region

Figure. Users reach a global external Application Load Balancer, drawn outside any region, through one anycast IP address. It sends traffic to backend VMs in three zones of region us-central1; each zone holds a VM and its zonal disk, while the subnet and static external IP address are regional. The callout notes that a disk must share its VM's zone and that the load balancer belongs to no region.

Worked example (synthetic). An architect adds a second zone of VMs behind the load balancer so one zone's outage does not stop the service. That changes nothing about the front end, which was never in a zone.

Now the three scopes in one picture. Inside the region are three zones, and inside each zone a backend virtual machine, or VM, with its zonal disk — zonal resources that can only be used by other resources in the same zone. The region box holds what is regional: the subnet, which any instance in the region's zones can use, and a regional static external internet protocol (IP) address. Outside the region, on the left, is the global external Application Load Balancer. With Cloud Load Balancing, a single anycast IP address is the frontend for backend instances in regions around the world, so the front end belongs to no zone and no region. The picture explains the availability advice too. Putting backends in different zones reduces the risk that one infrastructure outage affects them all at once, and the load balancer can keep sending users to whichever backends remain healthy.

Auto mode and custom mode VPC networks

Who decides which regions have a subnet

Figure. Two cards. Auto mode: one subnet per region is created automatically, and new projects start with a default auto mode network. Custom mode: no subnets are created automatically, so you add them in the regions you use. A band beneath notes that in both modes the network is global and each subnet is regional.

Worked example (synthetic). An engineer creates a custom mode network, then tries to create a VM in asia-east1 and finds no subnet to attach it to. Custom mode created none; one must be added in that region first.

The last piece of resource location is how a network gets its subnets, and Google offers two modes. When an auto mode VPC network is created, one subnet from each region is automatically created within it — and unless an organizational policy prohibits it, new projects start with exactly such a default network, with one subnet in each region. When a custom mode VPC network is created, no subnets are automatically created; you add a subnet in each region you intend to use. In both modes the geometry is the same: the virtual private cloud, or VPC, network is global and each subnet is regional. So the practical consequence of custom mode is the one the worked example shows — a virtual machine (VM) cannot be placed in a region until you have given that region a subnet.

Network Service Tiers

Premium optimizes for performance; Standard optimizes for cost

• Premium: traffic on Google's premium backbone
• Standard: traffic over regular ISP networks, a low-cost alternative
• The tier affects the path internet traffic takes to reach a resource
• Global external load balancers are Premium Tier only

Worked example (synthetic). A batch-download service with no latency target serves files from one region. Standard Tier fits; a global external Application Load Balancer in front of it would not be allowed in Standard.

The third consideration is Network Service Tiers, and Google states the trade in two sentences: Premium Tier delivers traffic on Google's premium backbone, while Standard Tier uses regular internet service provider, or ISP, networks; use Premium Tier to optimize for performance, and Standard Tier to optimize for cost. The load balancing guidance says the same thing as a rule of thumb — choose Premium for high performance and low latency, and Standard as a low-cost alternative for applications without strict latency or performance requirements. Be precise about what the tier changes. For a regional external internet protocol (IP) address, the tier only affects the path that traffic from the internet takes to reach the resource; traffic between virtual machine instances, in the same or different regions, stays on Google's network whichever tier you use. Standard Tier is available to resources that use regional external IP addresses in every region. The catch for load balancing is that some services are only available in Premium Tier — in particular, the global external Application Load Balancer and the global external proxy Network Load Balancer can only be configured in Premium.

Premium against Standard

Same resources, a different road in from the internet

Worked example (synthetic). A candidate says Standard Tier makes VM-to-VM traffic between regions cross the public internet. The last row says otherwise — the tier governs the internet-facing path only.

Side by side, the difference is narrower than candidates expect. The tiers differ on the path from the internet — Google's premium backbone against regular internet service provider networks — and so on what they optimize: performance and low latency for Premium, cost for Standard. They differ on the global external load balancers, which exist only in Premium Tier. Both offer regional external internet protocol (IP) addresses; Standard Tier is available for them in all regions. And they do not differ at all on traffic between virtual machine instances, which Google designs to stay on its own network in the same or different regions whichever tier you use. When an exam item claims Standard Tier changes internal traffic, the last row is the answer.

Setting the tier: project default, resource override

The resource's own tier always wins

Figure. Three stacked cards. The project default applies to new eligible resources that name no tier, defaults to Premium, and is set with gcloud compute project-info update and the default-network-tier flag. A tier set on a resource, such as with gcloud compute addresses create and the network-tier flag, always takes precedence. Changing the project default later leaves existing resources on their tier.

Worked example (synthetic). A project's default is switched to Standard on Monday. Friday's existing external IPs stay Premium; a new address created with no tier on Tuesday is Standard; one created with the network-tier flag set to PREMIUM is Premium.

The hands-on part of the tiers is where the setting lives. A project has a default network tier, and this tier is used by newly created eligible resources in the project unless you specify a tier for the resources themselves. You set it with the command on the first card, gcloud compute project-info update with the default network tier flag, replacing the placeholder with PREMIUM or STANDARD — and if you never set it, the default is PREMIUM. The second card is the override: the network tier you specify for a resource always takes precedence over the project default, as when you create a regional address with the network tier flag set to STANDARD. The third card is the one exam items like to test. Changing the default network tier for a project does not change the tier of any existing resource; it only changes the tier of new resources created without one.

What this topic actually tests

Three questions to ask of any network scenario

What traffic, from where, to how many regions? — that names the load balancer, and global is external only. What scope is each resource? — a zonal disk needs its VM's zone, a regional IP its VM's region. Which tier, set where? — Premium for performance, Standard for cost; the resource's tier beats the project default, and global external load balancers need Premium.

Close on three questions to ask of any networking scenario. First: what traffic, from where, to how many regions? hypertext transfer protocol (HTTP) or HTTPS means an Application Load Balancer, a need for the client's source address or a protocol like user datagram protocol (UDP) means passthrough, and remember that only external load balancers can be global — internal traffic to several regions needs the cross-region load balancer. Second: what is the scope of each resource? A zonal disk attaches only to an instance in its zone, a regional static internet protocol (IP) only to an instance in its region, and the virtual private cloud network with its firewall rules is global. Third: which tier, and set where? Premium Tier for performance, Standard for cost; a tier set on a resource always beats the project default, changing the default leaves existing resources alone, and the global external load balancers exist only in Premium. The next topics in Unit 3 deploy these same resources, so every one of these rules comes back as a command.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 2
• Global, regional, and zonal resources — Compute Engine
• Cloud Load Balancing overview
• Regions and zones — Compute Engine
• VPC networks
• Network Service Tiers overview
• Choose a load balancer
• Configure network tiers

Unit 3 roadmap — Deploying and implementing a cloud solution

Every objective below is quoted from Google's Associate Cloud Engineer exam guide, retrieved 2026-09-22. Under each topic is that topic's own summary of what the exam actually tests, taken from its lecture.

Topic 1 — Deploying and implementing Compute Engine resources

ACE-U3.T1 · 4 objectives · lecture deck of 15 slides

1. Launching a compute instance (e.g., assign disks, availability policy, SSH keys)
2. Creating an autoscaled managed instance group by using an instance template
3. Configuring OS Login
4. Configuring VM Manager

What this topic actually tests. Disks: attach, then format and mount. Availability: the host maintenance policy — live migrate by default. MIGs: templates can't be edited; disks are recreated with their VM. OS Login: metadata keys stop working; sudo needs osAdminLogin. VM Manager: API, agent and metadata — the org policy only reaches new VMs.

Topic 2 — Deploying and implementing Google Kubernetes Engine resources

ACE-U3.T2 · 3 objectives · lecture deck of 12 slides

1. Installing and configuring the command line interface (CLI) for Kubernetes (kubectl)
2. Deploying a Google Kubernetes Engine cluster with different configurations (e.g., Autopilot, regional clusters, private clusters, GKE Enterprise)
3. Deploying a containerized application to Google Kubernetes Engine

What this topic actually tests. Does this machine's kubeconfig know the cluster? if not, get-credentials. Can the setting change later? zonal and regional cannot. Who can reach the app? ClusterIP by default — --type LoadBalancer for the internet.

Topic 3 — Deploying and implementing Cloud Run and Cloud Functions resources

ACE-U3.T3 · 3 objectives · lecture deck of 12 slides

1. Deploying an application
2. Deploying an application for receiving Google Cloud events (e.g., Pub/Sub events, Cloud Storage object change notification events, Eventarc)
3. Determining where to deploy an application by using Cloud Run (fully managed), Cloud Run for Anthos, or Cloud Functions

What this topic actually tests. Image or source? --image if you built it, --source if you want Cloud Build to. Deploy or serve? Revisions are created on every change; traffic moves only when you say so. Which identity? The deployer, the service, the trigger — each a separate service account. Which name? Cloud Run for Anthos is Knative serving; Cloud Functions is Cloud Run functions.

Topic 4 — Deploying and implementing data solutions

ACE-U3.T4 · 2 objectives · lecture deck of 10 slides

1. Deploying data products (e.g., Cloud SQL, Firestore, BigQuery, Spanner, Pub/Sub, Dataflow, Cloud Storage, AlloyDB)
2. Loading data (e.g., command line upload, load data from Cloud Storage, Storage Transfer Service)

What this topic actually tests. What is fixed at creation? a dataset's location, a Spanner configuration's edition requirement, a bucket's hierarchical namespace. What must exist first? a subscription before a Dataflow job reads it; an AlloyDB cluster before its primary. Whose permission, and which location? you upload; the Cloud SQL instance's service account imports; the bucket and dataset share a location.

Topic 5 — Deploying and implementing networking resources

ACE-U3.T5 · 3 objectives · lecture deck of 14 slides

1. Creating a VPC with subnets (e.g., custom mode VPC, Shared VPC)
2. Creating ingress and egress firewall rules and policies (e.g., IP subnets, network tags, service accounts)
3. Peering external networks (e.g., Cloud VPN, VPC Network Peering)

What this topic actually tests. Is there a subnet in that region? The network is global; subnets are regional, and custom mode creates none for you. Which rule wins? Lowest priority number; with no rule, ingress is denied and egress allowed. What kind of network is on the other side? A VPC network is peered — both sides, no overlap, not transitive; anything else connects over Cloud VPN.

Topic 6 — Implementing resources through infrastructure as code

ACE-U3.T6 · 1 objective · lecture deck of 8 slides

1. Infrastructure as code tooling (e.g., Cloud Foundation Toolkit, Config Connector, Terraform, Helm)

What this topic actually tests. Which tool? Terraform by default; blueprints for a ready-made start; Config Connector if you live in Kubernetes; Helm to package apps, not cloud resources. Which command? init prepares, plan shows, apply changes, destroy removes. Where is the state? In a shared Cloud Storage backend — never one file per laptop.

Deploying and implementing Compute Engine resources

Study guide for Associate Cloud Engineer, Unit 3 · Topic 1. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Deploying and implementing Compute Engine resources. Considerations include:

1. Launching a compute instance (e.g., assign disks, availability policy, SSH keys)
2. Creating an autoscaled managed instance group by using an instance template
3. Configuring OS Login
4. Configuring VM Manager

Deploying and implementing Compute Engine resources

One machine, then many, then who may log in, then who keeps them patched

One instance — disks, availability, SSH keys. Many instances — an autoscaled managed instance group from an instance template. Who logs in — OS Login. Who keeps them current — VM Manager.

Unit 2 chose the platform and the machine shape. This topic is where an engineer actually builds, and its four objectives follow the life of a fleet. First, one instance: launching a compute instance, and the guide names three things to get right — its disks, its availability policy, and its secure shell (SSH) keys. Second, many instances: an autoscaled managed instance group, created from an instance template. Third, access: configuring OS Login, so that logging in to a virtual machine (VM) is governed by identity and access management (IAM) rather than by keys scattered through metadata. Fourth, upkeep: configuring VM Manager, Google's suite for keeping the operating system (OS) on a whole fleet patched and inventoried. Every slide here names the command or setting that does the work, because that is how this exam asks.

Launching a compute instance

Three decisions at launch: its disks, its availability, and who can connect

• Create: gcloud compute instances create, or the console's OS and storage section
• Disks: a boot disk, plus data disks attached at creation or later
• Availability: the host maintenance policy — live migrate, or stop and restart
• Access: SSH keys in project or instance metadata, or OS Login

Worked example (synthetic). An engineer launches a reporting VM with a second data disk, leaves it to live migrate during maintenance, and adds one colleague's key to that instance's metadata only — not the project's.

The first objective is launching an instance, and the guide's parenthesis tells you what it will test: disks, availability policy, and secure shell (SSH) keys. The launch itself is one command. Google's words: to create an instance with your own configuration, use the gcloud compute instances create command; in the console, the boot disk, the operating system (OS) and any additional non-boot storage are set in the OS and storage section. Disks come in two roles — Google says Persistent Disk can be a boot disk for an instance, or a data disk that you attach to one. Availability is set by what the guide calls an availability policy and Google now calls the host maintenance policy: it chooses how your instance responds during or after a host event. And access comes last: a virtual machine (VM) that does not use OS Login stores SSH keys in project and instance metadata. The next four slides take those one at a time.

Adding a data disk: three steps, not one

Create it, attach it, then format and mount it inside the guest

Worked example (synthetic). A team attaches a new disk and finds it missing from the VM's file system. Nothing failed: the third step, format and mount, was never run.

Adding a data disk is where hands-on candidates lose marks, because it is three steps and people remember two. Create the disk. Attach it: Google says after you create the disk, attach it to any running or stopped virtual machine (VM), using the gcloud compute instances attach-disk command — so there is no need to stop the instance first. Then the step that lives inside the guest rather than in Google Cloud: after you create the new disk and attach it to a VM, you must format and mount the disk, so that the operating system (OS) can use the available storage space. An attached, unformatted disk is present to Compute Engine and invisible to the application. If an exam item describes a disk that is attached and still not usable, the missing step is almost always this one.

The availability policy, in Google's words

The guide says availability policy; the setting is the host maintenance policy

Worked example (synthetic). An instance must come back by itself after a host error. The flag the exam wants is --restart-on-failure — maintenance behavior alone does not say what happens after a crash.

This is a naming mismatch worth knowing before the exam. The guide asks about an availability policy; Google's documentation calls the same thing the host maintenance policy, and splits it into settings. Maintenance behavior is whether the instance is live migrated or stopped when there is a maintenance event, set with the --maintenance-policy flag. Restart behavior is whether Compute Engine restarts or terminates the instance if it crashes, experiences a host error, or becomes unresponsive — include --restart-on-failure to restart automatically, or --no-restart-on-failure to prevent it. Both can be set at creation, and for an existing instance Google says to use the gcloud compute instances set-scheduling command. Keep the two settings apart: one answers what happens during planned maintenance, the other what happens after something breaks.

What a host event does to the instance

Live migration is the default; disks survive either path

Figure: A flow from a host maintenance event. With the default live migrate behavior the instance moves to a new host and keeps running. With stop, the instance is stopped, and restart behavior decides whether it is restarted automatically or stays stopped. On both paths the Persistent Disk data persists.

Worked example (synthetic). A web VM is on the default policy. During a maintenance event it keeps serving, because it was live migrated — nobody had to configure anything.

Drawn out, the policy is two questions in sequence. When a host event arrives, the first is maintenance behavior, and Google is explicit about the default: by default, most instances are set to live migrate during host events. During live migration Compute Engine moves your instance away from the maintenance event and your instance remains running during the migration. If the instance is set to stop instead, the second question applies — restart behavior — and that decides whether it comes back by itself. One reassurance holds on both paths: because Persistent Disk and Hyperdisk are network storage, Google says the data on those disks persists through live migration and instance restarts. So the policy decides whether the virtual machine (VM) keeps running, not whether its disk data survives.

Where SSH keys live, and who they reach

Project metadata reaches every VM; instance metadata reaches one

Figure. Three cards. Project metadata keys reach all VMs in the project except those blocking project-wide keys. Instance metadata keys reach one VM. OS Login ties keys to a Google identity and the guest agent ignores metadata keys. Beneath: connect with gcloud compute ssh; expired keys remain in metadata but cannot open new connections.

Worked example (synthetic). A contractor needs one VM and nothing else. Their key goes in that instance's metadata; in project metadata it would reach every VM that does not block project-wide keys.

The third launch decision is access, and the scope question is what the exam tests. For a virtual machine (VM) without OS Login, secure shell (SSH) keys live in metadata at two levels. Google says you can use keys stored in project metadata to access all VMs in a project — except VMs that block project-wide SSH keys — and keys stored in instance metadata to access individual VMs. So a key for one person and one machine belongs in instance metadata. There is a third arrangement, which the next objective covers, and it ties the operating system account to a Google identity: if OS Login is enabled for a VM, its guest agent ignores the keys stored in metadata altogether. Two operational details round this out. You connect with the gcloud compute ssh command. And Compute Engine does not automatically remove expired keys from metadata, though expired keys cannot establish new connections.

An autoscaled managed instance group from a template

The template says what each VM is; the group says how many and where

• Template: machine type, boot image, labels, startup script — saved once
• A MIG must be created from an instance template
• Templates can't be updated — create a new one instead
• Autoscaler: adds VMs as load rises, deletes them as it falls

Worked example (synthetic). A team needs a bigger machine type for its group. It cannot edit the template; it creates a new template with the new type and points the group at it.

The second objective joins two resources. An instance template, in Google's words, is a convenient way to save a virtual machine (VM) instance's configuration — machine type, boot disk image, labels, startup script and other properties. A managed instance group (MIG) is a group of VMs you treat as a single entity, and each VM in it is based on an instance template; Google is firm that if you want a group of identical VMs, you must create the MIG using an instance template. Two template rules are tested often. You cannot update an instance template after it is created — you create a new one. And unless you need to reuse a template across regions, Google recommends regional templates over global ones. Autoscaling is what makes the group elastic: an autoscaler adds or deletes instances based on the group's autoscaling policy, adding VMs when load rises and deleting them when it falls.

Three commands, in order

Template, then group, then autoscaler

Figure: Three commands in sequence: create the instance template, using the instance template region flag for a regional template; create the managed instance group from that template with a size and an optional health check; then set autoscaling, where the maximum number of replicas is required alongside a target CPU utilization.

Worked example (synthetic). An engineer runs set-autoscaling with a CPU target and no maximum, and the command is refused. The maximum number of replicas is required when creating an autoscaler.

On the command line the objective is three commands, and the order is forced because each consumes the one before. First the template: gcloud compute instance-templates create — and Google notes that for a regional template you must use the --instance-template-region flag. Second the group: gcloud compute instance-groups managed create, pointing at the template and giving a size; the same command can attach a health check at creation. Third the autoscaler: Google says to use the set-autoscaling sub-command to enable autoscaling for a managed instance group (MIG), and it states a requirement candidates miss — along with the --target-cpu-utilization parameter, the --max-num-replicas parameter is also required when creating an autoscaler. The target is written as a fraction of central processing unit (CPU) capacity. An autoscaler must also always have at least one scaling signal; CPU is simply the most common one.

A regional MIG, and what it recreates

Two zones for resilience — and disks that go with their VM

Figure. Users send requests to Cloud Load Balancing, which spreads them across a regional managed instance group with one VM in zone a and one in zone b, both created from the same instance template. Each VM has an attached Persistent Disk. The callout notes that the autoscaler adds and deletes VMs, autohealing recreates unhealthy ones, and their disks are recreated too unless the group is stateful.

Worked example (synthetic). A team stores uploaded files on a MIG VM's attached disk. After autohealing recreates the VM, the files are gone — the default recreates disks with their VM.

This is the group the objective builds, drawn so the two traps are visible. A regional MIG spreads its virtual machines (VMs) across zones; Google gives the reason as distributing VMs across multiple zones in a region to protect against zonal failure. Every VM is stamped from the same template, and that has a location consequence: if a template names a zonal resource, Google says that restricts the template to that resource's zone. The second trap is the disks. The default behavior for all persistent disks in a managed instance group (MIG) is to delete or recreate them when their VM is deleted or recreated, so you should not rely on attached disks as persistent data. Autohealing makes that concrete: if a health check finds an application not responding, the MIG marks the VM unhealthy and repairs it by default. If data must survive, the group needs stateful configuration — disks that retain data whenever VMs are autohealed, updated or recreated.

The autoscaler's settings, and what each one prevents

Signals, a ceiling, a warm-up, and a repair

Worked example (synthetic). A group keeps adding VMs during every deployment because new VMs show high CPU while they boot. Lengthening the initialization period stops that.

Four settings decide whether an autoscaled group behaves. The scaling signal: Google says an autoscaling policy must always have at least one. The ceiling: the maximum number of replicas, required alongside a central processing unit (CPU) target. The warm-up, which Google now calls the initialization period — formerly the cool down period — is the time it takes for applications to initialize on your virtual machine (VM) instances, and it matters because for scale-out decisions the autoscaler ignores usage data from instances still initializing. Set it too short and every busy new VM looks like more load. And the repair: autohealing, which Google defines as repairing a VM based on an application-based health check. Autoscaling changes how many VMs there are; autohealing replaces the ones that are broken. An exam item that mixes them is usually testing exactly that difference.

Configuring OS Login

SSH access governed by IAM, instead of keys spread through metadata

• Enable: enable-oslogin=TRUE in project or instance metadata
• Effect: metadata SSH keys are no longer accepted
• Access follows IAM — removing permissions revokes access
• Recommended by Google for many users across many VMs or projects

Worked example (synthetic). An engineer leaves the company. With OS Login, removing their IAM grants ends their access to every VM at once; with metadata keys, someone must find and delete each key.

The third objective replaces key management with identity. Google's description: use OS Login to manage secure shell (SSH) access to your instances using identity and access management (IAM), without having to create and manage individual SSH keys — and it calls OS Login the recommended way to manage many users across multiple compute instances or projects. Configuring it is one metadata value. You can enable OS Login for a single virtual machine (VM), or all VMs in a project, by setting enable-oslogin to TRUE in project or instance metadata; at creation that is --metadata enable-oslogin=TRUE. Know the side effect: when you set OS Login metadata, Compute Engine deletes the VM's authorized_keys files and no longer accepts connections from SSH keys stored in metadata. The payoff is revocation. If you remove IAM permissions from a Google identity, access to compute instances is revoked, because Google checks permissions for every login attempt. The operating system (OS) account simply follows the identity.

OS Login's roles and switches

Two login roles, a second factor, and a way back

Worked example (synthetic). A developer can log in to a VM but cannot run sudo. They hold roles/compute.osLogin; administrative access needs roles/compute.osAdminLogin.

Once OS Login is on, access is a matter of which role a person holds. Google defines two: roles/compute.osLogin grants login access without sudo access, and roles/compute.osAdminLogin grants login access with sudo access. So a user who can connect but cannot administer the operating system (OS) has the first and needs the second. A second factor is available, with one catch the exam likes: for OS Login two-factor authentication to be enforced, both the enable-oslogin and the enable-oslogin-2fa metadata values must be set to TRUE — setting only the second does nothing. And the switch works in reverse: when OS Login is disabled, you can connect to your virtual machines (VMs) using secure shell (SSH) keys stored in metadata again. One caution from Google's page is worth carrying out of this slide: a user who connects to a VM can use every identity and access management (IAM) permission granted to the service account attached to it.

Configuring VM Manager

Patch, inventory and OS policies for a whole fleet

• Patch: on-demand and scheduled patching, with compliance reporting
• OS inventory management: collect and review OS information
• OS policies: install, remove and auto-update software packages
• Scope: one VM, a project, or every project in a folder or organization

Worked example (synthetic). An operations team must prove every Linux VM got last month's security update. VM Manager's Patch service applies it on a schedule and reports compliance.

The fourth objective is upkeep at fleet scale. Google describes VM Manager as a suite of tools to manage operating systems for large virtual machine (VM) fleets running Windows and Linux on Compute Engine, and it has three services, each with one job. Patch applies on-demand and scheduled patches, and can also be used for patch compliance reporting. OS inventory management collects and reviews operating system (OS) information. OS policies install, remove and auto-update software packages. When a scenario asks you to keep a fleet current, prove it is current, or know what is installed on it, those are the three services in that order. Scope is flexible: Google says you can enable VM Manager for individual VMs, for a project, or for all projects in a folder or organization. The next slide is what enabling it actually involves.

Turning VM Manager on

An API, an agent, and a metadata value — or a policy that sets it

Figure. Three numbered steps: enable the OS Config API with gcloud services enable osconfig.googleapis.com; check the OS Config agent is installed on each VM, since VM Manager cannot be enabled where no agent exists for that OS; set the agent's metadata on the project or each VM. Beneath: the Require OS Config organization policy sets the metadata for new VMs only, not for VMs or projects created before it.

Worked example (synthetic). A team applies the Require OS Config policy and expects its existing VMs to appear in VM Manager. They don't — the policy sets metadata for new VMs; the existing ones need their metadata updated.

Enabling VM Manager is three pieces, and an exam item usually removes one. The application programming interface (API): Google says to enable the OS Config API in your project — gcloud services enable osconfig.googleapis.com is the command. The agent: on each virtual machine (VM), check the OS Config agent is installed, and note the hard limit — if the agent is not available for a particular operating system (OS), you cannot enable VM Manager for a VM running it. The metadata: on either the project or each VM, set the metadata for the OS Config agent. At organization scale there is a shortcut, the Require OS Config organization policy, which automatically sets the VM Manager metadata for all new VMs in an organization, folder or project. Read the word new. Google states that this policy does not change the enable-osconfig metadata for VMs or projects created before it was enabled; for those, you update the metadata yourself.

What this topic actually tests

Four objectives, each with one step candidates skip

Disks: attach, then format and mount. Availability: the host maintenance policy — live migrate by default. MIGs: templates can't be edited; disks are recreated with their VM. OS Login: metadata keys stop working; sudo needs osAdminLogin. VM Manager: API, agent and metadata — the org policy only reaches new VMs.

Each objective in this topic has one step that candidates skip, and the exam is built around those steps. Launching an instance: an attached data disk still has to be formatted and mounted inside the operating system (OS), and the guide's availability policy is Google's host maintenance policy, which live migrates by default. The autoscaled group: an instance template cannot be updated, so a change means a new template; the maximum number of replicas is required when you create a CPU-based autoscaler; and a managed instance group (MIG) recreates disks along with their virtual machine (VM) unless it is stateful. OS Login: once enable-oslogin is TRUE, secure shell (SSH) keys in metadata stop being accepted, and sudo needs roles/compute.osAdminLogin rather than roles/compute.osLogin. VM Manager: the application programming interface (API), the agent and the metadata must all be present, and the Require OS Config policy only reaches new VMs. Hold those five and this topic's scenarios become recognition rather than recall. The central processing unit (CPU) target is the one number you will set, and it is always written as a fraction.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 3
• Create and start a Compute Engine instance
• Add a Persistent Disk to your VM — Compute Engine
• Host maintenance overview — Compute Engine
• Add SSH keys to VMs — Compute Engine
• Instance templates — Compute Engine
• Basic scenarios for creating managed instance groups — Compute Engine
• Autoscaling groups of instances — Compute Engine
• About OS Login — Compute Engine
• Set up OS Login — Compute Engine
• VM Manager — Compute Engine
• Set up VM Manager — Compute Engine
• Set instance host maintenance policy — Compute Engine
• Connect to Linux VMs — Compute Engine
• Create instance templates — Compute Engine
• Scaling based on CPU utilization — Compute Engine
• Set up an application health check and autohealing — Compute Engine