Project Service Enablement
What does zop.dev create for 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.
| Field | Value |
|---|---|
| Cloud | gcp |
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
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.