CertifyDeck
Start for free
All cheat sheets
AZ-400 · CHEAT SHEET

Microsoft Certified: DevOps Engineer Expert

Key concepts grouped by official exam weight.

Download as PDF (free, no sign-up)

1. Design and implement processes and communications

10–15%

Design and implement traceability and flow of work

  • GitHub flow is a lightweight branch-based workflow: create a descriptive branch, commit isolated changes, open a pull request (as a draft for early feedback), address review, merge and delete the branch. In Azure Repos, Microsoft recommends feature branches, pull requests with build validation and automatic reviewers on main, and release branches that are never merged back: fixes are ported with cherry-picks.
  • In GitHub, issue templates and forms (.github/ISSUE_TEMPLATE) structure reports, config.yml can hide blank issues, and sub-issues build hierarchies. Notifications reach the web inbox, mobile or email depending on whether you participate in or watch a repository. Azure DevOps delivers notifications by email or service hooks through personal, team, project or global subscriptions filtered by event.
  • GitHub Projects combines a table, board and roadmap synced with issues and pull requests; built-in workflows set Done on close or merge, and auto-add brings in new items that match a filter. Automating them from Actions needs a GitHub App or PAT, because GITHUB_TOKEN cannot access projects. Azure Boards connects to GitHub through its app and links commits, pull requests and issues with AB#ID.
  • Traceability ties requirements, code, builds, releases, tests and bugs together through link types such as Branch, Commit, Pull Request and Integrated in build. In Azure Pipelines you can link test results to requirements, create bugs from failed tests and trace the code change where a failure began. The Requirements quality widget summarizes quality per requirement, and AB# or Fixes #n connect GitHub code to work.

Design and implement appropriate metrics and queries for DevOps

  • Lead time runs from work item creation to a Completed state and cycle time from first entering In Progress to Completed; the Lead Time and Cycle Time widgets show a moving average and standard deviation, and the CFD reveals bottlenecks and excess WIP. For delivery, the Cloud Adoption Framework proposes Lead Time for Change, Deployment Frequency, Mean Time to Restore and Change Fail Percentage.
  • For planning, Azure Boards provides velocity (work completed per sprint, credited to the sprint where it finishes), the forecast tool, which uses that velocity to spread the backlog over future sprints, and Burndown and Burnup widgets that can span several teams and show scope increase. Queries use macros such as @CurrentIteration - 1, and GitHub Projects offers historical charts such as Burn up.
  • Development metrics measure code health and the flow of changes: diff coverage on Azure Repos pull requests (azurepipelines-coverage.yml, advisory unless a branch policy requires it), the Code Tile and Pull Request widgets, Pulse in GitHub, and GitHub Actions performance metrics. To relate work to GitHub code in queries, Azure Boards uses External Link Count.
  • Test metrics in Azure DevOps come from the results a pipeline publishes (for example with PublishTestResults@2). Test Analytics and the Test failures report show the top failing tests and pass-rate trends; flaky test management detects flaky tests and can exclude them from the summary. The Test Results Trend (Advanced), Chart for Test Plans and Requirements quality widgets bring this data to dashboards.
  • Security metrics come from the alerts raised by scanning tools. In GitHub, security overview offers Overview, Risk, Coverage and per-tool views, and code scanning and Dependabot alerts are filtered with expressions such as is:open or scope:development. GitHub Advanced Security for Azure DevOps provides Risk, Coverage and Alerts tabs for Azure Repos, and Defender for Cloud unifies Azure DevOps, GitHub and GitLab.

