Azure AZ-400 common mistakes
Azure AZ-400 · Understand the traps and how to avoid them.
Designs the Azure Boards hierarchy by copying a textbook Agile model instead of mapping the organization's teams, area paths, iteration paths, and delivery plans to the reporting and communication needs stated in the scenario.
The exam tests scenario-based process design, but candidates often memorize framework names and never practice translating team structure into board configuration, so they choose a familiar model rather than the one that satisfies autonomy, cadence, and reporting requirements.
What to do instead
Practice creating a small Azure DevOps project: define teams, configure area and iteration paths, build a delivery plan and dashboard, and justify each choice against team topology, release cadence, and stakeholder reporting. Know when one team project is enough versus when multiple projects are justified.
Treats stakeholder communication as an after-the-fact status email and ignores built-in notifications, service hooks, wikis, and dashboard widgets when designing the process.
Candidates focus on work item tracking mechanics and overlook that the domain explicitly includes communications; they do not practice designing event-driven notifications or documenting decisions where stakeholders can find them.
What to do instead
Build an event-to-channel matrix: map work item changes, pull request updates, build/release failures, and approval requests to Azure Boards notifications, service hooks, Teams or Slack channels, dashboards, and wiki pages. Include controls to avoid notification fatigue.
Selects a branching strategy by personal preference, such as always choosing trunk-based development or always choosing GitFlow, without tying the choice to release cadence, team size, compliance requirements, or external contributor model.
Candidates memorize strategy names but do not practice comparing trade-offs; exam scenarios often include long-lived releases, regulated approvals, or open-source forks that make a generic answer wrong.
What to do instead
Create a decision matrix for trunk-based, feature-branch, release-branch, and fork-based workflows. For each, state when it fits, how hotfixes work, how releases are tagged, and what merge or rebase policy is needed. Practice justifying the choice from stated constraints.
Configures branch policies only on the main branch and forgets path filters, build validation, status checks, required reviewers, merge strategy restrictions, and fork pull request security.
Candidates know that branch policies exist but have not configured them in a repository with multiple folders, external contributors, or different validation needs; they miss policy scope and enforcement details.
What to do instead
Practice configuring branch policies for main and release branches: required reviewers, build validation with path filters, status checks, comment resolution, merge type restrictions, and auto-complete. Test a fork-based pull request to see which policies and secrets are exposed.
Writes multi-stage YAML using only stage, job, and step syntax but cannot explain template expressions, runtime variables, dependsOn, conditions, deployment jobs, or environment approvals.
Candidates read pipeline examples but do not build a pipeline that uses reusable templates, conditional execution, variable scoping, and environment-based deployment controls; they then confuse compile-time and runtime behavior under exam pressure.
What to do instead
Build a multi-stage YAML pipeline with a reusable stage template, variable groups, conditional jobs, deployment jobs targeting environments, and approval checks. Practice tracing when a variable is expanded and how dependsOn and conditions interact.
Publishes build output as loose workspace files or assumes classic release UI behavior instead of producing immutable, versioned artifacts and consuming them through deployment jobs.
Candidates underestimate artifact immutability and environment deployment controls; they have not practiced the publish/download artifact flow, package feeds, deployment jobs, gates, and rollback, so they pick release designs that cannot be audited or repeated.
What to do instead
Practice publishing a versioned artifact from a build stage, downloading it in a deployment stage, deploying through an environment with approvals or gates, and rolling back by redeploying a known artifact version. Compare pipeline artifacts, build artifacts, and package feeds.
Equates pipeline security with storing secrets in variable groups and ignores service connection scoping, agent pool permissions, repository permissions, branch policies, and separation of duties.
Candidates focus on the most visible secret-handling feature and miss the broader identity and authorization model; they do not practice reviewing who can edit pipelines, run builds, or use a service connection.
What to do instead
Map a threat model to Azure DevOps controls: least-privilege service connections, scoped variable groups backed by Key Vault, restricted agent pools, protected branches, environment approvals, and audit logging. Practice checking effective permissions for a pipeline and a human operator.
Designs a compliance plan as a list of tools without mapping each control to evidence, such as audit logs, retention settings, approval trails, code scanning, dependency scanning, infrastructure-as-code scanning, and access reviews.
Candidates memorize security product names but do not connect controls to the evidence an auditor or responder would need; they also confuse platform features such as Azure Policy, Defender for Cloud, and repository scanning.
What to do instead
Build a control-to-evidence table for a sample project: branch policy approval records, pipeline approval logs, retention and audit settings, CodeQL or dependency scan results, IaC scan results, SBOM, and access review cadence. State which system produces each evidence item.
Uses Application Insights and Log Analytics interchangeably and cannot choose the right signal, such as metrics, logs, traces, or availability tests, or write a KQL query for a stated monitoring scenario.
Candidates know the product names but have not practiced instrumenting an application and querying telemetry; they miss how correlation, sampling, alert rules, action groups, and workbooks fit together.
What to do instead
Instrument a sample app with Application Insights, generate requests and failures, write KQL queries for failures by operation and dependency, create a metric or log alert with an action group, and configure an availability test. Practice explaining when to use each signal.
Monitors application health but not delivery health: no deployment markers, release annotations, pipeline failure alerts, or feedback loop from production incidents back to work items.
Candidates treat instrumentation as only application performance monitoring and forget that the domain includes pipeline and release observability; they do not practice connecting telemetry to deployment events and backlog items.
What to do instead
Add deployment annotations or release markers to telemetry, configure alerts for pipeline and release failures, and design a feedback loop that creates or updates work items from production alerts. Practice correlating a production error with the deployment that introduced it.