AZ-305
Deep Dive
Designing the application layer: correctly sizing App Service, applying the cloud patterns the exam references (retry, circuit breaker, CQRS, strangler fig), and externalizing configuration, state and cache.
Contents
| Tier | Provides | When |
|---|---|---|
| Free / Shared | Shared compute, no SLA nor custom domain SSL | Testing |
| Basic | Dedicated compute, custom domains, manual scale to 3 | Dev/test and small apps |
| Standard | Autoscale (10), slots (5), daily backups | General production |
| Premium v3/v4 | More slots (20), 30 instances, VNet integration, zone redundancy, better hardware | Demanding production; "VNet integration" or "zone redundancy" → minimum Premium |
| Isolated v2 (ASE v3) | App Service Environment: deployed INTO your VNet, single-tenant, up to 100 instances | Total network isolation/compliance — the signal is "fully isolated in the VNet" |
Deployment slots
App Service networking
| Pattern | Problem it solves | In Azure |
|---|---|---|
| Retry with backoff | Transient network/service failures | Azure SDKs include it; Polly in .NET |
| Circuit Breaker | Don't hammer a downed service; fail fast | App logic / API Management |
| Queue-Based Load Leveling | Spikes that overwhelm the backend — a queue absorbs the load | Service Bus / Storage Queues between web and worker |
| Competing Consumers | Process the queue in parallel by scaling workers | Functions/Container Apps scaling by queue length |
| CQRS | Separate read and write models so each can scale independently | Writes to SQL, reads from replicas/cache/Cosmos |
| Event Sourcing | Full history as a sequence of events | Cosmos change feed / Event Hubs |
| Saga | Distributed transactions across microservices (compensation) | Durable Functions, Service Bus |
| Strangler Fig | Migrate a monolith incrementally, route by route | API Management / App Gateway routing between legacy and new |
| Sidecar / Ambassador | Cross-cutting functionality alongside the container | Dapr in Container Apps / AKS |
| Cache-Aside | Relieve the DB with a read cache | Azure Cache for Redis |
Typical signals
"Order spikes overwhelm the backend" → queue between layers (load leveling). "Migrate the monolith gradually with no big bang" → strangler fig. "Reads outnumber writes 100:1" → CQRS + cache/replicas.
App Configuration
Key Vault
External state
| Layer | Service | Caches |
|---|---|---|
| Data | Azure Cache for Redis | Query results, sessions, hot objects (cache-aside) |
| Global edge | Front Door (+CDN) | Static and dynamic content accelerated at global POPs |
| API | API Management (cache policy) | API responses by key/parameters |
| Static | Static blob + CDN/Front Door | SPA, images, downloads |
| Tool | When |
|---|---|
| Azure DevOps (Pipelines) | Enterprise CI/CD: build → test → release with approvals, gates and environments. Integrates with Azure Repos, GitHub or any git repo |
| GitHub Actions | Native GitHub workflows: YAML workflows in the repo, actions marketplace, OIDC integration for secret-free credentials |
| Azure Deployment Environments | Provision full environments (IaC templates) on demand for dev/test — self-service with central governance |
| Deployment slots (App Service) | Blue/green with no downtime inside App Service — swap between staging and production with prior warmup |
| Bicep / Terraform (IaC) | Declarative, version-controlled infrastructure in the repo — a prerequisite for repeatable, reviewable deployments |
| GitOps + Flux/ArgoCD (AKS) | The cluster reconciles its state against the git repo — configuration changes = a PR, not manual commands |
Exam signals
"Deploy to multiple environments with manual approval before production" → Azure Pipelines with gates/environments. "The team already uses GitHub" → GitHub Actions. "Repeatable IaC with no drift between environments" → Bicep/Terraform in a pipeline. "AKS clusters with no manual commands" → GitOps.
| Requirement | Design |
|---|---|
| Deploy with no downtime and immediate rollback | Deployment slots + swap |
| The app reaches a private SQL instance in the VNet | Regional VNet integration (Premium) |
| The app is only accessible from the private network | Private Endpoint (+ disable public access) |
| Single-tenant App Service fully inside your VNet | ASE v3 (Isolated v2) |
| Only accept traffic coming from Front Door | Access restrictions (service tag + X-Azure-FDID header) |
| Traffic spikes overwhelm order processing | Queue (Service Bus) + scaling workers (load leveling) |
| Feature flags and central config across multiple apps | Azure App Configuration |
| Incremental monolith migration | Strangler fig with APIM/App Gateway in front |
| User sessions when scaling horizontally | Redis as a session store (stateless app) |
| CI/CD with manual approval before production | Azure DevOps Pipelines (environments + approvals) |
| Deployment flow native to the GitHub repo | GitHub Actions |
| On-demand dev/test environments with IaC | Azure Deployment Environments |
Did you get this topic?
Test what you just learned
A ticket-selling website collapses when popular tickets go on sale: the orders API receives 50x normal traffic and the database saturates, dropping orders. The business accepts that order confirmation may take a few extra seconds during spikes. What pattern do you apply?
Put what you learned to the test with original AZ-305 exam questions.
Start AZ-305 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.