Enabling APIs

Most GCP APIs are disabled by default in a new project — only a small base set is on out of the box — and Terraform cannot create a resource whose underlying API is off. That makes google_project_service one of the first resources in almost every GCP configuration — you enable compute.googleapis.com before you create an instance, run.googleapis.com before a Cloud Run service, secretmanager.googleapis.com before a secret.

It is also a footgun on three fronts. API enablement is eventually consistent, so a resource created in the same apply can race ahead of the API and fail. A misconfigured disable_on_destroy can tear down an API other configurations still depend on. And enabling APIs by hand instead of in code leaves drift the next plan tries to undo. Each of those has a clean fix, and this topic walks through them.

Why APIs Are Off by Default

A fresh GCP project starts with almost nothing enabled. This is deliberate — it keeps the attack surface and the billable surface of a new project minimal — but it means every service you intend to use must be turned on first. Compute Engine needs compute.googleapis.com, Cloud Run needs run.googleapis.com, Secret Manager needs secretmanager.googleapis.com, and so on for every API in the catalog.

For the Hatch pipeline in hatch-pipeline-dev, that is a handful of services: Compute, Cloud Run, Pub/Sub, BigQuery, Secret Manager, and Cloud Storage. Each must be enabled before the resources that depend on it exist, which is why API enablement is the bootstrap step that comes before everything else in the configuration.

The Resource

google_project_service enables one API on one project. Rather than write a separate block per API, the common pattern is a single resource with for_each over a set of service strings, which keeps the enabled-APIs list in one readable place and creates one resource instance per service.

resource "google_project_service" "apis" {
  for_each = toset([
    "compute.googleapis.com",
    "run.googleapis.com",
    "pubsub.googleapis.com",
    "bigquery.googleapis.com",
    "secretmanager.googleapis.com",
  ])

  project            = "hatch-pipeline-dev"
  service            = each.value
  disable_on_destroy = false
}

Each string in the set becomes one enabled API, addressable as google_project_service.apis["run.googleapis.com"]. Adding a service to the list is a one-line diff, and the disable_on_destroy = false here is the safe default explained two sections down.

The Propagation Race

Enabling an API is not instant. The enablement propagates asynchronously across Google's backend, so a resource created in the same apply, microseconds after the service resource reports success, can still fail with API [run.googleapis.com] not enabled — the classic "API has not been used in project before or is disabled" error. The service was enabled; it just had not propagated yet.

The fix is to make the dependency explicit. A depends_on from the resource to its google_project_service forces Terraform to wait for enablement to report done before creating the resource. Where that is still not enough — the race is timing-dependent — a brief time_sleep between the service and the resource absorbs the propagation lag.

resource "time_sleep" "wait_for_apis" {
  depends_on      = [google_project_service.apis]
  create_duration = "30s"
}

resource "google_cloud_run_v2_service" "processor" {
  name     = "event-processor"
  location = "us-central1"
  depends_on = [time_sleep.wait_for_apis]   # wait out the propagation lag
  # ... template ...
}

The event-processor service now waits for the API set to enable and for a 30-second buffer before it is created, so the run API has time to propagate. Reach for the time_sleep only where the race actually appears — a plain depends_on handles most cases on its own.

disable_on_destroy

disable_on_destroy controls whether destroying the google_project_service resource also disables the API project-wide. Its default changed across provider majors — it was true through 6.x and is no longer true in 7.x — so do not rely on the default; set the flag explicitly. The behavior it guards against is real whenever the flag is true: in a single-stack throwaway project a destroy disabling the API is harmless, but in a shared project — where multiple Terraform configurations live in the same project — it is an outage: tear down one stack and you disable an API that the other stacks, and possibly the whole org, still need.

Set disable_on_destroy = false in any project shared across stacks. A destroy then removes the API from that configuration's state without actually turning the service off, so other configurations keep working. This single flag is the difference between a clean teardown and a cross-stack incident.

disable_dependent_services

A second flag, disable_dependent_services, controls cascade behavior. Some APIs depend on others, and disabling one can require disabling its dependents too. Left at its default the provider refuses a disable that would orphan dependent services; set the flag and it cascades the disable down the dependency tree.

Understand the flag before enabling it. Turning on disable_dependent_services so a stubborn destroy succeeds can disable more than you bargained for — every service that depended on the one you removed. Combined with disable_on_destroy = false in shared projects, you mostly avoid touching this at all.