Domain 1: Configure Processes and Communications
- Built-in process templates (Agile, Scrum, CMMI, Basic) cannot be edited directly; to customize work item types or states you must create an inherited process from the desired base, modify it, and switch projects to use the inherited process.
- Branch policies can require linked work items on pull requests, which blocks PR completion until at least one work item is associated, enforcing end-to-end traceability from requirement to code.
- Use the PR completion option (or a transition rule) to automatically move linked work items to Resolved/Closed when the PR merges, reducing manual board upkeep.
- The Predecessor/Successor link type models sequential dependencies (one item must finish before another starts) and is the correct choice for tracking cross-team blocking dependencies; visualize these on Delivery Plans.
- Delivery Plans is a built-in feature that overlays multiple teams' backlogs and iterations on a single timeline, giving leadership a consolidated cross-team view without leaving the project.
- Area paths separate work ownership across teams within one project, while iteration paths define sprints; a single project with multiple teams each owning an area path is the recommended scaling pattern over many small projects.
- Kanban boards support WIP limits per column and split columns (Doing/Done) so teams can track in-progress vs. ready-to-pull work within a single workflow stage.
- Azure Boards Analytics provides built-in lead time and cycle time charts, plus velocity, burndown, and cumulative flow diagram (CFD) widgets for dashboards.
- The Azure Boards app and Azure Pipelines app for Microsoft Teams let teams subscribe to work item updates and pipeline/deployment notifications directly in a Teams channel.
- Service hooks send Azure DevOps event data (build completed, work item changed, code pushed) to external systems and webhook endpoints for integration with third-party tools.
- Notification subscriptions exist at personal, team, and project/organization scopes; team subscriptions can be filtered (for example, build failures only on the main branch) while personal subscriptions handle individual interests.
- A code wiki is published from a Git repository in Azure Repos so documentation is versioned with code, whereas a project wiki is stored separately and edited in the portal.
- Deployment gates in release pipelines can call external systems (for example the ServiceNow Change Management extension) to require change-approval validation before a stage proceeds.
- Enabling Azure Boards-to-Azure Pipelines integration surfaces deployment status on work items, and linking commits and PRs to work items completes traceability from requirement through code to release.
Domain 2: Design and Implement Source Control
- Trunk-based development uses short-lived feature branches (typically 1-3 days) merged frequently into main, minimizing merge conflicts and best supporting continuous deployment at scale.
- GitHub Flow branches features directly off main and merges back via PR, suiting continuous delivery; Gitflow (main, develop, feature, release, hotfix) suits scheduled releases with parallel maintenance.
- For a hotfix in Gitflow, branch from main, apply the fix, then merge back into both main and develop so the fix is not lost in the next release.
- Rebase and fast-forward is the merge strategy that produces a strictly linear history with no merge commits; squash merge collapses a branch into a single commit on the target.
- To permanently purge a large or sensitive file from history you must rewrite history with git filter-repo (recommended) or BFG Repo Cleaner; a normal delete leaves the blob in every prior packfile.
- Git LFS requires a client-side tool installed locally; without it a clone fetches only LFS pointer files (metadata), not the actual binary content.
- For very large repos, reduce clone time and disk use with shallow clone (--depth 1), partial/blobless clone, or the Scalar tool, and store large binaries via Git LFS.
- Branch policies can require a minimum number of reviewers, optionally reset approval votes when new code is pushed, require build validation, require linked work items, and require all PR comments to be resolved before completion.
- Blocking force pushes and history rewriting on a protected branch is done through branch security/permissions settings (deny Force Push), not through a branch policy toggle.
- Automatic reviewers can be added by branch policy using path filters so changes under a specific service directory require the owning team's review.
- Enforce signed commits by adding a build validation pipeline that verifies GPG signatures on incoming commits, since Azure Repos has no built-in signed-commit policy.
- A monorepo enables atomic cross-service commits and easier shared-code refactoring, but requires path filters and partial-clone strategies to manage build scope and clone size.
- Path filters in pipeline trigger configuration (paths: include/exclude) limit CI runs to changes in specific directories, essential for monorepos and per-service pipelines.
- git-tfs (and git-tf) provide a two-way bridge that migrates TFVC repositories to Git while preserving full history, the recommended tool for TFVC-to-Git migrations.
Domain 3: Design and Implement Build and Release Pipelines
- In YAML triggers, the correct keyword is paths with include/exclude lists (for example src/api/*); it is not files, and include selects the directories that activate CI.
- The variables section can mix entry types only when written as a YAML sequence: a '- group: name' entry imports a variable group and a '- name:/value:' entry defines an inline variable.
- Manual approval before production is implemented with environment approvals and checks on an Azure DevOps environment targeted by the deployment job, not with a task inside the job.
- Deployment strategies in deployment jobs include runOnce, rolling (with maxParallel, e.g. 25% to update 25% of targets at a time), and canary; canary shifts traffic incrementally while monitoring.
- Cache@2 is the built-in caching task; for NuGet, key it on the hash of packages.lock.json and point path at the packages folder so the cache is reused only when dependencies are unchanged.
- Publish and consume build outputs across stages with PublishPipelineArtifact@1 and DownloadPipelineArtifact@2, or the YAML shortcut keywords 'publish' and 'download'.
- Authenticate to Azure Container Registry with a Docker Registry service connection backed by a service principal or managed identity holding AcrPush/AcrPull roles, so no credentials sit in YAML.
- Reuse YAML templates across repos with the resources: repositories section to reference the template repo, then template:...@alias to include a template from it.
- Required templates enforced via the 'extends' keyword plus pipeline settings guarantee every pipeline inherits approved stages, steps, and security controls.
- Azure App Service slot swap promotes a fully warmed staging slot into production with near-zero downtime and supports instant rollback by swapping back.
- Container jobs run pipeline steps inside a specified Docker image, isolating tool versions and dependencies from the agent host.
- Azure Artifacts uses views (@Release, @Prerelease) to promote packages through quality stages and upstream sources to proxy and cache packages from public feeds like nuget.org and npmjs.com.
- Mark sensitive values as secret variables in the pipeline or variable group so they are masked in logs; secret variables are not automatically mapped into script environments and must be passed explicitly.
- Deploy to Kubernetes with the Kubernetes manifest task (canary strategy with SMI-based traffic splitting) or HelmDeploy@0 using the 'upgrade' command and a Kubernetes service connection.
Domain 4: Develop a Security and Compliance Plan
- Access Key Vault secrets without hardcoding credentials by using the AzureKeyVault task (or a variable group linked to Key Vault) over an ARM service connection authenticated by a managed identity or service principal.
- Variable groups linked to Azure Key Vault retrieve secret values at runtime; the values are never stored in the pipeline definition and are automatically masked in logs.
- Prefer workload identity federation over long-lived client secrets for ARM service connections, eliminating secret rotation and the risk of leaked credentials.
- Apply least privilege to service connections: scope the service principal's role (for example Contributor) to a single resource group, not the whole subscription.
- Restrict a service connection to authorized pipelines via pipeline permissions so other pipelines cannot use it to reach protected resources.
- GitHub Advanced Security for Azure DevOps provides secret scanning (leaked credentials), dependency scanning (vulnerable open-source packages), and CodeQL code scanning, all integrated into the DevOps experience.
- Microsoft Defender for DevOps surfaces DevOps security posture and integrates GitHub Advanced Security findings; Defender for Containers scans images in the pipeline before push to the registry.
- Map security testing to the right stage: SAST analyzes source code without running it during build, DAST attacks the running app in a deployed environment, and SCA (npm audit, Snyk) scans dependencies in the PR/build.
- Catch secrets earliest with a pre-commit hook (for example detect-secrets) on developer workstations; add a credential scanner (CredScan or GHAzDO secret scanning) as a server-side/PR check for defense in depth.
- Harden the software supply chain by pinning task versions to a specific major.minor.patch rather than @latest, and by verifying checksums or signatures of downloaded tools and dependencies.
- Self-hosted agents on Azure VMs can use a system-assigned or user-assigned managed identity to authenticate to Azure resources without storing credentials; Microsoft-hosted agents cannot use a VM managed identity.
- Enforce production governance with required (extends) templates plus environment approvals and checks, so production pipelines must extend an approved, security-reviewed template.
- Azure DevOps organization audit logs record permission changes, pipeline modifications, and access to sensitive resources, and can be streamed to Azure Monitor or Microsoft Sentinel for centralized compliance and SIEM analysis.
- Trace a deployment for compliance by correlating organization audit logs with pipeline run details and environment deployment history, which together show who deployed what, when, and with what approvals.
Domain 5: Implement an Instrumentation Strategy
- Azure Application Insights is the APM service for distributed tracing across microservices, using correlation IDs and the W3C Trace Context standard to follow a request end to end.
- Use the Application Insights SDK methods TrackMetric() for custom numeric business metrics and TrackEvent() for custom events such as feature usage.
- Auto-instrumentation enables Application Insights monitoring without code changes for supported platforms (for example App Service, Functions), while custom telemetry captures app-specific signals.
- Availability tests (URL ping tests and multi-step web tests) provide synthetic monitoring from multiple global locations to validate uptime and responsiveness.
- Azure Monitor supports metric alerts (static or dynamic thresholds on a metric, for example average server response time > 2s over a 5-minute window) and log alerts (KQL queries against logs).
- Action groups define notification and automation channels including email, SMS, voice, push, webhooks, Azure Functions, Logic Apps, and ITSM connectors, and are reused across multiple alert rules.
- Release annotations created by the pipeline on deployment appear on Application Insights charts so you can visually correlate a performance change with a specific release.
- Smart Detection automatically analyzes Application Insights telemetry and alerts on failure anomalies and performance degradation (for example slow response times) without manual rule configuration.
- Strip sensitive data before it reaches Application Insights with a telemetry initializer or telemetry processor that scrubs or drops fields client-side.
- Add feature-flag state, environment, or version as custom dimensions via a telemetry initializer to slice telemetry and compare behavior across flag states.
- Kusto Query Language (KQL) is the query language for Azure Monitor Log Analytics, used to analyze logs and to drive log-based alerts and workbook visualizations.
- Azure Monitor workbooks build rich, interactive dashboards that combine metrics and KQL log queries from many resources into a single consolidated, real-time view.
- For AKS, enable Container Insights to collect node/container performance, logs, and inventory, and Application Insights for application-level distributed tracing.
- Health monitoring layers a centralized health-check endpoint that aggregates downstream dependency status with Kubernetes liveness and readiness probes on each microservice.
AZ-400 exam tips
- Expect heavy emphasis on Azure DevOps services (Boards, Repos, Pipelines, Artifacts) plus GitHub equivalents; when a question gives requirements like 'minimal effort', 'least privilege', or 'no hardcoded credentials', let those constraints eliminate distractors.
- Know the YAML pipeline schema cold: triggers and path filters, stages/jobs/steps, deployment jobs and strategies (runOnce, rolling, canary), environments with approvals and checks, variable groups vs inline variables, and templates with extends/resources:repositories.
- Distinguish branch policies (require reviewers, build validation, linked work items, comment resolution, merge strategy) from branch security/permissions (block force push); a few questions hinge on this exact split.
- For security questions, default to managed identity or workload identity federation over secrets, scope service connections to the smallest resource and authorized pipelines, and place SAST/SCA in build and DAST against a deployed environment.
- Practice with multi-answer 'select all that apply' and YAML/code drag-and-drop style items, and budget time for one or two case studies; read every requirement before choosing, because partial solutions are common wrong answers.
Study guide FAQ
What are the prerequisites for AZ-400?
Microsoft recommends that you first earn either the Azure Administrator Associate (AZ-104) or Azure Developer Associate (AZ-204) certification, and that you have practical experience working with both Azure administration and development, plus DevOps processes across the full delivery lifecycle. The associate cert is no longer a hard gate to register, but the exam assumes that level of Azure knowledge.
What score do I need and how is the exam structured?
You need a scaled score of 700 out of 1000 to pass. You get 120 minutes and typically 40-60 questions across the five skill areas, including multiple choice, multiple-response 'select all that apply', drag-and-drop ordering, YAML/code completion, and occasionally a case study. The five domains are roughly equally weighted.
Does AZ-400 cover GitHub as well as Azure DevOps?
Yes. The exam tests both Azure DevOps Services and GitHub, including GitHub Actions, GitHub Advanced Security, and GitHub repositories, and frequently asks you to map an Azure DevOps concept to its GitHub equivalent. Study branch protection, Actions workflows, and Advanced Security alongside their Azure Pipelines and Azure Repos counterparts.
How long is the certification valid and how do I renew it?
Microsoft role-based certifications are valid for one year. You renew for free during the six months before expiration by passing a short, unproctored online assessment in Microsoft Learn, with no need to retake the full proctored exam.