Google Cloud Accounts: Projects, Billing and Credit Headroom

Google Cloud is unusual among the large providers in how cleanly it separates the container for your resources from the thing that pays for them. Understanding that split explains most of what is distinctive about a GCP profile.

Projects are the unit of work

Everything in Google Cloud lives inside a project. Virtual machines, storage buckets, service accounts, API enablements and IAM bindings are all scoped to one. A project has an ID that cannot be reused, and it is the boundary most permissions are written against.

This has a practical effect: creating a clean project inside an existing account is cheap and gives you a fresh namespace without touching anything already there. When you inherit an account with unfamiliar resources, starting a new project is often tidier than untangling an old one.

Billing accounts are separate and detachable

A billing account is its own object. It holds the payment method, the billing contacts and any promotional balance, and it can be linked to many projects or unlinked from all of them.

Two consequences follow. First, a project without a linked billing account can exist but cannot run chargeable resources, which is a common reason a technically valid launch is refused. Second, promotional credit belongs to the billing account rather than to any individual project, so it is consumed by whichever projects are attached.

What upgraded status changes

A new Google Cloud profile typically starts in a restricted state with hard ceilings designed to prevent abuse. Completing billing verification moves it out of that state. The visible effects are higher default quotas, access to a wider set of machine types, and the removal of the automatic stop that applies when a trial balance is exhausted.

This is what the upgrade configuration in the catalogue refers to. It is a billing-side property rather than a technical one, but it is the difference between an account that can run a production workload and one that cannot.

APIs are opt-in per project

Google Cloud requires each API to be enabled before it can be used, per project. Compute Engine, Cloud Storage and the rest each have a switch. Inheriting a project with a set of APIs already enabled saves a little time; more importantly, it tells you what the project was previously used for.

It is worth reviewing enabled APIs on any inherited project. An API you do not intend to use is not a cost by itself, but it is surface area.

Quotas follow the account, not the project

Many quotas are enforced at the level of the account and region rather than the project, so creating a new project does not reset them. If you plan to run a large number of virtual CPUs in one region, check the figure in the console rather than assuming a fresh project starts clean. The general behaviour is covered in quotas and service limits explained.

Current catalogue options

The configurations below are read directly from the OldCloudShop catalogue, so they always reflect what is currently listed.

Matching a configuration to a workload

• Short experiments and prototypes. A modest credit balance is usually enough to evaluate Compute Engine or Cloud Storage without attaching spend to your own card immediately.
• Sustained development environments. Upgraded status matters more than balance here, because the ceilings are what get in the way.
• Data or model work with a defined budget. Larger credit tiers suit workloads where you know roughly what you intend to consume and want the runway in advance.

Whatever the tier, treat the balance as finite and dated. What happens when it runs out is covered in planning for credit expiry.

First tasks after taking control

1. Change the password and reconfigure two-factor authentication on a device you control.
2. Update the recovery email and phone number, and confirm the previous ones are removed.
3. Review IAM on every project and remove principals you do not recognise.
4. Check the billing account for the remaining balance and its expiry date.
5. Set a budget alert well below your expected monthly spend.
6. Enable audit logging so later questions have answers.

Google’s terms of service continue to govern the account throughout, and normal provider rules about acceptable use apply regardless of how ownership changed.