Configure collaboration and communication

  • The Azure DevOps wiki supports Markdown and Mermaid diagrams with the ::: mermaid container or a fenced mermaid block; flowcharts use graph, not flowchart. Tags such as [[_TOC_]] and [[_TOSP_]] generate indexes, and Publish code as wiki maps a repository branch and folder, ordered with .order files. GitHub renders Mermaid in fenced mermaid blocks.
  • On GitHub, automatically generated release notes include merged pull requests, contributors and a changelog link; .github/release.yml groups them by label and excludes labels or authors. API documentation in ASP.NET Core is generated as an OpenAPI document with Swashbuckle or NSwag and shown with Swagger UI.
  • Git provides commands to build documentation from history: git log with ranges such as v2.3.0..HEAD, --no-merges, --grep and --pretty=format creates changelogs; git shortlog -sn summarizes commits per author; git describe derives versions from the nearest annotated tag. The GitHub API generates release notes between two tags with the generate-notes endpoint.
  • Webhooks send events to an HTTPS endpoint. On GitHub, use a secret and validate the X-Hub-Signature-256 signature, respond with a 2XX quickly and use X-GitHub-Delivery against replays. Azure DevOps sends events through Web Hooks service hook subscriptions, and Azure Pipelines supports webhook resources with a secret-protected Incoming Webhook connection.
  • Azure Boards connects to GitHub repositories, preferably through the Azure Boards app. AB# mentions in commit messages and pull request descriptions link work items, and keywords such as Fixes transition them only when merged into the default branch. Status badges, branches created from work items and ! mentions of pull requests are also available.

2. Design and implement a source control strategy

10–15%

Design and implement branching strategies for the source code

  • Microsoft recommends a simple strategy: short-lived feature branches from main, merges through pull requests and an always-healthy main branch. Release branches are created from main, never merged back, and receive fixes through cherry-pick. Trunk-based development uses feature flags instead of long-running branches.
  • The pull request workflow is controlled with branch policies in Azure Repos (minimum reviewers, automatically included reviewers, build validation, linked work items, comment resolution and status checks) and with branch protection rules in GitHub (required reviews, code owners defined in CODEOWNERS, status checks and conversation resolution).
  • Merge restrictions limit how changes reach a branch. In Azure Repos, the Limit merge types policy allows only squash, rebase or basic merges, and bypass permissions, Force push and branch locks handle exceptions. In GitHub, branch protection requires linear history, a merge queue with the merge_group event, or restricts who can push.

Configure and manage repositories

  • Git works best with text files; large binaries that change often belong in Git LFS, which keeps pointers in the repo and the content in separate storage, while dependencies belong in package management. git lfs track adds the pattern to .gitattributes, which should be committed. Without the LFS client you only get pointers, and Azure Pipelines needs lfs: true on checkout.
  • Scalar optimizes Git for very large repositories: it configures partial clone, sparse-checkout, commit-graph, prefetch and background maintenance; scalar clone leaves only the top-level directory unless --full-clone is used. To share code across repositories use submodules (git submodule add) or a common package registry, and multiple checkout steps in Azure Pipelines.
  • In Azure Repos, permissions are set at All Repositories or per repository, which inherits from the project level unless inheritance is turned off; Deny generally overrides Allow. There are two bypass permissions: when completing pull requests and when pushing. In GitHub, repository roles go from Read to Triage, Write, Maintain and Admin.
  • Annotated tags (git tag -a or -s) store tagger, date and message and are meant for releases; lightweight tags are just a name and git describe ignores them by default. In Azure Repos the web portal creates only annotated tags and deleting requires Force push. In GitHub, tag rulesets restrict who can create or delete tags matching a pattern.
  • Git recovers data with specific commands: git reflog shows where HEAD and branches were in the local repository, git fsck --lost-found lists unreachable commits, and git checkout <sha>^ -- file restores a deleted file. git revert undoes shared changes without rewriting history. In Azure Repos, deleted branches are restored from the web portal, without their policies.

3. Design and implement build and release pipelines

50–55%

