# Project Service Enablement

> zop.dev manages Google Cloud API enablement through the project_service resource type, complementing the bootstrap module's fixed list of 11 core APIs. Enabling a service is free. The risk runs the other way: disabling one can break every resource that depends on it, immediately.

Source: https://zop.dev/integrations/provision/gcp/project-service-enablement
Updated: 2026-08-19

---

GCP features are gated behind per-project API enablement. zop.dev manages service enablement as a resource so a project's API surface is declarative and auditable.

## API enablement as the project_service type

Enablement of Google Cloud project services/APIs (resource type project_service).

## One service name per resource

```text
Service name to enable; the bootstrap module enables 11 core APIs by default.
```

## A complement to the bootstrap module's fixed list

Available through the cloud-resource-provisioner API, complementing the bootstrap module's fixed API list.

## Eleven APIs before anything runs

A fresh GCP project can do almost nothing, because every capability sits behind a per-project API
gate. The bootstrap module opens the 11 the platform needs (resource management, compute,
container, Cloud SQL, Secret Manager, Redis, DNS, service networking, certificates, and
friends), which is why provisioning works on a new project without a checklist of console
toggles. The `project_service` resource type covers everything past that fixed list: a team
adopting BigQuery, Vertex, or any other service enables it declaratively, and the project's
API surface stays a fact in configuration rather than an accumulation of one-time clicks.

## Disabling is the dangerous direction

Enablement is free and additive; disablement is where the sharp edge lives. Turning a service
off does not politely refuse new usage. It can immediately break every resource that
depends on the API, and dependencies are not always obvious (service networking, for one,
quietly underpins private database connectivity). An enabled-but-unused API costs nothing
and threatens nothing by itself; the reflex to "clean up" enabled services has a worse
risk-reward than almost any other cleanup. Treat disablement as a change-managed operation
with a dependency check, not hygiene.

## The API surface becomes auditable

The declarative shape earns its keep at review time. Which projects can spin up compute?
Which ever enabled a data-exfiltration-adjacent service? With enablement as managed
configuration, those are queries; with console-clicked enablement, they are archaeology.
The same property gives drift detection something to hold onto: an API enabled out-of-band
is a visible divergence from declared state, which is occasionally the first sign of
someone doing something a project was never meant for.