3.1 Enabling APIs and Provisioning Cloud Operations Suite

Enabling APIs and Provisioning Cloud Operations Suite

Quick Answer: Every Google Cloud API is disabled by default on a new project, so before you can call Compute Engine, run a query in BigQuery, or deploy a container to GKE, you (or your automation) must explicitly enable that API's Service. Separately, the Associate Cloud Engineer (ACE) exam guide names two more Section 1.1 bullets you must know cold: enabling APIs within projects and provisioning and setting up products in Google Cloud's operations suite (the rebranded "Stackdriver" toolset — Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler, and Error Reporting).

Why This Matters on the Exam

ACE loves scenario questions where a gcloud command fails with a permission-denied or "API not enabled" error, and you have to pick the fix. It also tests whether you understand that enabling an API is not the same as being authorized to use it — those are two separate control planes (Service Usage vs. IAM), and mixing them up is one of the most common wrong answers on practice exams. Setting up observability (the operations suite) is graded as its own setup task because a newly provisioned environment is only "done" once someone can actually see what's happening inside it.

APIs Are Disabled by Default

Google Cloud exposes hundreds of APIs (also called services) — for example, compute.googleapis.com for Compute Engine or container.googleapis.com for Google Kubernetes Engine (GKE). A brand-new project has almost none of them turned on. Attempting to call an API before enabling it returns an error like SERVICE_DISABLED, even if the calling identity has full IAM permissions on the resource type.

Console path: APIs & Services → Library → search for the API → Enable.

gcloud path:

gcloud services enable compute.googleapis.com
gcloud services enable container.googleapis.com --project=my-project
gcloud services list --enabled
gcloud services list --available

Behind the scenes, all of this is managed by the Service Usage API, which is why the IAM permission you need to enable or disable services is serviceusage.services.enable — bundled into the predefined Service Usage Admin role (roles/serviceusage.serviceUsageAdmin) as well as the broader Project Editor and Owner roles.

The Trap: Enablement ≠ Authorization

A project Owner who enables compute.googleapis.com has not thereby given a teammate permission to create VMs. Enabling an API only makes the API reachable for the project; a caller still needs an IAM role (e.g., roles/compute.instanceAdmin.v1) granting the specific permissions on the resource. Exam questions frequently describe "a developer can't create a Compute Engine instance" and offer both "enable the Compute Engine API" and "grant the Compute Instance Admin role" as options — you have to read the scenario carefully to tell which layer is actually broken (or whether both are).

Provisioning Google Cloud's Operations Suite

The operations suite (formerly Stackdriver) is Google Cloud's built-in observability toolkit:

Cloud Logging captures Google Cloud platform and audit logs automatically for most services with no setup — the "provisioning" work is mostly about Cloud Monitoring. Every Google Cloud project has a metrics scope, which defines which projects' time-series data can be viewed and charted together. By default, a project's metrics scope contains only itself. To centralize monitoring — a very common ACE scenario — you designate one project as the scoping project and add other projects (dev, staging, prod, or per-team projects) into its metrics scope. A single metrics scope can currently monitor up to 375 projects. Only the scoping project stores the configuration (dashboards, alerting policies, uptime checks, SLOs); the underlying metric data still physically lives in each source project.

Exam Scenario

A platform team has 12 microservice projects under one folder. Leadership wants a single dashboard showing error rates and latency across all 12 without moving any workloads. The correct move is to pick (or create) one scoping project, then add the other 11 projects to its metrics scope in Cloud Monitoring — not to consolidate them into one project, and not to export logs to BigQuery (that solves log analytics, not a live cross-project dashboard).

Common Traps to Avoid

• Assuming enabling an API also grants IAM permission to use the resulting resources — it does not.
• Believing Cloud Logging must be manually "turned on" per project — platform/audit logging is automatic; what you configure is retention, sinks, and exports (covered in Chapter 13).
• Confusing a Workspace (the deprecated pre-2022 model, one project = one workspace) with the current metrics scope model, where one project can now belong to scopes with up to 375 projects.
• Forgetting that gcloud services enable requires the Service Usage Admin permission — a Viewer-only account cannot enable new APIs even if it can see that they're disabled.