GCP Quotas and Resource Limits

Quotas in Google Cloud are hard limits on the amount of a particular resource that can be consumed within a project. They exist to prevent runaway consumption, ensure fair resource distribution among tenants, and protect Google's infrastructure from abuse. Quotas are enforced at the project level and are not tied to billing accounts—even if you have unlimited budget, you cannot exceed your quota without an increase request.

There are two main types of quotas: rate quotas and allocation quotas. Rate quotas limit the rate at which API requests can be made (e.g., 1000 requests per minute per project). Allocation quotas limit the total number of resources that can exist at any time (e.g., max 100 VMs per region per project). The ACE exam focuses heavily on allocation quotas because they directly affect resource creation.

When you issue a command to create a resource (e.g., a Compute Engine VM), the request goes to the relevant API. Before the resource is provisioned, the API checks the current usage against the quota. If the new resource would cause the quota to be exceeded, the API returns an error (HTTP 429 Too Many Requests for rate quotas, or a specific error like QUOTA_EXCEEDED for allocation quotas). The request is never executed. This check happens synchronously and is atomic—there are no race conditions that could allow temporary overuse.

Quotas are enforced per project, per region, and per resource type. For example, Compute Engine has separate quotas for CPUs, disks, and static IPs in each region. You can view quotas in the Cloud Console under IAM & Admin > Quotas, or via the gcloud compute regions describe command.

The ACE exam expects you to know approximate default quotas for common resources. Note that these can change over time, but as of the current exam:

These defaults are important because exam questions often present scenarios where a user hits a quota limit. You must identify which quota is exceeded and how to resolve it.

You can view quotas using:

Example command to list Compute Engine quotas for us-central1:

gcloud compute regions describe us-central1 --format="table(quotas.metric, quotas.limit, quotas.usage)"

Output:

METRIC              LIMIT  USAGE
CPUS                24      12
DISKS_TOTAL_GB      10240   2048
STATIC_ADDRESSES    20      3
...

When you need more resources than the default quota, you can request an increase via the Cloud Console (IAM & Admin > Quotas > select quota > Edit Quota). You must provide a justification and expected usage. The request is reviewed by Google Cloud support. For most quotas, increases are approved automatically for reasonable amounts (e.g., doubling CPUs). Some quotas, like those for GPU instances, require manual review. The process can take from minutes to days.

Important: Quota increases are applied per project, per region. You cannot increase a global quota—you must increase each regional quota separately.

Quotas interact with:

Note that some services have 'limits' that are not adjustable (e.g., maximum size of a single Cloud Storage object is 5 TB). Quotas are adjustable; limits are not. The exam may ask about this distinction.

# View all quotas for a project
gcloud compute project-info describe --project [PROJECT_ID]

# View regional quotas
gcloud compute regions describe [REGION]

# List quota usage with filter
gcloud compute regions describe us-central1 --format="table(quotas.metric, quotas.limit, quotas.usage)"

# Request quota increase (via console or gcloud alpha)
gcloud alpha compute quotas update --project [PROJECT_ID] --region [REGION] --metric [METRIC] --limit [NEW_LIMIT]

Note: The gcloud alpha command may not be available in all environments; the console is the primary method.

Scenario 1: E-commerce Platform Scaling for Holiday Traffic A retail company runs its e-commerce site on Compute Engine in us-central1. During Black Friday, they need to scale from 20 VMs to 100 VMs. Their default CPU quota is 24 CPUs in us-central1. They hit the quota error when trying to create the 25th VM. The solution: two weeks before Black Friday, they request a quota increase to 200 CPUs in us-central1 via the console, explaining the expected traffic spike. They also set up Cloud Monitoring alerts at 80% usage. During the event, they scale up without issues. The mistake many engineers make is waiting until the last minute; quota increases can take time for manual review if the request is large or unusual.

Scenario 2: Startup Running Out of Static IPs A startup uses multiple load balancers and VPN gateways, each requiring static IPs. They hit the default quota of 20 static IPs per region. They attempt to create a new VPN gateway and get an error. The engineer checks the quota and finds 20 IPs are in use. They release unused IPs (e.g., old load balancers) to free up 3 IPs, allowing the new gateway. However, they also request a permanent increase to 50 IPs. Common pitfall: forgetting that reserved but unattached IPs count against quota.

Scenario 3: API Rate Limiting on a High-Traffic App A data analytics application makes thousands of BigQuery API calls per second. The default rate quota for BigQuery is 100 requests per second per project. The application gets HTTP 429 errors. The engineer implements exponential backoff with jitter in the client code, which reduces the peak rate. They also request a rate quota increase via the console, but for rate quotas, increases are often approved only after demonstrating need. The engineer also considers distributing load across multiple projects (each with its own quota).