Design and implement a package management strategy

  • GitHub Packages hosts npm, RubyGems, Maven, Gradle, NuGet packages and container images next to the code, with integrated permissions and GITHUB_TOKEN in workflows. Azure Artifacts offers feeds with NuGet, npm, Python, Maven, Cargo and Universal Packages, views and upstream sources. Pipeline artifacts pass build outputs between stages, not package management.
  • An Azure Artifacts feed is project- or organization-scoped and has the @Local, @Prerelease and @Release views; packages are always published to @Local and then promoted, with no demotion. Upstream sources save packages from public registries into the feed and are searched in a defined order. Use a single feed per configuration file and least-privilege feed roles.
  • SemVer uses Major.Minor.Patch: major signals breaking changes, minor backward-compatible features and patch bug fixes; labels such as -beta mark prereleases. Date-based versions, such as vcpkg version-date (YYYY-MM-DD), fit libraries without release versions. NuGet version ranges and the Dependabot versioning-strategy option control which versions are accepted.
  • In Azure Pipelines the run name is set with name and tokens such as $(Date:yyyyMMdd) and $(Rev:r), which resets when the rest of the number changes; counter keeps a per-prefix counter for semantic versions. Pipeline artifacts are deleted with their run and consumed through pipeline resources. In GitHub Actions, retention-days sets how long an artifact is kept.

Design and implement a testing strategy for pipelines

  • In Azure Pipelines, approvals and checks (Branch control, Required template, Query Azure Monitor alerts, Business hours, Exclusive lock) are set by the resource owner and cannot be changed from YAML. In classic pipelines, gates are re-evaluated until all succeed in the same interval. In GitHub, environments use required reviewers, wait timers and deployment branch rules.
  • A DevOps test taxonomy classifies tests by dependencies: L0/L1 unit, L2 functional with SQL or files, L3 against a deployed service and L4 against production. Shift-left moves most tests to the lowest level and into the build. Load tests with Azure Load Testing run in the pipeline, with failureCriteria and autoStop in the YAML configuration file.
  • VSTest and the .NET Core task publish results to the Tests tab on their own; JUnit, NUnit, xUnit, CTest or TRX files from scripts need PublishTestResults@2, with options such as failTaskOnFailedTests. UI tests require agents running interactively, and VSTest can slice tests across agents. In GitHub Actions, results are uploaded with upload-artifact and if: always().
  • PublishCodeCoverageResults@2 publishes Cobertura, JaCoCo and other formats to the Code Coverage tab; on Linux, .NET uses Coverlet with XPlat Code Coverage. In Azure Repos, azurepipelines-coverage.yml sets the pull request diff coverage target, whose status blocks merges only when a branch policy requires it. In multistage pipelines, coverage appears once the whole pipeline completes.

Design and implement pipelines

  • Azure Pipelines builds GitHub, Azure Repos and other repositories, offers a classic editor, YAML stages, environments with deployment history and runOnce, rolling and canary strategies. GitHub Actions defines everything in YAML next to the code, selects runners by labels and connects to Azure with a service principal through azure/login or with a publish profile.
  • Microsoft-hosted agents and GitHub-hosted runners give a clean machine per job with no maintenance; self-hosted ones allow custom software and caches but must be maintained and should almost never serve public repositories. Agents and runners open outbound HTTPS connections themselves. Managed DevOps Pools and ephemeral runners make autoscaling easier.
  • Azure Pipelines accesses GitHub with the GitHub App (Azure Pipelines identity and GitHub Checks), OAuth or a personal access token. It supports CI, pull request and comment triggers (/azp run), and its status can be required on protected branches. Secrets are not passed to builds from forks by default.
  • In Azure Pipelines, trigger defines CI by branch, path and tag (trigger: none disables it and batch groups pushes), pr validates pull requests, schedules uses cron in UTC and pipeline resources chain pipelines. In GitHub Actions, on combines events such as push, pull_request, schedule, workflow_dispatch, workflow_run and merge_group with branch and path filters.
  • In Azure Pipelines, ${{ }} expressions are evaluated during template parsing and can use parameters, while $[ ] is evaluated at run time with no access to parameters. Includes templates insert content and extends templates enforce a security schema. In GitHub Actions, reusable workflows declare workflow_call and are called at job level with uses.

