Billing, gcloud CLI & Cloud Tooling

Assumes you're comfortable with Part 1's resource hierarchy and project model. This chapter answers the next two questions any new environment raises: who pays, and what tool do you actually use to build it.

Table of Contents#

1. What This Chapter Covers
2. Billing Accounts: Self-Serve vs. Invoiced
3. Linking Projects and the Billing Hierarchy
4. Budgets and Alerts: What They Actually Do
5. Billing Data Export: FOCUS, Standard, and Detailed Usage
6. The gcloud CLI: Configurations, Components, and Auth
7. Cloud Shell and Client Libraries
8. Infrastructure as Code: Terraform and the Google Provider
9. Config Connector: Kubernetes-Native Infrastructure Management
10. Helm for Application-Layer Packaging
11. Fabric FAST: An Opinionated Landing Zone Factory
12. AI-Assisted Tooling: the 2026 Landscape
13. Application Design Center: Application-Centric Infrastructure
14. Choosing the Right Tool for the Job
15. A Full Worked Example: Meridian's Billing and Bootstrap Pipeline
16. Real-World Scenario: The Budget Alert Nobody Was Watching
17. Second Real-World Scenario: The Terraform State Lock That Blocked a Friday Deploy
18. Part 2 gcloud and Terraform Cheat Sheet
19. Pre-Flight Checklist: Is Your Tooling Actually Production-Ready?
20. Common Mistakes and Interview Traps
21. Worked Practice Problems
22. Summary and What's Next

What This Chapter Covers#

🎯 By the end of this chapter, you'll be able to set up a billing account with real cost guardrails, and know which of GCP's five (yes, five) infrastructure-building tools to reach for depending on who's building and how repeatable the result needs to be.

This chapter maps to two ACE exam considerations that sit side by side in the guide for a reason: "managing billing configuration" (part of the setting-up domain) and "planning and implementing resources using tooling" (part of the planning domain). They're related because most of what you'll spend money on gets created by one of the tools in this chapter, and the exam expects you to know both halves.

Billing Accounts: Self-Serve vs. Invoiced#

A Cloud Billing account is a separate resource from a project: it holds a payment method and defines who can be charged, while a project is where resources actually run. GCP offers two billing account types:

A billing account has its own IAM policy, separate from any project's: roles/billing.admin on the billing account lets someone manage payment methods and link/unlink projects, while roles/billing.user lets someone link a new project to an existing billing account without touching payment details at all. This separation matters operationally: a platform team can hand every engineer roles/billing.user so they can self-serve new projects, without ever exposing the underlying credit card or invoice details.

Linking Projects and the Billing Hierarchy#

