Google Cloud Billing Accounts, Budgets, Alerts, and BigQuery Export

A Cloud Billing account pays for projects: the relationship is one billing account to many projects, and each project links to at most one billing account at a time. The billing account itself holds no resources — it is a payment configuration connected to a Google payments profile, which carries the actual payment instrument, tax and invoicing details. Billing accounts are also resources in the resource hierarchy sense: they belong to an organization (or stand alone for individual accounts) and carry their own IAM policy, separate from any project's policy.

Billing accounts come in two types:

• Self-serve (online) accounts — costs are charged automatically to a credit or debit card or bank account. Anyone can create one; this is what you get by default.
• Invoiced (offline) accounts — Google issues monthly invoices paid by wire transfer or check. Available to eligible businesses that apply and are approved, typical for enterprises with procurement processes.

A project with no active billing account can exist and hold configuration, but any service that costs money stops working: VMs will not start, storage writes fail, APIs that require billing refuse requests. When billing is disabled on a running project, paid resources shut down or degrade and some data can eventually be deleted — so "unlink the billing account" is the drastic, effective answer to "stop all spend now," with real destruction as its cost. The exam likes contrasting that behavior with budgets, which never stop anything.

You create a self-serve billing account from the Console's Billing section: choose Create account, name it, pick the country and currency (fixed at creation, because they come from the payments profile), and attach a payment method. The creator automatically becomes Billing Account Administrator on it. An organization can hold multiple billing accounts, and the common reasons to create more than one are separate payment sources, separate currencies or legal entities, and hard separation of cost centers — for example, one billing account per subsidiary so each receives its own invoice and reports.

Google's guidance leans the other way for everyday structure: prefer fewer billing accounts with many projects, and slice costs by project and label in reports, rather than multiplying billing accounts per team. Creating a billing account inside an organization requires the Billing Account Creator role (roles/billing.creator), typically granted at the organization level and deliberately kept scarce so employees cannot attach company projects to personal cards.

Invoiced accounts are not self-service — the business applies to Google, and once approved the account is provisioned with invoice terms. From the engineer's perspective they behave identically for linking and budgets; only the payment mechanics differ.

Useful commands: gcloud billing accounts list shows the accounts you can see, with their IDs in XXXXXX-XXXXXX-XXXXXX form and an open flag telling you whether the account is active. gcloud billing accounts describe ACCOUNT_ID shows details for one. Closed billing accounts stop paying for their projects, so a project on a closed account is effectively unbilled — same consequences as unlinking.

Linking is a single operation with a two-sided permission requirement — the source of the exam's favorite billing question. In the Console: Billing, then Account management, then link a project; or from the project side, Billing, then Link a billing account. On the command line: gcloud billing projects link my-app-prod --billing-account=0X0X0X-0X0X0X-0X0X0X. Unlink by disabling billing: gcloud billing projects unlink my-app-prod.

To link project P to billing account B you need both sides:

• Permission to spend from B — the billing.resourceAssociations.create permission, carried by Billing Account User (or Administrator) on the billing account.
• Permission to change P's billing — carried by Project Billing Manager on the project (Project Owner also includes it).

Neither role alone is enough, and that is by design: a Project Owner cannot attach their project to a billing account they have no rights on, and a Billing Account User cannot commandeer arbitrary projects onto the company account. The standard enterprise pattern grants Billing Account User to a small group (or to automation that creates projects) and Project Billing Manager to the teams that own projects.

A concrete scenario the exam recycles: a developer creates a sandbox project and complains they cannot enable Compute Engine. The project has no billing link, and the developer lacks Billing Account User on the company account. The least-privilege fix is granting them Billing Account User on that one billing account — not Billing Account Administrator, and not Owner on anything.

Billing uses its own set of IAM roles, granted either on a billing account or on a project, and the exam expects you to match role to task precisely.

Two separation-of-duties patterns are worth memorizing. Finance sees money, not infrastructure: give the finance team Billing Account Viewer (or Administrator if they also manage payment settings) and no project roles at all — they can audit every charge without touching a single VM. Engineers see infrastructure, not money: project Editors and Owners can build resources that generate cost, but without a billing-account role they cannot see invoices, change payment methods, or move projects between accounts.

