I passed AZ-400 last month on my second attempt, and honestly, the first attempt failed for dumb reasons that had nothing to do with my actual DevOps skills. I've been running CI/CD pipelines professionally for four years. I know what a blue-green deployment is. I've debugged a broken YAML pipeline at 2 AM more times than I'd like to admit. None of that saved me the first time, because AZ-400 doesn't test whether you can do DevOps — it tests whether you know the specific Microsoft-flavored way of describing DevOps.
So here's the list I wish someone had handed me before I booked my first attempt. If you're a developer or DevOps engineer eyeing this cert, run through a free AZ-400 practice test before you even open a study guide. It'll show you the gap between "I do this at work" and "I can answer a scenario question about this" faster than any course will.
1. You need AZ-104 or AZ-204 first, and it's not just a formality
Microsoft requires you to hold either AZ-104 (Administrator) or AZ-204 (Developer) before AZ-400 counts toward the Expert certification. I already had AZ-204, so I assumed the prerequisite was pure paperwork. It's not. AZ-400 leans hard on the assumption that you already know Azure resource management, RBAC, and basic App Service or AKS concepts cold. If your AZ-204 knowledge is a year stale, spend a weekend refreshing it before you touch AZ-400 material. I got burned on a question about managed identities that I would've nailed six months earlier.
2. Git branching strategy questions are more opinionated than real life
In my day job, we use trunk-based development with short-lived feature branches and nobody argues about it. AZ-400 wants you to know the tradeoffs between GitFlow, GitHub Flow, trunk-based development, and release branching — including scenarios where the "correct" answer is the one that minimizes merge conflicts for a specific team size, not the one your team actually uses. I got two questions comparing branch policies (build validation, required reviewers, path filters) and had to reason through them like a consultant, not a practitioner. Know when you'd recommend each strategy, not just how to execute the one you use.
3. IaC questions assume you've touched at least two tools
I write Bicep every week. I have touched Terraform exactly twice. That was a mistake. The exam expects familiarity with ARM templates, Bicep, and Terraform at a conceptual level — state management, idempotency, module structure, and how each integrates into a pipeline. You don't need to write Terraform HCL from memory, but you do need to know why someone would choose it over Bicep (multi-cloud support, mature module ecosystem) and what a Terraform state file actually does. Skipping this because "my company only uses Bicep" cost me points.
4. Configuration management is the domain everyone forgets to study
Ansible, Chef, Puppet, DSC — this whole area gets maybe 10-15% of the exam weight, and it's the section every developer I talked to skipped because "we don't use that stuff." I skipped it too, the first time. Big mistake. You don't need deployment-level expertise, but you need to recognize what each tool is for, the difference between push and pull configuration models, and how Azure Automation State Configuration fits in. Give this domain two focused study sessions minimum, even if it feels irrelevant to your stack.
5. Secure pipeline questions are really about shifting left
The security domain isn't abstract "best practices" fluff — it's specific: SAST vs. DAST vs. dependency/container scanning, where each tool slots into a pipeline (pre-commit, build, release), secret scanning with GitHub Advanced Security or Azure DevOps equivalents, and how to gate a release on scan results without turning your pipeline into a five-hour bottleneck. I underestimated how deep this went. There were questions asking me to sequence security checks across a multi-stage pipeline, and "shift left" isn't just a buzzword on this exam — it's a scoring criterion.
6. Observability means more than "I set up Application Insights once"
I've wired up Application Insights on maybe a dozen projects, so I walked in confident about this domain. The exam goes further than basic instrumentation — it wants you to reason about Log Analytics workspaces, Kusto queries (basic ones, not expert-level), alert rules tied to release gates, and how Azure Monitor feeds back into your release pipeline as an automated approval or rollback trigger. Study the release gate mechanics specifically. I lost points not knowing how to wire a post-deployment health check into an automatic rollback.
7. The exam format punishes people who skim case studies
AZ-400 runs roughly 40-60 questions in 150-180 minutes, costs around $165, and needs a 700 to pass. Some of those questions come attached to a case study — a couple paragraphs describing a fictional company's current pipeline, team structure, and constraints — and multiple questions reference the same case study. Skim the case study once, and you'll misread a constraint (like "the team cannot approve deployments manually" or "the company is required to use on-premises source control") and get three questions wrong instead of one. Read it slowly. Take notes if you can on the scratch pad they give you.
Bonus: the exam rewards "boring" answers more than clever ones
One pattern I noticed too late — when a question offers a clever, custom-scripted solution alongside a plain, built-in Azure DevOps or GitHub Actions feature, the built-in feature is almost always the intended answer. I kept picking the option that showed off more engineering effort because that's what I'd do at work to look good in a code review. The exam isn't grading creativity, it's grading whether you know the platform-native way to solve a problem with the least custom code. Once I recalibrated toward "what's the boring, supported, first-party way to do this," my accuracy on scenario questions jumped noticeably.
What actually got me from 690 to a pass
The second time around, I stopped rewatching video courses and just drilled scenario questions daily for two weeks, reading the explanation on every single one — right or wrong. Video content teaches you facts; questions teach you the pattern-matching the exam actually rewards. I also started timing myself, since 150-180 minutes for 40-60 questions sounds generous until you're three case studies deep and re-reading a constraint for the third time.
If you want the full skills outline before you commit to a date, the AZ-400 exam page on ExamCert lays out the current domain weightings, which changed slightly from what I'd studied the first time around — worth double-checking before you lock in a test date.
DevOps engineers tend to walk into this exam overconfident because we live this stuff daily. That's exactly why it's worth taking seriously. Real-world scattershot experience across a handful of tools isn't the same as broad, exam-ready knowledge across all of them. Book the retake if you need it — I did, and the second attempt felt like an entirely different, much fairer exam once I knew what it was actually asking for.
Top comments (0)