Module 1: GCP Foundations

GCP Structure: Projects and Billing

Everything you create in Google Cloud lives inside a project, and every project that uses paid services is attached to a billing account. Understanding this structure before you create your first virtual machine saves you from the two most common beginner problems: resources scattered with no clear owner, and surprise charges nobody can explain. This lesson shows you how Google Cloud organises resources and money.

The resource hierarchy

Google Cloud arranges resources in a tree:

1. Organisation: the root node, tied to a company domain through Google Workspace or Cloud Identity (for example example.co.ke). Individual accounts may have no organisation at all.
2. Folders (optional): group projects by department, team or environment, such as Finance, Engineering/Production, Engineering/Development.
3. Projects: the basic container for resources, APIs, permissions and billing.
4. Resources: virtual machines, storage buckets, databases and so on, each belonging to exactly one project.

Two rules make this hierarchy powerful. First, policies are inherited downward: an access permission granted on a folder applies to every project inside it. Second, organisation policies set at the top can restrict what anyone below may do, for example limiting which regions resources may be created in.

Projects in detail

Every project has three identifiers:

Each project also has its own set of enabled APIs. Before you can use a service such as Compute Engine or Cloud Run in a project, its API must be enabled. The console usually prompts you; on the command line you enable it explicitly.

Projects are the natural boundary for environments and applications. A sensible pattern is one project per application per environment: duka-dev, duka-staging, duka-prod. Separating them means a developer experimenting in development cannot accidentally delete production data, and each environment's cost shows separately on the bill.

Billing accounts

A Cloud Billing account holds the payment method (for example a card or invoiced billing) and pays for the projects linked to it. One billing account can pay for many projects; each project is linked to at most one billing account at a time. If a project has no billing account, paid services in it stop working.

Billing has its own permissions, separate from project permissions. For example, the Billing Account Administrator can manage payment details and link projects, while a Billing Account Viewer can see costs without changing anything. Keep the number of billing administrators small.

New customers are often eligible for a free trial credit, and Google Cloud also offers an Always Free tier with limited monthly usage of some products. The amounts, eligible products and conditions change over time and can vary by region, so check the current terms on Google Cloud's official free-tier page rather than relying on figures from articles or videos.

Worked example: setting up a small business

A Nairobi company, Duka Online, is moving its e-commerce site to Google Cloud. A tidy setup looks like this:

Organisation: dukaonline.co.ke
  Folder: Production
    Project: duka-prod        (billing: Duka Main Billing)
  Folder: Non-production
    Project: duka-dev         (billing: Duka Main Billing)
    Project: duka-sandbox-amina (billing: Duka Main Billing, budget alert set)

Creating and linking a project with the gcloud command-line tool:

gcloud projects create duka-dev-2026 --name="Duka Dev" --folder=FOLDER_ID
gcloud billing accounts list
gcloud billing projects link duka-dev-2026 --billing-account=XXXXXX-XXXXXX-XXXXXX
gcloud config set project duka-dev-2026
gcloud services enable compute.googleapis.com run.googleapis.com

Labels help you analyse costs later. Add them to projects and resources, for example env=dev, team=web, app=shop; billing reports can then be filtered by label.

When a project is no longer needed, shut it down with gcloud projects delete PROJECT_ID. Deletion is not instant: the project enters a recovery period during which it can be restored, and its resources stop running and billing.

Common mistakes to avoid

• Putting development and production in one project. Mistakes and costs mix together.
• Choosing a project ID you regret. It is permanent and appears in URLs and commands; choose something clear.
• Using a personal card and account for company work, so the business loses access when someone leaves.
• Leaving abandoned test projects running. Review projects regularly and delete what you no longer need.