App Configuration & Automated Deployment
Azure App Configuration, feature flags, and IaC with ARM/Bicep — design configuration management and deployment pipelines that enable safe, repeatable releases.
Configuration and deployment design
Configuration is the knobs and dials of your application. Connection strings, feature toggles, environment-specific settings. Azure App Configuration centralises these so you don’t scatter settings across app code, environment variables, and Key Vault.
Deployment automation means your infrastructure and applications are deployed by code (IaC), not by clicking buttons. ARM templates, Bicep, Terraform, and CI/CD pipelines make deployments repeatable, auditable, and safe.
Azure App Configuration
| Feature | Description |
|---|---|
| Key-value store | Centralised settings for all apps and environments |
| Labels | Same key, different values per environment (dev/staging/prod) |
| Feature flags | Toggle features on/off without redeployment |
| Key Vault references | Reference secrets in Key Vault — App Config stores the reference, not the secret |
| Sentinel key | Watch a single key for changes — triggers config refresh in connected apps |
| Snapshots | Point-in-time snapshots of configuration for rollback |
🚀 Marcus’s config design: NovaSaaS uses App Configuration as the single source of truth:
- Labels:
dev,staging,prod— same keys, environment-specific values - Feature flags: New features rolled out to 10% of tenants, then 50%, then 100%
- Key Vault references: Connection strings stored in Key Vault, referenced from App Config
- Sentinel key:
AppConfig:Version— when changed, all apps refresh their configuration
Infrastructure as Code
| Factor | ARM Templates | Bicep | Terraform |
|---|---|---|---|
| Language | JSON (verbose) | DSL (clean, readable) | HCL (HashiCorp) |
| Azure-native | Yes — first-party | Yes — compiles to ARM | No — multi-cloud |
| State management | Azure handles (deployment history) | Azure handles (compiles to ARM) | State file (local/remote) |
| Multi-cloud | No — Azure only | No — Azure only | Yes — AWS, GCP, Azure |
| Modules/reuse | Linked templates (complex) | Modules (simple) | Modules (mature ecosystem) |
| What-if/plan | Yes (what-if) | Yes (what-if) | Yes (plan) |
| Best for | Legacy templates, complex nested deployments | New Azure deployments, ARM migration | Multi-cloud, existing Terraform investment |
Exam tip: Bicep is the recommended Azure IaC tool
Microsoft recommends Bicep for new Azure IaC projects. It compiles to ARM JSON, so there’s no risk — it’s syntactic sugar over ARM templates. If the exam asks about “Azure-native IaC” or “infrastructure as code for Azure,” Bicep is the expected answer unless the scenario mentions multi-cloud (then Terraform).
Deployment patterns
| Pattern | How It Works | Risk | Best For |
|---|---|---|---|
| Blue-Green | Deploy to inactive slot, swap when validated | Low — instant rollback by swapping back | Web apps with App Service deployment slots |
| Canary | Route small % of traffic to new version | Low — limited blast radius | APIs, microservices with traffic splitting |
| Ring-based | Deploy to ring 0 (team) → ring 1 (early adopters) → ring 2 (all) | Lowest — progressive exposure | Large-scale services, multi-tenant SaaS |
| Rolling | Update instances in batches | Medium — mixed versions during rollout | VMSS, AKS rolling updates |
🏛️ David’s deployment discipline: CloudPath Advisory requires:
- All infrastructure defined in Bicep — no portal clicking for production
- GitHub Actions pipelines — automated lint → validate → what-if → deploy
- Blue-green deployments for App Service — swap slots after smoke test
- Ring-based for multi-tenant updates — internal users first, then pilot tenants, then all
Knowledge check
🚀 Marcus wants to release a new billing feature to 5% of NovaSaaS tenants first, then gradually expand to all tenants. The feature should be toggleable without redeployment. Which approach should he use?
🏛️ David's government client requires all infrastructure changes to be version-controlled, peer-reviewed, and deployed through an automated pipeline with no manual portal changes. Development, staging, and production must use identical configurations. Which approach should David recommend?
Next up: Moving to the cloud — Migration Strategy & Assessment.