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