Provisioning

Provisioning creates the compute, database, storage, secrets, ingress, identity, and telemetry a workload needs. It may run as one workflow or as requests to several teams.

Queue effects

An internal tool may need a runtime, database, secret, and hostname. When each dependency has its own queue, a small application crosses several forms and teams.

Long provisioning lead times change team behaviour. Teams batch requests, ask for more capacity than they need, or use infrastructure they already control. These responses make inventory and capacity harder to manage.

Self-service provisioning

A single workflow can produce a running application with its dependencies attached. It also provides one place to maintain the approved defaults.

• Put backup policy, encryption, network placement, log retention, and tags in the template so each request receives the defaults.
• Give the workload its own identity at creation so secrets and data access can be scoped to it. Retire shared workload accounts from the template.
• Provide a self-service teardown that includes each dependent resource and protects data that has a separate retention requirement.
• Keep the configuration in version control so the environment can be reconstructed outside the console.

Short-lived environments

AI work can produce many short-lived environments, including experiments, demos, per-branch previews, and agent sandboxes. When creation is expensive, teams keep them longer and may leave production data in undocumented infrastructure.

Set an expiry when short-lived environments are created. This reduces abandoned infrastructure and the data copies it holds.

Quotas and approvals

For routine requests, a quota lets teams operate within an approved capacity. Review is then reserved for increases beyond that limit.

Quotas also produce a demand signal. Repeated increases from one team show where the approved capacity is too low.

Use approvals for production data access, public exposure, and spend above a defined threshold.