Design and implement deployments

  • Progressive exposure limits blast radius: canary sends a release to a small group and widens it; rings or tiers start with internal users and respect a bake time; blue-green keeps two identical environments and switches traffic after testing. Feature flags separate deployment from exposure, and variant flags enable A/B testing by percentile allocation.
  • In Azure Pipelines, stages run sequentially unless dependsOn is used, while jobs in a stage run in parallel unless they declare dependsOn; by default they continue only if dependencies succeeded. In GitHub Actions, needs orders jobs and skips dependents on failure. In Bicep, references and parent create implicit dependencies, and independent resources deploy in parallel.
  • In App Service, deploy to a staging slot and swap into production: the swap warms instances and is reversed by swapping again. Warm-up is tuned with WEBSITE_SWAP_WARMUP_PING_PATH and _STATUSES, and auto swap is not available on Linux or containers. Scale sets in rolling mode upgrade in batches using a health probe, and a rolling strategy with maxParallel keeps VMs serving.
  • In a release-branch flow, the fix goes into main first by pull request and is then cherry-picked into the release branch so it does not recur. Azure Repos Cherry-pick opens a new pull request with policies, and git cherry-pick -x records the source commit. Safe deployment guidance lets a Sev 0 fix go straight to the affected scale unit, while a Sev 1 fix passes through tier 0 first.
  • A resilient rollout stops as soon as a health signal fails: the Query Azure Monitor Alerts check blocks the next stage while alerts are active. retryCountOnTaskFailure retries tasks with transient errors, and on: failure runs rollback steps. Before a Bicep deployment, what-if previews the changes, and versioned artifacts, point-in-time restore and circuit breakers support recovery.

Design and implement infrastructure as code (IaC)

  • For operating system configuration as code across Azure and Arc-enabled servers, recommend Azure Machine Configuration, which replaces Automation State Configuration. Ansible uses YAML playbooks and dynamic inventory; Bicep and Terraform are declarative and idempotent; App Configuration centralizes application settings and Key Vault holds the secrets.
  • The Azure Pipelines tasks for App Configuration import key-values from files (with Dry Run, label and prefix) and export them as variables; Key Vault references resolve to secret variables. To combine labels, chain several export tasks. In ARM templates deployed in incremental mode, omitted properties revert to their default values.
  • An IaC strategy keeps templates in Git, reviews every change through pull requests and validates it before deployment: the Bicep linter (configured in bicepconfig.json) and what-if show what will be created, modified or deleted. Terraform state goes to Azure Storage, which locks the blob on every write.
  • Azure Machine Configuration applies OS configuration as code with the Audit, ApplyAndMonitor and ApplyAndAutoCorrect modes and needs the extension and a system-assigned identity on Azure VMs. Automation State Configuration offers a built-in DSC pull server but should be migrated. Bicep deployment stacks delete removed resources and block changes with deny settings.
  • Azure Deployment Environments lets developers create environments on demand from environment definitions (an IaC template plus environment.yaml) published in GitHub or Azure DevOps catalogs. Project environment types set the target subscription and the managed identity that deploys; developers need the Deployment Environments User role.

Maintain pipelines

  • In Azure Pipelines, the pass rate, duration and test failures reports show the top failing tasks, the slowest tasks and the problem tests. Flaky test management detects flaky tests through reruns or an API and can exclude them from the summary. In GitHub, Actions performance metrics show run times, queue times and failure rates.
  • To optimize pipelines: caching (Cache@2 in Azure Pipelines, actions/cache in GitHub) reuses dependencies through keys and restore keys; batch: true groups pushes made during a run; fetchDepth shortens checkout; timeoutInMinutes cancels hung jobs; and Managed DevOps Pools standby agents avoid provisioning waits.
  • In GitHub Actions, the concurrency key allows one in-progress run per group; cancel-in-progress cancels the earlier one, and the group should include github.workflow to avoid affecting other workflows. In Azure Pipelines, parallel jobs are shared across the organization, maxParallel limits matrices, and the exclusive lock with lockBehavior serializes deployments.
  • In Azure Pipelines run retention is configured only in project settings; to keep a specific run you mark it to be retained indefinitely or add a lease through the Lease API. That retention does not cover packages: Azure Artifacts has its own feed retention, and versions promoted to a view are exempt. In GitHub Actions, retention-days on upload-artifact sets the retention of a single artifact.
  • Only pipelines created with the classic build designer can be exported to YAML from the definition view; classic release pipelines are migrated task by task. After pasting the exported YAML you must redefine classic editor variables and review cron schedules, which use UTC in YAML. Deployment groups become environments, approvals and gates become checks, and task groups become templates.

