Infrastructure as Code

Customer-controlled Azure environments should be provisioned through reviewed, versioned infrastructure as code. A modular design makes security policy, naming, diagnostics, private networking, and environment differences repeatable.

Module Domains

A reference implementation commonly separates:

• identity and role assignments,
• virtual network, subnets, DNS, and network security,
• monitoring and diagnostics,
• container registry and application runtime,
• storage, databases, and search,
• Key Vault and keys,
• model and document-processing services,
• function and background workloads,
• private endpoints,
• alerting, backup, and production protection.

Dependency Order

Deploy foundation resources first, then managed data and platform services, compute workloads, private connectivity, and finally secret references and environment-specific configuration. Use module outputs rather than copying resource identifiers between files.

Safe Pipeline

• Pin and review infrastructure module changes.
• Validate syntax, policy, and a preview or what-if result before apply.
• Separate plan and production approval.
• Use workload identity or a narrowly scoped pipeline identity.
• Keep secret values out of templates and pipeline logs.
• Detect configuration drift.
• Retain deployment evidence and the exact commit or artifact version.
• Require an explicit rollback, forward-fix, or recovery plan for risky changes.
• Apply production deletion protection where supported and operationally appropriate.

Parameters

Parameterize environment, region, customer code, SKU, capacity, redundancy, network integration, identity groups, domains, and feature-specific resources. Do not use production defaults that silently deploy an insecure or oversized environment.

Detailed module names, resource identifiers, network ranges, and production parameter files belong in the controlled engineering repository, not public documentation.