Which platform operations should be self-service, and which should require review?
Show the full answer Hide the answer
The model
Boundaries defined in advance and enforced automatically; anything inside them is self-service; anything crossing them requires review.
Inside the boundary, self-service: provisioning a service from a template into an approved region with standard resource sizes, standard networking, standard data classification, and cost within a team's budget. No human involvement, minutes not weeks.
Crossing the boundary, review: a new data store type, a new external interface, regulated data crossing a boundary, an unapproved region, spend above a threshold, or a resource type not on the sanctioned list.
The trigger set should be published in advance, so teams know before they start rather than discovering governance as an ambush.
Why the alternatives fail
Review everything produces a queue that becomes the constraint on delivery, so teams route around it — and the organisation ends up with a rigorous process covering a fraction of the estate and no visibility into the rest. A lighter process covering everything provides more assurance than a rigorous one covering a third.
Self-service everything with detective controls generates findings faster than they can be remediated, because detection scales with headcount and creation scales with the estate. The backlog grows and the compliance position is defended by exception.
Self-service only in non-production means production remains a bottleneck, and the environments diverge — so the thing that was tested is not the thing that was deployed.
What makes the boundary work
- Preventive enforcement at the control plane, so the boundary cannot be crossed by any path including a console action.
- Attribution enforced at creation — untagged resources blocked — since without it nothing downstream is possible.
- Bounded review turnaround for the crossing cases, because unpredictable lead time causes routing around more than the review itself.
- An exception path with an owner, scope and expiry, since permanent exceptions become the architecture.