4. Develop a security and compliance plan

10–15%

Design and implement authentication and authorization methods

  • Managed identities remove credential management. A system-assigned identity lives and dies with its resource and only that resource can use it; a user-assigned identity is a standalone resource that can be shared and can get role assignments before deployment. Outside Azure, as in GitHub Actions, you use an Entra application or a user-assigned identity with a federated credential.
  • The GITHUB_TOKEN is an installation token created for each job, limited to the repository and tuned with permissions; actions it performs do not trigger new runs except for listed events. GitHub Apps suit long-lived integrations: fine-grained permissions, short-lived tokens and no dependency on a user. Personal access tokens fit short scripts, with fine-grained tokens preferred.
  • Service connections use the Reader, User, Creator and Administrator roles, and each pipeline should be authorized individually instead of opening the connection to all pipelines. For Azure, workload identity federation is recommended. Azure DevOps PATs are a last resort: organization-scoped, minimal scopes, short lifetime; they never exceed the owner's permissions and regenerating one invalidates the old value.
  • GitHub repository roles go from least to most access: Read, Triage, Write, Maintain and Admin. Triage manages issues without write access, Maintain manages the repository without sensitive actions, and Admin controls branch protection, webhooks and deletion. At organization level there are predefined roles such as security manager, billing manager, moderator and GitHub App manager, and owners have full access.
  • In Azure DevOps permissions are assigned to security groups at organization, project or object scope, with the states Allow, Deny and Not set. At the same scope a Deny generally wins over an Allow, and an explicit assignment on a child node replaces the inherited one. Project Collection Administrators manage processes, policies and extensions; Project Administrators manage teams, paths and repositories.

Design and implement a strategy for managing sensitive information in automation

  • In Azure Pipelines, the AzureKeyVault@2 task downloads secrets as variables; RunAsPreJob makes them available to the whole job, and the identity needs Get and List on secrets. A variable group linked to Key Vault maps only secret names (not keys or certificates) and fetches the latest value on every run. In GitHub Actions, sign in with OIDC and mask the value with ::add-mask::.
  • Workload identity federation avoids stored secrets: Azure Pipelines recommends it for Azure Resource Manager service connections, and connections created automatically and used by a single project can be converted. In GitHub Actions, the job needs id-token: write and azure/login exchanges the OIDC token for a short-lived Azure token that is valid only for the job.
  • Azure Pipelines secure files (certificates, keystores, provisioning profiles, SSH keys) are stored encrypted, are a protected resource with pipeline permissions, approvals and checks, and can't be edited after upload. DownloadSecureFile@1 exposes the path as $(name.secureFilePath) and deletes the file when the job ends. In GitHub Actions, use Base64 secrets or gpg-encrypted files.
  • To prevent leaks, never print secrets or pass them on the command line: map them to environment variables and don't use structured data as a secret, because redaction relies on exact matches. Secrets don't reach fork builds and, in GitHub, aren't passed automatically to reusable workflows. Pin actions to a full commit SHA and use intermediate environment variables against script injection.

