11.4 Application Configuration Management & Automated Deployment Design (App Configuration, DevOps Pipelines, Deployment Slots)

Why Configuration Management and Automated Deployment Matter on AZ-305

This section closes out the Design infrastructure solutions (30-35%) application-architecture subgroup by shifting from what services an application is built from to how that application's settings are managed and how new versions reach production safely. A recurring AZ-305 trap is confusing Azure Key Vault (covered earlier under identity and governance design: secrets, certificates, and cryptographic keys) with Azure App Configuration (general application settings and feature flags). The exam also expects fluency in deployment strategies — slot swaps, blue-green, canary, and rolling — matched to specific downtime and rollback requirements.

Core Concepts: Application Configuration Management

Azure App Configuration is a fully managed, centralized store for application settings and feature flags, distinct from both source control and Key Vault.

• Key-value pairs with labels: the same setting key can carry different values scoped by label — for example, one label per environment (Dev, Staging, Prod) or per deployment ring — avoiding the need for entirely separate configuration stores per environment.
• Feature management: feature flags let a team turn a feature on or off without redeploying code, and support percentage-based rollout and targeting filters (specific users or groups) as well as time-window filters that automatically enable or disable a feature on a schedule.
• Key Vault references: App Configuration stores only a reference (a pointer) to a secret that actually lives in Key Vault — never the secret value itself — so secrets remain centrally managed, rotated, and audited in Key Vault while still being retrievable through the same App Configuration client the application already uses for its other settings.
• Dynamic refresh without restart: application clients poll a designated sentinel key; when that key's value changes, the client library knows the rest of the configuration has changed and refreshes it, avoiding both a full application restart and a poll-storm against every individual key on every refresh cycle.
• Point-in-time snapshots and history: App Configuration retains configuration history so a team can roll back to a previously known-good configuration state after a bad change.
• Replicas: read replicas in additional regions improve resilience and latency for globally distributed applications without duplicating the write/management path.

Core Concepts: Automated Deployment

Azure Pipelines (or GitHub Actions) implement continuous integration (build and test) followed by continuous delivery/deployment (CD) as YAML-defined pipelines. Environments and approval gates control promotion between stages such as Dev, Test, and Production, and can include pre- or post-deployment checks — a work-item query, an automated health-check function call, or a manual sign-off — before a release advances.

Infrastructure as Code (IaC) — Bicep, ARM templates, or Terraform — describes target infrastructure declaratively so every environment is reproducible and configuration drift is detectable. AZ-305 expects IaC to be the recommended approach over manual portal changes for anything that must be repeatable across environments or disaster-recovery regions.

Deployment strategies:

• Deployment slots (App Service): a staging slot is a fully separate, independently addressable app instance. A swap exchanges the staging and production slots with near-zero downtime because the staging slot is already warmed up — there is no cold start. Sticky (slot-specific) app settings are explicitly marked so they do not move during a swap — the classic use case is a connection string, so the staging slot always points at a staging database even immediately after a swap, and production always points at production.
• Blue-green deployment: two complete, independent production environments; traffic is cut over to the new ("green") environment once validated, often implemented as a slot swap or via Front Door/Traffic Manager routing, with instant rollback available by reverting the cutover.
• Canary deployment: a small percentage of production traffic (for example, 5%) is routed to the new version first and gradually increased if the new version is healthy, minimizing blast radius compared to an all-at-once release. This requires infrastructure capable of weighted traffic splitting, such as Azure Front Door, Application Gateway, or App Service's own slot traffic-routing percentages.
• Rolling deployment: for Virtual Machine Scale Sets or AKS, instances or pods are updated in batches so the workload never drops to zero healthy capacity during the rollout.

Decision Framework

• Zero-downtime release for an App Service with instant rollback → deployment slots with swap.
• Minimize blast radius for a risky release across many backend instances → canary deployment via weighted routing.
• Need to change application behavior (a promotional banner, a discount campaign) without a redeploy → App Configuration feature flag with dynamic refresh via a sentinel key.
• Need a secret referenced from configuration but centrally managed and audited → App Configuration Key Vault reference, not a copy of the secret value in App Configuration itself.
• Need reproducible, versioned infrastructure across multiple environments or regions → Bicep or Terraform IaC in the deployment pipeline, not manual portal changes.

Exam Scenario

A retail web app's marketing team wants to enable a flash-sale banner instantly for 10% of users, then ramp to 100% if metrics look healthy, without any code deployment. Separately, engineering is concerned that the connection string that differs between the staging and production slots must never accidentally swap during the next slot swap. The correct combination is an App Configuration feature flag using a percentage/targeting filter for the banner (with dynamic refresh via the sentinel key so no restart is needed), and a sticky (slot-specific) app setting for the connection string so it remains correct for each slot after every swap.

A second scenario: a payments service must deploy a new version to a five-instance Virtual Machine Scale Set with zero moments of total unavailability, accepting a slower rollout in exchange for never dropping below partial capacity. The correct strategy is a rolling deployment, updating instances in batches, rather than a slot swap (which does not apply to VM Scale Sets) or an all-at-once blue-green cutover (which would briefly risk full exposure to an unhealthy new version).