AZ-400 DevOps Engineer Expert

Exam Crash Course

Three-part intensive. All seven exam domains. The critical decision maps, exam-day cheats, five hard scenario questions, and the ten must-memorise rules to pass.

7 domains covered 3 parts 5 hard scenario questions 10 cheats to memorise cold

Domain 1: Continuous Integration — The Highest-Weight Domain

[MUST]

Build once, promote one immutable artefact. The same binary — no rebuild — travels from CI through staging to production. Any answer suggesting "rebuild for each environment" is wrong.

[MUST]

YAML template types: Step template = reuse steps · Job template = reuse job definitions · Stage template = reuse full deployment stages · Variable template = share variable sets.

[TRAP]

Templates live in a separate shared repository. They cannot be shared cross-repo from the same pipeline file.

[MUST]

Quality gates must fail the pipeline. Warn-only gates are anti-patterns. A test failure, a coverage miss, or a critical CVE must block the merge — not just generate a report.

Domain 2: Continuous Delivery — Strategy Map

Scenario keyword	Strategy	Key property
Instant rollback / zero downtime	Blue/Green	Two environments, traffic switch
Gradual / percentage of users	Canary	SLI-gated progressive exposure
Cohort / insider ring / staged	Ring-based	User group sequencing
Toggle feature without redeploy	Feature flags	Decoupled release
No dual environment / rolling update	Rolling	In-place sequential update

[TRAP]

Blue/green needs two identical environments simultaneously. Not one. And rollback is a traffic switch — no redeploy required.

[TRAP]

Canary progression must be based on telemetry thresholds — not calendar time or team availability.

Domain 3: Source Control — The Two-Answer Domain

Scenario	Branching model
Multiple deploys per day, cloud-native SaaS, high frequency	Trunk-based
Quarterly releases, versioned enterprise product, major versions	GitFlow

[MUST]

Trunk-based still requires PR gates. Short-lived branches + mandatory build validation + minimum reviewers. "No gates" in trunk-based is wrong.

[MUST]

PR governance requirements: mandatory build validation + minimum reviewer count + required comment resolution + work item link.

Domain 4: Security and Compliance — Shift Everything Left

Timeline of scan types: Pre-commit (optional) → PR build: SAST + SCA + IaC scan → Post-merge: container scan → Test env deploy: DAST → Release gate: compliance evidence

[MUST]

SAST = static analysis of source code. No running app needed. Runs at PR time.

[MUST]

DAST = dynamic analysis against a running app. First possible point: after deployment to test environment.

[MUST]

SCA = dependency/CVE scanning. Runs at PR time. Critical CVE = fail the build.

[MUST]

All secrets come from Key Vault. Variable group with Key Vault backing = the canonical pipeline answer. Secrets in YAML, env files, wikis, or plaintext variables are always wrong.

[TRAP]

Visibility-only scans (warn but never fail) = DevSecOps anti-pattern. Security gates must have teeth.

Domain 5: Instrumentation Strategy

You need to…	Use
Trace a request across microservices	Application Insights (distributed tracing)
Monitor availability from external locations	Application Insights (availability tests)
Track custom application events	Application Insights (custom events)
Monitor VM CPU / memory / disk	Azure Monitor (platform metrics)
Query logs with KQL	Log Analytics workspace (Azure Monitor)
Create alert rules and action groups	Azure Monitor
Mark deployments on metric charts	Release annotations (App Insights or Azure Monitor)

[TRAP]

"Azure Monitor handles distributed tracing." Wrong — that is Application Insights.

[MUST]

Alert quality principle: alerts should be SLO-linked and fire only when user impact is at genuine risk. Threshold-based alerts on raw metrics produce noise. More alerts ≠ better monitoring.

[MUST]

Release annotations are the fastest way to correlate a deployment to an incident. Place them at every deployment in every environment.

Domain 6: SRE Strategy — The Budget Model

The SRE chain: SLI (measure) → SLO (target) → Error Budget (headroom) → Decision Error budget formula: Budget = (1 − SLO) × period 99.9% SLO over 30 days = 0.001 × 43,200 min = 43.2 minutes/month 99.95% SLO over 30 days = 0.0005 × 43,200 min = 21.6 minutes/month

Budget state	Team action
Burn rate > 1× sustainable — budget at risk	Freeze risky releases. Fix reliability first.
Burn rate < 0.5× — budget healthy	Safe to increase release velocity.
Budget depleted before period end	All feature work stops. Reliability sprint only.

[TRAP]

"SLA should be higher than SLO." Always wrong: SLA ≤ SLO. The SLA is the customer-facing commitment; the SLO is the internal target. The SLO must be harder to maintain than the SLA.

[MUST]

Toil = manual, repetitive work that scales with system load and must be automated. MTTR = Mean Time to Restore. CFR = Change Failure Rate. Both are DORA metrics.

[MUST]

Post-incident review: blameless · structured · produces tracked corrective actions with named owners and due dates in the backlog.

Domain 7: Communication and Collaboration

[MUST]

Azure Boards hierarchy (Scrum): Epic → Feature → User Story → Task / Bug. Epic = multi-month goal. Feature = spans sprints. Story = fits in a sprint. Task = sub-unit of work.

Ceremony	Purpose	Who attends
Sprint Review	Demo completed work to stakeholders. Inspect the product increment.	Team + stakeholders
Sprint Retrospective	Inspect and improve the team process. What to start/stop/continue.	Team only
Daily Standup	Yesterday / today / blockers. Time-boxed to 15 minutes.	Development team
Sprint Planning	Select and decompose backlog items into the sprint.	Team + Product Owner