Automate security and compliance scanning

  • A scanning strategy combines secret scanning (full history plus push protection), CodeQL code scanning, dependency scanning and license control. In GitHub, Dependabot alerts find vulnerable dependencies on the default branch, and the dependency review action blocks pull requests that add vulnerable packages or disallowed licenses (allow-licenses or deny-licenses).
  • Defender for Cloud DevOps security connects Azure DevOps, GitHub and GitLab through connectors and centralizes code, secret, dependency and IaC findings. The Microsoft Security DevOps extension and action run analyzers such as Bandit, Checkov, Template Analyzer and Trivy; in Azure DevOps, SARIF files are published to the CodeAnalysisLogs artifact. Pull request annotations require build validation.
  • In GitHub, Advanced Security provides secret scanning with push protection, CodeQL code scanning and Dependabot alerts. In Azure Repos, GitHub Advanced Security for Azure DevOps uses tasks such as AdvancedSecurity-Codeql-Init@1, AdvancedSecurity-Codeql-Analyze@1 and AdvancedSecurity-Dependency-Scanning@1, and the NewHighAndCritical or AllHighAndCritical status checks block pull requests.
  • The GitHub Advanced Security integration with Defender for Cloud uses the GitHub connector to map repositories to running workloads and add risk factors (internet exposure, sensitive data, critical resources, lateral movement) to GHAS alerts. Campaigns are created in the GitHub organization with the Runtime Risks filter, and issues generated from Defender stay in sync both ways.
  • To scan images in the pipeline, use Microsoft Security DevOps with Trivy (break: true fails the build) or the Defender for Cloud CLI (defender scan image); Defender for Containers also assesses registry images and running images. CodeQL must run in the same container where the code is built (container: image: on the job) and doesn't support musl-based Alpine images.

5. Implement an instrumentation strategy

5–10%

Configure monitoring for a DevOps environment

  • Azure Pipelines integrates with Azure Monitor through the Query Azure Monitor alerts check or gate, which lets a deployment proceed only when no alert rules are activated. Application Insights creates Azure DevOps work items or GitHub issues from templates stored as Azure Monitor workbooks. Azure DevOps auditing can be streamed to Azure Monitor Logs and queried with KQL in the AzureDevOpsAuditing table.
  • For virtual machines you install the Azure Monitor agent and associate data collection rules; host metrics are collected without an agent. On AKS you combine managed Prometheus, container log collection and a diagnostic setting for the control plane. Application Insights uses a connection string and OpenTelemetry, while Storage insights and Network insights work without configuration.
  • Insights for GitHub Projects lets you build current charts and historical charts (X-axis set to Time), filter them with the same syntax as views and aggregate number fields on the Y-axis; archived items are not tracked. Repositories offer Pulse and the traffic graph, and organizations offer Actions usage metrics (minutes) and performance metrics (queue times, failures).
  • In GitHub, Actions notification settings deliver email or web notifications and can be limited to failed workflows; to automate alerts, workflow_run with types: [completed] and a condition on github.event.workflow_run.conclusion reacts to another workflow. In Azure DevOps, team subscriptions use templates such as Build fails or Run stage waiting for approval and deliver through email or service hooks.

Analyze metrics from instrumentation

  • Host metrics of a virtual machine, such as Percentage CPU, Available Memory Bytes, OS Disk Queue Depth or Network In Total, are collected without an agent and analyzed in metrics explorer with aggregations, filters and splitting. The VM insights Performance tab uses guest data and shows Top N charts for CPU, memory, disk and network, including traffic between virtual networks.
  • Application Insights offers usage tools: Users, Sessions and Events, Funnels for conversion through a fixed sequence, User Flows for path exploration, Cohorts, retention and Impact Analysis. Users are counted by anonymous IDs unless an authenticated user ID is set. The Performance and Failures views list operations with their count, average duration and affected users.
  • Application Insights correlates distributed telemetry through operation_Id, shared by every item of an operation, and operation_ParentId, which points to the immediate parent; with W3C Trace Context, traceparent carries those identifiers. Application map identifies components by cloud role name, and end-to-end transaction details show a Gantt chart of requests and dependencies.
  • A KQL query starts with a table and chains operators with |: where filters (== is case sensitive and =~ is not), project selects columns, extend adds columns, summarize aggregates with functions such as count() or avg(), and bin() groups by time intervals. take returns arbitrary records, top sorts on the server, and render must come last.
Practice this certification