Every project that consumes billable resources must be linked to exactly one billing account (a project can exist unlinked, but API calls that create billable resources will fail until it's linked). One billing account can have many linked projects, which is the entire mechanism behind Meridian consolidating spend across Freight, Warehousing, and Data Science into one invoice while still tracking cost per project.

Caption: the budget itself only ever sends notifications; everything past the plain email (the Pub/Sub topic, the Slack webhook) is infrastructure you build on top of a budget alert to turn a notification into an actual automated response.

Budgets and Alerts: What They Actually Do#

⚠️ This is one of the most consistently mistested facts on the ACE exam: a Cloud Billing budget does not stop spending. It only notifies. A budget defines a spend target and a set of percentage thresholds; crossing a threshold fires an email to the billing account's admins (and optionally a Pub/Sub message), full stop. If you want spending to actually be capped, you build that yourself, typically a Cloud Function triggered by the budget's Pub/Sub notification that disables billing on the project (gcloud billing projects unlink) or applies a constraints/gcp.disableGcpResourceUsageExport-adjacent lockdown.

Budget alerts also aren't real-time: cost data can lag actual usage by several hours, so a budget alert is a same-day warning system, not a live meter.

Billing Data Export: FOCUS, Standard, and Detailed Usage#

Exporting billing data to BigQuery turns your invoice into a queryable dataset, the foundation for any real cost-allocation or FinOps work (covered in depth in the GCP SRE & Observability course). As of a January 2026 schema update, three export formats are available:

Setup is a one-time flow: create (or choose) a project to hold the export, enable the BigQuery Data Transfer Service API, create a dataset, then turn on export from the Cloud Billing console. Expect a delay of several hours before the first rows appear, and up to five days for a retroactive backfill of the current and previous month to fully catch up; this lag is itself an exam-relevant fact, since it explains why billing-export data is never the right tool for real-time cost incident response.

The gcloud CLI: Configurations, Components, and Auth#

gcloud is GCP's command-line control plane, and its named configurations feature is the detail engineers coming from a single-account AWS CLI setup most often miss: a gcloud config configuration bundles a default project, region, zone, and active account together, letting you switch your entire working context with one command instead of passing --project on every call.

# Create a configuration per environment
gcloud config configurations create meridian-prod
gcloud config set project meridian-freight-prod-8f2k
gcloud config set compute/region us-central1

gcloud config configurations create meridian-dev
gcloud config set project meridian-freight-dev
gcloud config set compute/region us-central1

# Switch between them instantly
gcloud config configurations activate meridian-prod

gcloud's functionality is split into components (gcloud components install kubectl, gcloud components install terraform-tools), installed on demand rather than bundled monolithically, which keeps the base install lean but means a fresh machine needs an explicit gcloud components install pass before kubectl or other extensions work.

Authentication has two distinct paths that get confused constantly: gcloud auth login authenticates you, the human, for interactive gcloud commands and console access; gcloud auth application-default login sets up Application Default Credentials (ADC), a separate credential GCP client libraries and Terraform pick up automatically. Running only the first and then wondering why a Python script using the google-cloud-storage library still fails with DefaultCredentialsError is one of the single most common early-career GCP mistakes.

Cloud Shell and Client Libraries#

Cloud Shell is a free, browser-based shell with gcloud, kubectl, Terraform, and a code editor preinstalled, backed by a small persistent VM with 5 GB of persistent $HOME storage. It's genuinely useful for quick administrative tasks or a first look at a new API from a machine with zero local setup, but its ephemeral compute (the underlying VM recycles after a period of inactivity, though $HOME survives) makes it a poor fit for anything resembling a long-running build or a production automation job.

Client libraries (google-cloud-storage for Python, @google-cloud/storage for Node.js, and equivalents for Go, Java, and others) are the idiomatic way application code talks to GCP APIs, handling auth, retries, and pagination so your code doesn't hand-roll raw REST calls. They authenticate via Application Default Credentials by default, the same mechanism gcloud auth application-default login sets up locally, and via the attached service account automatically when running on GCP compute.

Infrastructure as Code: Terraform and the Google Provider#

Terraform, using HashiCorp's google and google-beta providers, is the dominant infrastructure-as-code tool for GCP in real production environments, valued for being declarative, versionable, and reviewable through the same pull-request process as application code.

resource "google_project" "freight_prod" {
  name       = "Meridian Freight Production"
  project_id = "meridian-freight-prod-8f2k"
  folder_id  = google_folder.production.id
  billing_account = "012345-6789AB-CDEF01"
  labels = {
    business-unit = "freight"
    environment   = "production"
  }
}

resource "google_project_service" "compute" {
  project = google_project.freight_prod.project_id
  service = "compute.googleapis.com"
}

⚙️ Terraform's state file is the mechanism that makes it work: a JSON record of every resource it's created and their current attributes, used to compute the diff between your configuration and reality on every plan. For any team beyond a single engineer, state must live in a shared, lockable backend, a GCS bucket with object versioning enabled is the standard choice on GCP, since a local state file has no way to prevent two engineers from applying conflicting changes simultaneously.

Config Connector: Kubernetes-Native Infrastructure Management#

Config Connector lets you manage GCP resources (a Cloud SQL instance, a Pub/Sub topic, an IAM binding) as Kubernetes Custom Resources, reconciled continuously by a controller running inside a GKE cluster, the same declarative reconciliation loop Kubernetes uses for Pods and Deployments.

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLInstance
metadata:
  name: meridian-orders-db
spec:
  region: us-central1
  databaseVersion: POSTGRES_15
  settings:
    tier: db-custom-2-8192

The differentiator versus Terraform is the reconciliation model: Terraform applies a change once and stops; Config Connector's controller continuously watches for drift and corrects it, the same way a Kubernetes Deployment controller restores a deleted Pod. Teams already running a GitOps workflow for application manifests (Part 2 of the GCP DevOps & CI/CD Platform course covers this in full) often extend the same kubectl apply/Argo CD pipeline to infrastructure via Config Connector rather than maintaining a second, Terraform-specific pipeline.

Helm for Application-Layer Packaging#

Helm is a package manager for Kubernetes manifests, bundling a set of related resources (a Deployment, a Service, a ConfigMap, an HPA) into a single versioned, parameterizable chart. It sits one layer above both Terraform and Config Connector conceptually: those two provision the GCP infrastructure a cluster and its supporting services need, while Helm packages what actually runs inside the cluster once it exists. A GKE cluster provisioned by Terraform, with Config Connector managing its Cloud SQL dependency, and a Helm chart deploying the application onto that cluster, is a genuinely common three-tool stack on real GCP platform teams, and the ACE exam expects you to recognize each tool's actual layer rather than treating them as interchangeable.

Fabric FAST: An Opinionated Landing Zone Factory#

Fabric FAST (part of the open-source cloud-foundation-fabric project, maintained by Google Cloud's own Professional Services engineers) is a staged, opinionated Terraform framework for bootstrapping an entire production-ready GCP organization from scratch: resource hierarchy, org policies, centralized logging, networking, and IAM, deployed in a defined sequence rather than assembled ad hoc. It's the direct successor to what was previously called the Cloud Foundation Toolkit, and the name to know for the exam is Fabric FAST specifically.

Where hand-written Terraform (the pattern shown above) is appropriate for a handful of projects, Fabric FAST is built for the "we're standing up an entire company's GCP presence" scale: it deploys in explicit stages (bootstrap, security foundations, networking, project factory), each with its own state and service account, so a mistake in a later stage can't accidentally corrupt the foundational bootstrap stage's state.

AI-Assisted Tooling: the 2026 Landscape#

This is the section of the exam guide most likely to feel unfamiliar if you last studied a year ago, because the tooling underneath it changed meaningfully in 2026.

Caption: four distinct products, easy to conflate; the sunset arrow matters because a source written before mid-2026 will describe Gemini CLI as the current terminal tool when it's since been superseded for most users.

The four products, disambiguated:

Application Design Center: Application-Centric Infrastructure#

Application Design Center lets a platform team build a reusable, opinionated template (a Cloud Run service plus its Cloud SQL database plus its Pub/Sub topic, say, wired together and parameterized) that developers then instantiate through a visual designer rather than hand-writing Terraform for each new service. The platform team encodes the organization's standards once, in the template; developers get self-service deployment without needing deep IaC expertise, and without silently drifting from the standard the platform team intended.

This is a genuinely different tool from Terraform or Config Connector: those are general-purpose infrastructure-as-code tools that assume the person writing configuration understands the underlying GCP resources. Application Design Center assumes the opposite, that most developers using it shouldn't need to.

Choosing the Right Tool for the Job#

Caption: gcloud sits alone in the imperative, one-off corner (a quick manual fix or a script), while Fabric FAST anchors the far declarative/platform-authored end (bootstrapping the whole organization once); Application Design Center is the outlier reaching toward developer self-service without sacrificing repeatability.

A Full Worked Example: Meridian's Billing and Bootstrap Pipeline#

Meridian's platform team's actual onboarding sequence for a new business unit, combining this chapter's tools end to end:

# 1. Platform team creates the billing account link via Terraform, reviewed in a PR
terraform apply -target=google_billing_budget.freight_monthly

# 2. A budget alert wired to a Cloud Function that posts to Slack and,
#    for non-production projects only, disables billing automatically
gcloud pubsub topics create billing-budget-alerts
gcloud functions deploy budget-alert-handler \
  --runtime=python312 \
  --trigger-topic=billing-budget-alerts \
  --entry-point=handle_budget_alert

# 3. Developers self-service a new microservice from an
#    Application Design Center template the platform team published
#    (no gcloud or Terraform required on the developer's part)

# 4. The platform team's own infrastructure changes go through
#    Terraform with a GCS backend, reviewed like any other pull request
terraform init -backend-config="bucket=meridian-tf-state"
terraform plan -out=freight.tfplan
terraform apply freight.tfplan

Real-World Scenario: The Budget Alert Nobody Was Watching#

Meridian's Data Science team set a $10,000 monthly budget on their sandbox project, with the default single email alert at 100% of spend, sent to a distribution list that included a former team lead who had left the company four months earlier and was never removed. When a runaway BigQuery query (an accidental cross join against an unpartitioned multi-terabyte table, left running over a weekend) pushed the project to 340% of budget, the alert fired correctly, to an inbox nobody on the current team was reading. The bill wasn't caught until the following month's finance review, by which point roughly $23,000 in unplanned spend had accrued.

The fix Meridian implemented afterward: every budget alert's Pub/Sub topic now feeds a Cloud Function that posts to a monitored Slack channel and checks a distribution-list-freshness rule against the current Cloud Identity group membership, flagging any budget still pointing at an individual's email instead of a group alias. The underlying condition wasn't "the alert didn't fire," it was that the alert's audience wasn't kept current the same way any other access grant should be.

Second Real-World Scenario: The Terraform State Lock That Blocked a Friday Deploy#

Two engineers on Meridian's platform team both ran terraform apply against the shared production configuration within seconds of each other on a Friday afternoon. The second apply failed immediately with Error: Error acquiring the state lock, the GCS backend's native locking (via a Cloud Storage object hold) correctly preventing a concurrent write that could have corrupted the state file. The immediate symptom was a blocked deploy; the immediate cause was the lock; the underlying condition was that Meridian had no CODEOWNERS-style convention forcing infrastructure changes through a single CI pipeline instead of allowing any engineer to run apply locally from their own laptop, which is exactly the setup that makes concurrent applies possible in the first place. The real fix, adopted the following sprint, was routing every production Terraform apply exclusively through a CI job with its own serialized queue, leaving local apply access only for non-production projects.

Part 2 gcloud and Terraform Cheat Sheet#

Pre-Flight Checklist: Is Your Tooling Actually Production-Ready?#

• Billing account has more than one roles/billing.admin, so payment-method access doesn't depend on one person
• Every budget's alert audience is a Cloud Identity group, not an individual email address
• At least the 100% budget threshold triggers an automated action, not just a notification email
• Terraform state lives in a shared, versioned, lockable backend, never a local file for anything beyond a personal sandbox
• Production Terraform applies run through CI, not from an engineer's local machine
• Anyone using "Gemini CLI" documentation written before mid-2026 has checked whether Antigravity CLI is the actually-current tool for their use case

Common Mistakes and Interview Traps#

Worked Practice Problems#

Problem 1: Meridian's finance team asks why their $50,000 monthly budget alert fired at 90% of spend but Compute Engine costs kept accruing well past that point over the following week. What's the correct explanation?

Answer: A Cloud Billing budget alert is purely a notification; it has no built-in mechanism to stop resource creation or usage once triggered. Spending continued because nothing was actually configured to act on the alert. To actually cap spend, the team needs to wire the budget's Pub/Sub notification to a Cloud Function (or similar automation) that takes a real action, disabling billing on the project, scaling down a resource, or another explicit response, since GCP will never do this automatically on the team's behalf.

Problem 2: Two platform engineers, working independently, both try to run terraform apply against the same production state within moments of each other. One succeeds; the other fails with a state lock error. Is this a bug, and what should the team change?

Answer: This is expected, correct behavior: Terraform's GCS backend uses object locking specifically to prevent two concurrent applies from corrupting shared state, and the failure is the safety mechanism working as designed. The real problem is process, not tooling: production Terraform applies should run through a single serialized CI pipeline rather than allowing any engineer to apply directly from their laptop, which is what created the race condition in the first place.

Problem 3: A developer wants to deploy a standardized three-tier application (a Cloud Run frontend, a Cloud SQL database, a Pub/Sub queue) without writing any Terraform or Kubernetes YAML, using only a template the platform team already published. Which tool are they using, and why wouldn't Config Connector or plain Terraform fit this requirement as well?

Answer: Application Design Center is the tool: it's specifically built for developer self-service against platform-team-authored templates through a visual designer, with no IaC authoring required from the developer. Terraform and Config Connector both assume the person applying the configuration understands and is willing to write the underlying resource definitions; Application Design Center exists precisely to remove that requirement for developers who shouldn't need that expertise for a standardized, already-vetted pattern.

Summary and What's Next#

This chapter covered the two things every environment needs before real workloads land: a billing setup with actual guardrails (not just notifications nobody's automated a response to), and a clear map of GCP's five infrastructure-building tools, gcloud, Terraform, Config Connector, Helm, and Fabric FAST, plus the fast-moving AI-assisted layer on top (Gemini Cloud Assist, Antigravity, and Application Design Center) that's reshaped significantly since 2025.

Part 3 moves into IAM and identity in full depth: the role taxonomy this chapter's IAM references glossed over, how policy inheritance actually composes across the resource hierarchy, service accounts and their lifecycle, and Workload Identity Federation, the workload-facing counterpart to Part 1's Workforce Identity Federation.