[TRAP]

Sprint Review ≠ Sprint Retrospective. Review = what was built. Retro = how to improve. These appear in the exam as a deliberate confusion trap.

[MUST]

DORA metrics for leadership dashboards: Deployment Frequency · Lead Time for Changes · Change Failure Rate (CFR) · Mean Time to Restore (MTTR).

[MUST]

Traceability chain: Work item → Commit → Build → Artefact → Release. Every layer must be linked. This chain enables incident investigation, compliance evidence, and release audit.

Five Hard Scenario Questions

Click "Show answer" after committing to a choice. These represent the highest-difficulty question types on the AZ-400.

SCENARIO Q1 — Domain 4 + Domain 1

A pipeline runs a SAST scan and a SCA dependency check on every pull request. A new junior developer asks: "Can we skip these in dev branches to speed up development?" What is the correct response and reasoning?

No. Security scans must run on every branch and every PR — including dev branches. The purpose of shift-left is to catch vulnerabilities at the earliest possible point. A vulnerability introduced in a dev branch and caught early costs minutes to fix. The same vulnerability in production costs hours of incident response, potential data exposure, and reputational damage. Allowing bypasses in any branch defeats the security control entirely.

SCENARIO Q2 — Domain 6 (SRE)

Your service SLO is 99.95% over a 30-day period. After 10 days, the team has already consumed 80% of the error budget. A new feature release is scheduled for tomorrow. What should the team do?

Calculate the burn rate: 80% of budget consumed in 10 of 30 days = consuming at 2.4× the sustainable rate. The error budget is at high risk of full depletion before the month ends. The team must: (1) cancel or defer the new feature release, (2) initiate a reliability sprint focused on root cause analysis and fixes, and (3) not restore velocity until the burn rate drops to sustainable. Deploying new features while burning at 2.4× is a guaranteed SLO breach.

SCENARIO Q3 — Domain 2 (CD)

A canary release is at 15% traffic. Technical SLIs (latency, error rate, availability) are all passing. However, the business intelligence team reports that conversion rates dropped 8% in the canary cohort. What is the correct action?

Pause the canary and investigate. Technical health metrics passing does not mean the release is safe — business KPIs are equally valid canary gate criteria. An 8% conversion drop is a user experience regression that technical metrics may not capture. The correct design is to: (1) pause the rollout immediately, (2) investigate whether the feature change caused the conversion regression, and (3) redesign the release gate to include business KPIs (conversion rate, revenue per session) alongside technical SLIs.

SCENARIO Q4 — Domain 4 (Security)

An auditor asks for proof that production deployment X was formally approved by the correct approver and that no single person both submitted and approved the release. Which Azure DevOps capability provides this evidence, and what data does it contain?

Azure DevOps environment approval policies generate immutable pipeline run records containing: the approver's Microsoft Entra ID identity (named user, not a shared account), the timestamp of approval, the approval decision (approved/rejected), the specific pipeline run ID, and the release version. Segregation of duties is enforced by configuring the policy to exclude the deployment requestor from the approver list — this is policy-enforced, not advisory. The audit log is system-generated and cannot be altered retroactively.

SCENARIO Q5 — Domain 1 + Domain 3

A platform team manages 40 service repositories. They update a shared YAML step template with a breaking change that renames a required parameter. Three service pipelines fail immediately after the update. What structural practice would have prevented this, and what should the team implement going forward?

The missing practice is semantic versioning combined with pre-production validation. The team should: (1) pin all template references to a specific major.minor version (e.g., @v1) so breaking changes in a new version do not auto-propagate; (2) validate template changes in a dedicated pre-production pipeline that tests all consuming pipelines before publishing the new version; (3) use semantic versioning — increment the major version (v2.0) for breaking changes, allowing teams to adopt deliberately. Unversioned shared templates where any change is immediately live to all consumers is the root cause pattern to eliminate.

Ten Exam-Day Cheats — Memorise Cold

These rules consistently select the correct answer when two options look equally valid.

CHEAT 01

Automated gate beats manual check. Every time.

CHEAT 02

Shift left beats scan at release. If it can run at PR time, it should.

CHEAT 03

Immutable artefact. One build. Never rebuild per environment.

CHEAT 04

Key Vault. Always. Secrets never in YAML, repos, wikis, or plaintext.

CHEAT 05

"Instant rollback" = Blue/Green. Never canary for instant rollback.

CHEAT 06

High error budget burn = freeze releases + reliability sprint. Not "monitor it".

CHEAT 07

SLA ≤ SLO. Always. SLA is customer promise; SLO is internal target.

CHEAT 08

DAST needs a running app. Earliest: post-deploy to test environment.

CHEAT 09

Multiple deploys per day = trunk-based. Quarterly versioned = GitFlow.

CHEAT 10

Sprint Review = demo to stakeholders. Sprint Retro = team improvement. Not the same ceremony.

Exam Question Type Tactics

[MUST]

Scenario questions: Read the full scenario before looking at options. Identify the core requirement in the last sentence. Options are written to distract — the correct answer resolves the core requirement with the best governance and safety.

[MUST]

Multi-select questions: The question will specify "choose two" or "select all that apply". Do not over-select. Partial credit may not apply — select exactly as many as specified.

[MUST]

Two valid-looking options: Apply the elimination hierarchy → automate > shift-left > immutable artefact > Key Vault > least privilege > rollback-safe. The option satisfying more of these wins.

[TRAP]

Do not choose an answer because it uses newer service names (e.g., "GitHub Actions" vs "Azure Pipelines"). The AZ-400 tests the principle, not brand preference. Both are equivalent in exam context.