2.1.3. Enabling APIs, Quotas, and Product Availability
💡 First Principle: A newly created Google Cloud project starts with almost every service API disabled by default — this isn't an oversight, it's a deliberate security posture that means a service simply cannot be used, misconfigured, or billed against until someone explicitly turns it on.
Before you can create a single Compute Engine VM or BigQuery dataset, its corresponding API must be enabled for the project — a one-time toggle (via console, gcloud services enable, or Infrastructure as Code) that then permits any properly-permissioned identity to use that service going forward. Once services are running, Google Cloud Observability products (Cloud Monitoring and Cloud Logging) need to be provisioned and configured to actually collect telemetry — they don't retroactively see activity from before they were set up.
Every project also operates under quotas — default limits on things like the number of VM CPUs per region or API requests per minute — that exist to protect both Google's infrastructure and customers from runaway costs due to bugs or misconfiguration. When a legitimate workload needs more than the default allows, you request a quota increase through the console, and Google reviews and approves it, typically within minutes for modest increases. Finally, not every product is available in every region simultaneously — verifying product availability across the specific regions and zones a project needs is a real pre-deployment step, particularly for newer services or specialized hardware like certain GPU families.
Part of this initial setup is also setting up cloud networking at the project level — every new project ships with a Default VPC network already present, and initial setup work means deciding whether to keep, reconfigure, or delete that default network before real workloads land on it. The deep design work (custom subnets, firewall policy, connectivity options) is a Phase 3 topic in its own right — this step is about the project simply having a sane starting network to build on, not the finished architecture.
⚠️ Exam Trap: A scenario where "the API call fails with a permission-like error even though IAM roles look correct" is frequently testing whether you recognize that the API itself might simply be disabled for the project — a distinct failure mode from an IAM misconfiguration, and one candidates often overlook because the error can look superficially similar.
Reflection Question: A batch job that ran fine in testing suddenly starts failing in production with quota-exceeded errors during a traffic spike. What are the two different fixes available, and which one addresses the actual constraint versus just working around it temporarily?
