Quotas and system limits

1. The distinction, and why it decides what you do next

	What it is	Can it change?
system limit	"fixed constraints, such as maximum file sizes or database schema limitations"	No — "cannot be increased or decreased"
quota	how much, or how fast, you may consume	Yes, by request

This is the whole of the triage. A failure against a system limit is a design change. A failure against a quota is a request, or a backoff. Reading the vendor's page to find out which one you hit is cheaper than either guess.

2. The two quota types

an allocation quota restricts "how much of a resource Google Cloud allocates to you" — concurrent VMs,

addresses, disks;

a rate quota restricts "the rate at which you can consume a resource" — API requests per minute.

They fail differently. An allocation quota fails at create time and stays failing until something is released or the quota is raised. A rate quota fails intermittently and is answered by truncated exponential backoff first and a quota request second.

3. The scopes a quota can attach to

project · folder · organization · user or service account · and geographically regional, zonal or global.

Two consequences:

"The quota" is not one number. The same metric can be bounded per project and per region. The Azure

hub's record of this platform's own capacity model makes the same point: a refusal that names one bound tells you nothing about the others.

A per-service-account quota means that moving work onto a second identity can be a legitimate

mitigation, where moving it onto a second project would not be.

4. The calls — this is what a document should cite instead of a number

gcloud quotas info ...          # read quota information and current usage
gcloud quotas preferences ...   # read and set quota preferences (requests)

These are beta-surface commands; gcloud must have its beta components available. The console equivalent is IAM & Admin → Quotas & System Limits.

To do this	Role	Permissions named
view quotas	Quota Viewer, `roles/servicemanagement.quotaViewer`	`serviceusage.quotas.update`
request an adjustment	Quota Administrator, `roles/servicemanagement.quotaAdmin`	`serviceusage.quotas.update`, `cloudquotas.quotas.update`

Recorded as the page states it: the view-only role is listed against an update permission, which reads oddly. The hub does not resolve it — read the roles page before relying on the viewer role being read-only.

Google also documents a quota adjuster that requests increases automatically as usage approaches a limit, and quota alerts. For a migration, the adjuster is the difference between a cutover that stalls at 03:00 and one that does not.

5. The rule this hub follows, and why

No adjustable value is typed in any document here. Not as an example, not "as of today". A typed quota is wrong for every project whose quota differs and wrong for every reader after the next adjustment, and the reader cannot tell which. Every document that would need one names the call above instead.

What is written down: a number the vendor states as a system limit — Secret Manager's 64 KiB payload, IAM's 1,500 principals per allow policy, Cloud KMS's "key rings can't be deleted". Those are facts about the platform's shape, and each one is cited to the page that calls it fixed.

6. Cross-cloud

All three clouds separate "fixed" from "askable", and they are not equally askable — AWS publishes a table of increases that are approved automatically, Google Cloud and Azure publish fixed identity ceilings with no request path. The comparison, and what it does to a capacity plan, is in guides/parity/identity.md §3 and guides/parity-and-migration-method.md.