When a question asks for "the minimal role so X can do Y," strip the task to its verb: link a project — Billing Account User plus Project Billing Manager; view charges — Billing Account Viewer; change the payment card — Billing Account Administrator; create a new billing account — Billing Account Creator.

A budget watches spending against a target and sends alerts — it never stops spending. No matter how many thresholds fire, resources keep running and charges keep accruing. Any answer option implying a budget "prevents" overspend is wrong; that single fact decides several exam questions.

You create budgets in the Console under Billing, then Budgets and alerts. Each budget has three parts:

• Scope — the whole billing account, or narrowed to specific projects, services, and labels. One billing account can carry many budgets with different scopes.
• Amount — a fixed figure, or last period's spend as a dynamic target.
• Threshold rules — percentages of the amount (defaults are 50%, 90%, 100%) that trigger notifications, each evaluated against actual spend or forecasted spend. Forecasted thresholds warn that you are trending toward the limit before money is gone.

By default, threshold emails go to Billing Account Administrators and Billing Account Users on the account — not to Project Owners, a detail the exam checks. To notify other people, link the budget to Cloud Monitoring notification channels (email addresses, chat integrations). For automation, enable programmatic notifications: the budget publishes messages to a Pub/Sub topic with current spend and threshold data, and your subscriber acts on them.

That Pub/Sub hook is also the official answer to "I actually need a hard cap": a common pattern subscribes a Cloud Run function to the budget topic and has it disable billing on the project when spend passes the line — accepting that disabling billing kills the workload. Automated capping is you-built, deliberate, and destructive; it is not a checkbox.

Cloud Billing export to BigQuery is the mechanism for real cost analysis: it writes your billing data into BigQuery tables automatically throughout the day, where you can query it with SQL, join it with other data, and feed dashboards in Looker Studio. The Console's built-in billing reports answer quick questions; BigQuery export answers hard ones — cost per label across projects, month-over-month deltas per SKU, chargeback reports per team.

You configure export per billing account under Billing, then Billing export, choosing a target project and BigQuery dataset (create the dataset first; its location matters because it cannot be trivially moved later). There are three export types:

• Standard usage cost — one row per cost line item: service, SKU, project, labels, usage amount, cost, credits. The workhorse for most analysis.
• Detailed usage cost — everything in standard plus resource-level granularity, so you can attribute cost to an individual VM or disk rather than just a SKU within a project.
• Pricing — your account's price list, useful for estimating and for joining prices against usage.

Two facts carry exam weight. First, export is not retroactive: data flows from roughly when you enable it, so enabling export the day a cost mystery appears gives you nothing about last month — set it up on day one. Second, export is configured per billing account and requires Billing Account Administrator on the account plus BigQuery permissions in the target project. There is also a legacy file export to Cloud Storage, but BigQuery export is the supported, analysis-ready path and the one the exam wants.

Cost analysis starts in the built-in Reports page of the billing account: filter and group spend by project, service, SKU, region, or label, and compare time ranges. Labels are the allocation mechanism — key-value pairs like team=checkout or env=prod applied to resources flow through to billing line items, in both reports and the BigQuery export. A labeling convention established early is what makes "which team spent this?" answerable at all; retrofitting labels does not relabel past spend.

Pulling the whole topic together, here is the setup a new organization performs once:

1. Create (or get approved for) the billing account; confirm the payments profile details.
2. Grant billing IAM: Billing Account Administrator to the cloud platform team, Billing Account Viewer to finance, Billing Account User to the project-creation automation, Project Billing Manager to project owners' groups.
3. Link projects: gcloud billing projects link PROJECT_ID --billing-account=ACCOUNT_ID for each.
4. Enable BigQuery export (standard and detailed usage cost) into a dedicated billing-admin project — immediately, because it is not retroactive.
5. Create budgets: one account-wide budget with 50/90/100% thresholds on actual spend plus a forecasted 100% rule, and tighter per-project budgets for sandboxes, with Pub/Sub programmatic notifications for automation.
6. Define the label taxonomy and enforce it, so reports and exports can be grouped meaningfully.

Gotchas to retain: budgets alert, never cap; alert emails go to billing-account roles by default, not Project Owners; a project needs a live billing link before paid APIs work; and disabling billing is the blunt instrument that stops spend by breaking the workload.