# Azure deployment checklist (/deployments/full-deployment/azure-deployment-checklist)



## Azure deployment support [#azure-deployment-support]

Crucible supports Azure full deployments end to end. Once the customer approves the tenant, billing, security, and network boundaries, Crucible connects its Enterprise Application, creates or verifies the subscription, provisions the runtime and supporting infrastructure, deploys the project, and keeps the resulting status and URLs in Crucible.

```mermaid
flowchart TD
  subgraph azure [Customer Azure tenant]
    E[Enterprise Application] -->|creates or verifies| S[Subscription]
    S -->|hosts| D[Full deployment]
  end
  C[Crucible] -->|admin consent| E
```

The running Azure environment remains customer-owned. Revoking Crucible's permissions stops future management access without requiring the workload to move out of Azure.

## Azure setup path [#azure-setup-path]

<Steps>
  <Step>
    **Connect the Crucible Azure App**

    In **Organization Settings > Azure App**, an Entra administrator grants [Microsoft admin consent](https://learn.microsoft.com/en-us/entra/identity-platform/v2-admin-consent), which creates the Enterprise Application in the tenant.
  </Step>

  <Step>
    **Choose the billing boundary**

    Microsoft Customer Agreement (MCA) tenants choose an invoice section where Crucible can [create subscriptions](https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription), and assign the Enterprise Application the **Subscription creator** role on it. Enterprise Agreement (EA) and CSP tenants supply an existing subscription for Crucible to verify instead.
  </Step>

  <Step>
    **Approve deployment access**

    Grant the Enterprise Application the approved subscription and role-assignment scope it needs to create the environment resources and identities.
  </Step>

  <Step>
    **Settle the runtime decisions**

    Agree on region, recovery, network, egress, DNS, data residency, quotas, resource policy, support access, and release approvals using the table below before creating the full deployment.
  </Step>
</Steps>

<Accordions>
  <Accordion title="Under the hood: the Azure boundary">
    * Crucible stores tenant and application identifiers for the organization, not Azure user tokens.
    * The Enterprise Application object ID identifies the service principal that receives billing or subscription permissions.
    * The selected invoice-section resource ID becomes the billing scope for subscription creation.
    * A subscription ID supplied in the deployment's `cloud_account_id` is verified instead of creating a new one. The created or supplied subscription ID is stored on the full deployment.
  </Accordion>
</Accordions>

## Decisions before provisioning [#decisions-before-provisioning]

Name an owner and approved outcome for each decision. If an answer is not ready, record the approval path instead of treating the item as optional.

| Decision                       | Owner                     | Outcome                                                                                                                       |
| ------------------------------ | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| Billing and subscription model | Azure billing owner       | Agreement type (MCA or EA/CSP), the invoice section for MCA, or existing subscription IDs for EA/CSP, plus a lifecycle owner. |
| Enterprise Application access  | Entra administrator       | Admin consent, service-principal review, approved RBAC scope, and any time-bound controls.                                    |
| Region and recovery            | Platform lead             | Primary and recovery regions, data-residency constraints, quotas, and global-service restrictions.                            |
| Network and egress             | Network or security lead  | VNet topology, private access, outbound IPs, firewall controls, and external allowlists.                                      |
| Secrets and workload identity  | Security or identity lead | Key Vault ownership, workload identity, secret rotation, support access, and audit requirements.                              |
| DNS and release approval       | Delivery owner            | Domain owner, certificate path, release gates, acceptance tests, and named approvers.                                         |

## Network requirements [#network-requirements]

* **Private cluster access**: Define how deployment automation and support users reach the [private AKS API](https://learn.microsoft.com/en-us/azure/aks/private-clusters).
* **Controlled outbound egress**: Choose the [NAT Gateway](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-overview) or firewall path and the fixed source IPs required by dependent services.
* **Secrets and identity**: Approve workload identity, support access, secret rotation, and [Key Vault RBAC](https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide).
* **DNS ownership**: Name the domain owner and confirm [Azure DNS delegation](https://learn.microsoft.com/en-us/azure/dns/dns-delegate-domain-azure-dns), certificate, and validation requirements.

## Customer IT checklist [#customer-it-checklist]

* Confirm the Azure billing owner and agreement model. For MCA, name the invoice section. For EA/CSP, supply subscription IDs Crucible can verify.
* Confirm who approves the Crucible Enterprise Application and which security review applies.
* State the approved RBAC scope and any time-bound or approval-gated access rules.
* Provide region, recovery, VNet, private-access, firewall, egress, and allowlist requirements.
* Name the DNS, certificate, secrets, telemetry, logging, and support-access owners.