Developer self-service: automate actions inside policy boundaries
Design self-service infrastructure with server-enforced authorization, quotas and reliable retries. Follow a preview-environment request from form to cleanup.
TL;DR: Self-service delegates a defined operation with bounded resources. Authenticate and authorize it on the server, validate the requested destination and record a durable operation identity so retries cannot create duplicate infrastructure.
Define the action before building the form
A useful platform operation might create a preview environment for one repository, using an approved template and expiring after a specified interval. “Run arbitrary Terraform with the platform credential” delegates a much broader capability. Decide which resources and parameters the platform actually supports before exposing a button.
Backstage's Scaffolder authorization documentation distinguishes permissions around template content, actions and tasks. Hiding an input in the browser is not sufficient enforcement. The backend must reject the same unauthorized value if a caller submits it directly.
For an illustrative preview service, permit an authenticated team member to request a small namespace for a repository that team owns. The request can choose an approved size class and lifetime. It cannot choose a production account, arbitrary execution role or unrestricted network policy.
Carry identity to the policy decision
The API's identity and the provisioning worker's identity serve different purposes. The first establishes who requested the action. The second grants only the permissions needed to execute that approved action. Keep the requesting principal in the audit record even when a shared worker performs the cloud API calls.
Authorization must include the destination. A caller allowed to create a preview for repository A should not gain access to repository B by modifying a hidden parameter. Cloud IAM evaluation supplies another enforcement layer, but the platform still needs application-level ownership and quota decisions.
Handle two simultaneous requests correctly
Suppose a team has a quota of four environments and currently owns three. Two engineers submit requests at the same moment. Both requests read “three active,” both pass a naive check and both create an environment. The team now has five.
Reserve capacity atomically with the operation record, or use another concurrency-safe admission mechanism. Treat provisioning, failure and cleanup as state transitions that update the reservation. A worker crash after cloud creation should not leave an untracked environment or free the quota while the resource still exists.
| Situation | Required behavior | Evidence retained |
|---|---|---|
| Browser retries after a timeout | Return the existing operation for the same request identity | Stable operation ID |
| Two requests compete for final quota slot | Admit at most one reservation | Atomic admission result |
| Cloud create succeeds, worker crashes before acknowledgment | Reconcile by operation/resource identity | Resource tags and durable state |
| Provisioning fails halfway | Report partial state and schedule cleanup | Created resource identifiers |
| Expiry arrives during an active extension request | Resolve the state transition consistently | Authorized expiry change |
An idempotency contract makes repeated submission safe. A generated display name alone is a weak contract if the cloud provider allows several resources with that name.
Make the supported path observable
Give the developer a status that reflects actual progress: accepted, provisioning, ready, failed with cleanup pending, or deleted. “Request accepted” should not appear as “environment ready” while the worker is still creating resources. Include the current failure and a safe retry action when the platform can recover without duplicating work.
For the preview example, readiness means the environment can receive the intended deployment and pass its minimal health check. A namespace object existing in the API is only an intermediate condition. Link the resulting environment to its service catalog record, owner and expiry so operators can identify forgotten resources.
Keep an exception path for legitimate requirements outside the template. Google's SRE engagement model is useful context for balancing standardized support with explicit responsibility. An exception should identify who operates the resulting infrastructure and when the platform will review it, rather than silently granting the broad worker credential to the requester.
Explain the controls as part of the product
A strong interview answer connects each restriction to an operational failure: destination authorization prevents cross-team access, quota reservations prevent oversubscription, and expiry reconciliation prevents abandoned cost. Developers should receive enough information to correct an input or find the right owner without seeing internal credential details.
Self-check: the form offers only a small environment size, but a direct API request can submit a larger instance type. Is the template enforcing the quota policy?
No. Validate an allowlisted size class on the server and derive the actual infrastructure parameters there. Recheck that the execution identity cannot provision outside the supported scope. The browser can help users choose valid inputs; the backend must enforce what is allowed.