Skip to main content

Projects

Exam guide§1.1

The project is the practical unit of Google Cloud. Every resource belongs to exactly one project, and four things are scoped to it: billing linkage, enabled APIs, quotas, and most IAM. If a scenario mentions any of those, the answer is almost always "per project."

Creating and organizing

Start with the three identifiers a project carries - you choose the ID once, at creation, and can never change it, so pick carefully.

Project IDGlobally uniqueAssigned by Google Cloud but mutable during creationImmutable after creationProject nameNeed not be uniqueChosen by youMutableProject numberGlobally uniqueAssigned by Google CloudImmutable
Every project carries three identifiers: a project ID (you finalize it at creation, then it is immutable), a project name (a mutable display label), and a Google-assigned project number.

You can create a project either in the console or the CLI - both do the same thing and enforce the same immutable ID.

In the console, the New Project dialog derives the ID from the name and warns It cannot be changed later.

Google Cloud console New Project dialog: project name field with an auto-generated project ID marked as unchangeable

In the CLI, one command creates it and another makes it active:

CommandsCreate and switch
gcloud projects create my-proj-id --name="My Project" --folder=FOLDER_ID
gcloud config set project my-proj-id # make it the active project
gcloud projects describe my-proj-id
gcloud projects delete my-proj-id # 30-day soft-delete, recoverable

Switching the active project

The console project picker (top bar) and gcloud config set project both change which project subsequent actions target. In Cloud Shell the two are independent: switching the console picker does not move the shell, so set it explicitly.

Cloud Shell setting the active project with export PROJECT_1_ID and gcloud config set project
GotchaShutting down is a scheduled 30-day soft delete

The console Shut Down flow makes you retype the project ID to confirm. Billing and traffic stop immediately, but deletion is only scheduled for 30 days later, so an accidental shutdown is recoverable within that window. gcloud projects delete behaves the same way.

Google Cloud console Shut down project confirmation dialog requiring the project ID, noting deletion is scheduled after 30 days

Enabling APIs

Every Google Cloud service is off by default. Before you (or gcloud) can use a product, its API must be enabled on that project.

CommandsManage APIs
gcloud services list --available # everything you could enable
gcloud services list --enabled # what's on for this project
gcloud services enable compute.googleapis.com
gcloud services disable compute.googleapis.com
GotchaThe "it works in dev but not prod" trap

APIs are enabled per project. Copying a working deployment to a new project fails with API not enabled until you enable the same APIs there. This is a common wrong-answer distractor dressed up as a permissions problem.

Quotas

Quotas cap resource usage per project, per region (e.g. "CPUs in us-central1", "in-use external IPs"). They exist to prevent runaway spend, not to bill you.

  • Rate quotas reset over time (API requests per minute).
  • Allocation quotas are a ceiling on concurrent resources (VMs, IP addresses).
Resource countPER PROJECT15VPC networksper projectAPI ratePER PROJECT5Spanner admin actionsper secondRegionalPER REGION24CPUsper region
The same project meets quotas on three axes: how many resources it can hold, how fast it can call an API, and how much it can allocate in one region.

They exist for three reasons:

  • Prevent runaway consumption from an error or malicious attack (imagine a typo that spins up 100 VMs instead of 10).
  • Prevent billing spikes or surprises.
  • Force sizing consideration and periodic review - do you really need that 96-core instance, or a smaller, cheaper one?
GotchaQuota is not billing, and increases are not instant

Hitting a quota returns a quota exceeded error even though you'd happily pay for more. The fix is a quota increase request through the console (IAM & Admin → Quotas), which Google reviews - it is not automatic. Exam scenarios about "can't launch more VMs" with budget available point to quota, not billing.

GotchaQuota is a ceiling, not an availability guarantee

Having quota does not mean the capacity exists. If a region is out of local SSDs, you cannot create a local SSD there even with unused local-SSD quota. Quota is the maximum you may create as long as those resources are available.

Recap

DECISIONBlocked from creating a resource - which limit?
Quota 'CPUS' exceededRegional quota - request increase
Billing account ... disabledBilling, not quota
API [x] not enabledEnable the service
Permission deniedIAM role missing
Pick this when: match the error text to the limit type