AZ-400 DevOps Engineer Expert
Final Exam Attack Plan
Your complete, high-detail, single-source study system to pass the AZ-400. Designed for fast recall under time pressure and deep understanding when questions are tricky.
Typical exam profile: 40–60 questions · 100–120 minutes · Mix of single-choice, multi-select, drag-and-drop, and case studies · Passing threshold approximately 70%.
Practical pass target: Aim for 80% in practice mocks so you have a safety margin on exam day.
Pace model for 60 questions in 120 minutes: 2 minutes average per question · First pass target: all questions answered by minute 90 · Review buffer: 30 minutes for flagged questions.
Spending more than 3 minutes on a single uncertain question in the first pass.
Hard rule: if not resolved after 2 minutes and you are down to two options, pick the more automated/conservative answer, flag the question, and move on.
Weight-driven study priority order:
If you have limited revision time: 35% effort on D1 CI · 20% on D2 deployment strategies · 20% on D3 source + D4 security · 15% on D6 SRE + D7 collaboration · 10% on D5 instrumentation.
Spending equal revision time across all domains. Domain 1 is worth 2–3× more than Domain 6.
3.1 The Four Unbreakable Rules
Burn these into memory — they eliminate wrong answers instantly:
- Build once, promote one immutable artefact. Never rebuild per environment.
- Shift security left. Scan at PR time. Never only at release.
- Retrieve secrets at runtime from Key Vault. Never store in YAML, plaintext, or repo files.
- Automate rollback. Never rely on manual intervention as the primary rollback plan.
"Rebuild the artefact for each environment to ensure it matches config." — Wrong: one artefact, all environments.
"Run the security scan after deployment to production." — Wrong: scan at PR time.
3.2 Deployment Strategy Core Map
Memorise exactly:
| Strategy | Use When |
|---|---|
| Blue/Green | Instant rollback required |
| Canary | Progressive, risk-controlled rollout |
| Ring-based | User-cohort staged exposure |
| Rolling | No-downtime, no dual environment |
| Feature flags | Decouple deployment from release |
Scenario says "instant rollback" → Blue/Green · "gradual rollout to 5% of users" → Canary · "internal users first, then preview, then GA" → Ring-based · "enable feature for select users without redeploying" → Feature flags.
"Blue/green requires only one environment." — False: it requires two active environments (blue and green).
What deployment strategy is correct when the exam says "instant rollback with zero downtime"?
3.3 YAML Template Types
Know when to use each template type:
- Step template: Reuse a shared sequence of steps (e.g., a shared code-coverage publish step)
- Job template: Standardise an entire job definition across repositories
- Stage template: Replicate a complete deployment stage with parameters
- Variable template: Share variables across pipelines without duplication
Template files live in a separate shared pipeline repository. Referenced with template: and resources: repository block.
A team has a security-scan step used in 15 service pipelines. What template type should they use?
3.4 Branching Strategy Decision
The only two answers the exam tests:
- Trunk-based: high-frequency delivery (multiple deploys per day), short feature branches, strong PR gates
- GitFlow: low-frequency delivery, versioned enterprise releases, explicit release branches
Exam scenario says "multiple deploys per day" or "cloud-native SaaS" → Trunk-based · "quarterly releases" or "major version management" → GitFlow.
"Trunk-based development does not require PR gates." — False: gates are mandatory or quality collapses.
3.5 Security Scan Placement
The shift-left sequence:
Any scan that can run at PR time should run at PR time. DAST can only run on a deployed, running application — earliest is post-deploy to test environment.
"SAST requires a running application." — False: SAST is static, runs on source code without execution.
When does DAST first become possible in the pipeline?
3.6 SRE Core Sequence
The chain: SLI → SLO → Error Budget → Release/Reliability Decision
- SLI: The measurement (e.g., request success rate)
- SLO: The target (e.g., 99.9% success rate over 30 days)
- SLA: The customer promise — always set below the SLO
- Error budget: Available failure headroom =
(1 − SLO) × period - High burn: consuming budget faster than sustainable → freeze releases, fix reliability
- Low burn: budget intact → safe to increase release velocity
Error budget formula:
"SLO is 99.9%. 90% of error budget consumed in 15 days." → Burning at ~1.8× sustainable rate → Answer: freeze risky releases, prioritise reliability work.
"The SLA should be higher than the SLO." — False: SLA must always be at or below the SLO.
3.7 Azure Key Vault Integration Patterns
The three pipeline patterns:
- Variable group linked to Key Vault: secrets appear as pipeline variables at runtime, never logged
- Managed identity + Key Vault reference in app settings: zero credential handling in code
- Key Vault reference in App Service/Function settings:
@Microsoft.KeyVault(...)syntax
"Service principal with a client secret stored in an env file is acceptable." — Never: this creates a secret-in-file anti-pattern.
3.8 Azure Boards Hierarchy
The Scrum template hierarchy:
"Large multi-month strategic goal" → Epic · "User-facing deliverable within a sprint" → User Story · "Defect found during testing" → Bug.
"Features are at the sprint level." — False: features span multiple sprints. User stories fit within a sprint.
3.9 Application Insights vs Azure Monitor
| Capability | Tool |
|---|---|
| Request rate, failure rate, response time | Application Insights |
| Distributed tracing across microservices | Application Insights |
| Availability tests (external probes) | Application Insights |
| Custom events from application code | Application Insights |
| VM CPU, memory, disk metrics | Azure Monitor |
| Platform-level metrics (scale sets, storage) | Azure Monitor |
| Log Analytics KQL queries | Azure Monitor (Log Analytics) |
| Alert rules with action groups | Azure Monitor |
| Workbooks | Azure Monitor |
"Azure Monitor handles distributed tracing for a microservices application." — False: Application Insights handles distributed tracing.
3.10 Agent Selection
| Scenario | Agent Type |
|---|---|
| Private network access required | Self-hosted |
| Custom tools that take too long to install each build | Self-hosted |
| Standard public build with no private network needs | Microsoft-hosted |
| Cost-sensitive, low-frequency builds | Microsoft-hosted |
"Microsoft-hosted agents can access on-premises SQL Server without configuration." — False: they only reach public internet endpoints.
Domain 1 — CI (20–25%)
Build once, promote immutable artefact — appears in ~30% of Domain 1 questions.
YAML template type selection — step vs job vs stage — appears frequently.
Quality gates: fail pipeline on critical CVE, test pass threshold, coverage minimum.
PR build validation trigger — build must pass before merge is permitted.
Caching by lockfile hash to improve build speed and reproducibility.
Domain 2 — CD (10–15%)
Deployment strategy selection — appears in most Domain 2 questions.
Blue/green specifics: dual environment, traffic switch, instant rollback.
Canary specifics: percentage traffic, SLI-gated progression, rollback on threshold breach.
Release gates: query Azure Monitor or Work Items before proceeding.
Domain 3 — Source Control (10–15%)
Trunk-based vs GitFlow decision — the most-tested Domain 3 topic.
PR governance requirements: build validation, minimum reviewers, work item link.
Monorepo when a team owns tightly coupled services. Multi-repo for independent services.
Domain 4 — Security (10–15%)
Shift-left: SAST and SCA at PR time — always.
Key Vault for all secrets, always — no exceptions.
DAST: earliest feasible point is post-deploy to test environment (requires running app).
Managed identity: eliminates credential handling entirely.
Domain 5 — Instrumentation (5–10%)
Application Insights distributed tracing for microservices.
KQL: Log Analytics query language — know basic filter, project, summarize patterns.
Availability tests: external probes to verify endpoint is reachable from multiple regions.
Domain 6 — SRE (5–10%)
Error budget formula and burn rate decision — appears in every SRE question.
High burn = freeze releases. Low burn = increase velocity.
Toil = manual, repetitive, scalable work that must be automated.
Chaos engineering: inject controlled failures to validate resilience.
Domain 7 — Collaboration (10–15%)
Epic → Feature → User Story → Task hierarchy — tested frequently.
Sprint Review (demo to stakeholders) vs Sprint Retrospective (team improvement). These are different ceremonies.
Kanban = continuous flow. Scrum = time-boxed sprints. Correct answer depends on scenario context.
Definition of Done: agreed criteria for calling a user story complete.
Pipeline Answer Selection
Apply in order when a question is about pipeline design:
- Does it involve secrets? → Key Vault variable group answer wins.
- Does it involve security scanning? → Shift-left answer wins.
- Does it involve artefact handling? → Build-once answer wins.
- Does it involve environment promotion? → Approval gate + health probe answer wins.
Deployment Strategy Selection
Apply in order:
- "Instant rollback" in scenario → Blue/Green
- "Gradual" or "percentage" in scenario → Canary
- "Cohort" or "insider ring" in scenario → Ring-based
- "Toggle without redeploy" in scenario → Feature flags
- "No dual environment" in scenario → Rolling
SRE Error Budget Decision
Apply in order:
- Calculate error budget if not given:
(1 − SLO) × period - Burn rate > 1× and budget at risk → freeze risky releases, fix reliability
- Burn rate < 0.5× and budget intact → increase release velocity
- If SLA > SLO in a question → always wrong: SLA must be ≤ SLO
Security Scan Timing
Apply in order:
- Secret detection → pre-commit or PR (earliest possible)
- SAST → PR validation build
- SCA → PR validation build
- IaC scan → PR validation build (alongside SAST)
- Container scan → before push to registry
- DAST → post-deploy to test environment (requires running app)
48 hours before exam: Complete one full timed mock. Note every wrong answer. For each wrong answer: write why the correct answer is correct in one sentence. No new topics after this point.
24 hours before exam: Read all [!!!] markers from memory. Review the deployment strategy table. Review the SRE chain. Stop heavy study by evening.
Morning of exam: Skim the four unbreakable rules. Skim the deployment strategy table. Skim SLI → SLO → Error Budget chain. Log in with 10 minutes to spare.
During the exam: First question — breathe, read the full scenario before looking at answers. Uncertain between two? Apply the hierarchy: automate > shift-left > immutable > Key Vault > low blast radius. Flag difficult questions and return in the review buffer.
Read the question. Cover the answer. Only reveal when you have committed to an answer mentally.