Infrastructure as Code

Replaced ad-hoc CLI scripts with a modular Bicep stack orchestrated by main.bicep. A bootstrap shell script handles pre-flight work that Bicep cannot — resource group creation, Key Vault secret seeding, and subnet delegation — then hands off to Bicep for all infrastructure resources. Every deploy is idempotent; --what-if runs before every apply.

using 'main.bicep'

param adminPassword = az.getSecret(
  '343a8a7e-...',
  'rg-az104-dev-wus3-01',
  'kv-az104-dev-wus3-01',
  'vm-admin-password'
)

param tags = {
  env: 'dev'
  owner: 'geoste'
  managed-by: 'bicep'
}

• Bootstrap + Bicep split — Bootstrap handles what Bicep cannot: RG creation (Bicep can't create its own target RG), KV secret seeding, subnet delegation flags. Bicep owns all infrastructure resources.
• Secrets via getSecret(), never in templates — .bicepparam resolves secrets from Key Vault at deploy time. Credentials never appear in template files, parameter files, or CLI args.
• Policy-enforced tag inheritance — require-tag-env and require-tag-owner deny assignments on the RG. inherit-tag-* policies push tags from RG to all child resources automatically. Manual tagging is inconsistent and breaks.
• Bastion condition flag — deployBastionHost bool parameter controls whether the host deploys. Standard SKU costs ~$140/mo; delete between lab phases.
• guid() with stable inputs — Role assignment names use guid() seeded with static param values, not module outputs. Module outputs aren't known at deployment start.

Built a complete container delivery pipeline: images built and pushed to Azure Container Registry, deployed via Bicep to an internal Container Apps Environment on a delegated /23 subnet. Two image versions deployed simultaneously with an 80/20 traffic split — demonstrating blue/green rollout patterns without downtime. Scale-to-zero configured with minReplicas: 0.

az containerapp ingress traffic set \
  --name ca-dev-wus3-01 \
  --resource-group rg-az104-dev-wus3-01 \
  --revision-weight \
    latest=80 \
    ca-dev-wus3-01--v1=20

Container Apps Environment sits on snet-capp-dev-wus3-01 (10.0.8.0/23, delegated to Microsoft.App/environments). Internal ingress only — no public endpoint. ACR admin access disabled; all pulls use AcrPull role on the managed identity.

• activeRevisionsMode: Multiple — required for traffic splitting between revisions. Single mode replaces the active revision on every deploy — no split possible.
• minReplicas: 0 — scale to zero when idle. First request cold-starts in seconds. Eliminates compute cost during inactive periods.
• Traffic weights via CLI, not Bicep — revision names are auto-generated at deploy time and unknown to Bicep. Set weights post-deploy via CLI; attempting to set them in Bicep requires hardcoding revision names that don't exist yet.
• User-assigned MI preferred over system-assigned — system-assigned identity only exists after the Container App is created, creating a role-assignment timing window. User-assigned MI is created as infrastructure ahead of time with AcrPull pre-assigned.

Deployed Key Vault with RBAC authorization model, assigned system-managed identities to both VM and App Service, and wired App Service configuration to pull secrets via KV reference strings — no credentials stored anywhere in code or config. Diagnostic logs routed to Log Analytics; KQL queries used to audit every secret access event.

@Microsoft.KeyVault(
  VaultName=kv-az104-dev-wus3-01;
  SecretName=vm-admin-password
)

AzureDiagnostics
| where ResourceType == "VAULTS"
| where OperationName == "SecretGet"
| project TimeGenerated,
          CallerIPAddress,
          OperationName,
          ResultType
| order by TimeGenerated desc

• RBAC model, never Access Policies — KV created with --enable-rbac-authorization true. Access Policies are deprecated for new vaults. RBAC provides per-secret granularity with full audit trail in Entra ID.
• Two separate access grants required — (1) creator needs Key Vault Secrets Officer to write secrets; (2) ARM needs --enabled-for-template-deployment true to resolve getSecret() in Bicep. Neither is implied by the other.
• System-assigned MI at creation time — --assign-identity "[system]" passed during resource creation. Post-creation assignment introduces a timing window where RBAC assignment may fail before the identity GUID propagates in Entra ID.
• KV reference strings — use Cloud Shell — The @ and parentheses in KV reference values cause PowerShell parsing failures even inside quotes. Always use Cloud Shell Bash for az webapp config appsettings set with KV references.

The capstone project is this site. A production-grade Azure stack deployed entirely via Bicep: Front Door with WAF policy, Static Web App with GitHub Actions CI/CD, Key Vault, storage account for static assets, and Log Analytics with Application Insights. Custom domain ostebovik.net with managed TLS certificate — all provisioned from a single az deployment group create command.

az deployment group create \
  --resource-group rg-geoste-prod-wus3-01 \
  --template-file main.bicep \
  --parameters prod.bicepparam \
  --what-if

• Front Door as perimeter, not App Gateway — Front Door operates at the edge (global CDN + WAF), appropriate for a static site with no backend compute. App Gateway sits inside a VNet and is designed for internal load balancing — wrong tool at this scale.
• SWA serves from GitHub, not storage — Static Web App requires content in a GitHub repo; Storage Account holds referenced assets (diagrams, screenshots). Push to main → GitHub Action → deployed in under 60 seconds.
• GitHub Actions workflow created manually — skipGithubActionWorkflowGeneration: false requires Azure write access to the repo at deploy time. If not granted, the workflow file is never auto-generated. Added manually to .github/workflows/ with deployment token in repo secrets.
• Managed TLS certificate — certificateType: 'ManagedCertificate' on the Front Door custom domain. Free, auto-renewed — no certificate management overhead.