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

Microsoft Certified: Agentic DevOps Engineer Expert

Key concepts grouped by official exam weight.

Download as PDF (free, no sign-up)

1. Design and implement processes and communications

15–20%

Design traceability and flow of work

  • Design the flow of work by connecting phases: plan in Azure Boards or GitHub Projects (columns, split columns, WIP limits, Definition of Done), build with automatic linking of work items to builds, deploy through environments that record history and deployed work items, and operate by creating work items from Application Insights with their telemetry context.
  • Feedback cycles in Azure DevOps rely on subscriptions: personal, team, project or global, delivered by email or through service hooks to external services such as Teams, Service Bus or Datadog. Delivery by role limits alerts to the people involved and Skip initiator avoids notifying whoever made the change. In GitHub Actions, scheduled workflow notifications follow the creator or whoever re-enables it.
  • Choose the process to fit the team: Basic (epics, issues, tasks), Agile (user stories), Scrum (backlog items with Approved and Committed states) or CMMI (change control, risks and reviews). Organize work with area paths per team or component, which can also restrict access, and iteration paths per sprint, and use delivery plans to see several teams and their dependencies on a calendar.
  • Traceability connects work items with branches, commits, pull requests, builds, releases and tests. In Azure Repos, the Check for linked work items policy enforces links; with GitHub, AB# in commits or descriptions links items and, with fixes, transitions them when merged into the default branch. Requirement-based test suites and traceability reports measure the quality of each requirement.

Design and implement success metrics for DevOps

  • Turn each KPI into a measurable metric: lead time (creation to Completed) for customer commitments, cycle time and the cumulative flow diagram for efficiency and bottlenecks, pass rate, duration and test failure reports for delivery quality, and GitHub security overview (Coverage, Remediation) for security, using the audit log when compliance needs consistent data.
  • With the Azure DevOps MCP Server in agent mode, an assistant turns natural language questions into WIQL queries and tool calls over work items, builds and tests. Analytics exposes OData (LeadTimeDays and CycleTimeDays only for completed items) for Power BI. Azure Copilot generates sample KQL for Azure Monitor logs, and Copilot usage metrics measure AI adoption.

Configure collaboration and communication

  • Document the project with Azure DevOps wikis (a project wiki or code published as a wiki, kept in sync with the branch), a README in .github, root or docs, release notes generated and configured in .github/release.yml, a LICENSE file, and CODEOWNERS, where the last matching pattern wins. Mermaid draws process diagrams, and Copilot drafts pull request summaries starting from a blank description.
  • Set requirements for agents with instructions in .github/copilot-instructions.md, .instructions.md files with applyTo, and AGENTS.md; skills in .github/skills with SKILL.md; and custom agents whose tools field limits tools. Copilot cloud agent pushes only to its copilot/ branch and cannot approve its pull requests. Scheduled agentic workflows run with read permissions and write only through safe-outputs.
  • Azure DevOps MCP Server can be remote (https://mcp.dev.azure.com/{organization}, HTTP and Entra ID), filtered with X-MCP-Toolsets, X-MCP-Tools or X-MCP-Readonly, or local (stdio, PAT or Entra ID). The remote GitHub MCP server uses OAuth or a PAT. For Copilot cloud agent, the repository JSON supports only tools, uses COPILOT_MCP_ secrets, and the built-in GitHub server reads only the current repository.
  • GitHub webhooks and Azure DevOps service hooks push events (pushes, reviews, work items) to external systems without polling. MCP servers give Copilot tools: for Copilot cloud agent they are configured per repository and read Agents secrets prefixed COPILOT_MCP_. Agent skills are folders with a SKILL.md file (name and description) under .github/skills.
  • The Azure DevOps MCP Server gives AI assistants in agent mode access to work items, pull requests and pipelines. The remote server (https://mcp.dev.azure.com/{org}) requires Microsoft Entra; the local one runs with npx over stdio. X-MCP-Toolsets and X-MCP-Readonly headers limit its tools, and Azure Boards can start Copilot on GitHub repositories.

2. Design and implement a source control strategy

10–15%

Design and implement branching strategies for Azure DevOps and GitHub

  • Microsoft recommends short-lived feature branches merged into main through pull requests and an always-healthy main branch (a trunk-based approach). Release branches are cut from main, never merged back, and receive fixes by cherry-pick. GitHub flow deletes the branch after merge, and git worktree lets you check out several branches at once from one repository.
  • In Azure Repos, branch policies require a minimum number of reviewers, build validation with configurable expiration, linked work items and automatically included reviewers with path filters. In GitHub, branch protection rules and rulesets require approved pull requests, code owner review, dismissal of stale approvals and conversation resolution.
  • Azure Repos can limit merge types (basic, squash, rebase and fast-forward, rebase with merge commit) and blocks direct pushes only when required policies exist. GitHub offers linear history, signed commits, merge queues, required deployments and branch locking; multiple rulesets are aggregated and the most restrictive rule applies.
  • Copilot cloud agent pushes only to its copilot/ branch and is subject to branch protections and required checks; if a ruleset blocks it, add Copilot as a bypass actor. It cannot approve or merge its pull requests, the person who requested the work cannot approve them, and workflows wait for approval from a user with write access.

Configure and manage repositories for Azure DevOps and GitHub

  • In Azure Repos, permissions are set on All Repositories, on a single repository or on a branch; Deny overrides Allow and Not set inherits. Bypass policies when completing pull requests and Bypass policies when pushing separate overriding policies at completion from direct pushes. In GitHub, the Read, Triage, Write, Maintain and Admin roles scale access; only Admin manages branch rules.
  • Git supports lightweight tags (just a name) and annotated tags (tagger, date and message, meant for releases). Azure Repos creates annotated tags from the portal, and deleting tags needs the Force push permission. Tags don't trigger Azure Pipelines unless trigger: tags is set, GitHub Actions filters with on.push.tags, and GitHub rulesets can also protect tags.
  • Traceability ties code to work: in GitHub, AB# mentions link commits and pull requests to Azure Boards, and keywords such as Fixes close issues when merged into the default branch. Azure Repos can require linked work items and, with a policy on the coverage status, minimum coverage; GitHub Code Quality blocks pull requests through quality rulesets.
  • Git hooks are executable scripts in .git/hooks (or the path set by core.hooksPath) that fire at points such as pre-commit, commit-msg or pre-push; a non-zero exit aborts the operation. Client-side hooks are not copied when cloning and --no-verify skips pre-commit, commit-msg and pre-push, so mandatory policies must also be enforced on the server side.
  • GitHub Enterprise Importer, through the gh ado2gh extension and tokens in GH_PAT and ADO_PAT, migrates Git source, pull requests and branch policies from Azure DevOps Cloud (not Server), but not LFS objects. Run a trial migration, halt work during the real one, and afterwards review the migration log, adjust visibility and reclaim mannequins.

3. Design and implement build and release pipelines

35–40%

Design and implement a package management strategy

  • Azure Artifacts provides project- or organization-scoped feeds for NuGet, npm, Maven, Python, Cargo and Universal Packages, with upstream sources and views. GitHub Packages hosts npm, RubyGems, Maven, Gradle, NuGet packages and container images next to the code, with repository or granular permissions, and GitHub Actions authenticates with GITHUB_TOKEN to publish to its own repository.
  • An Azure Artifacts feed saves copies of packages installed from its upstream sources and searches in order: published packages, saved packages, then each upstream by position. Use a single feed per client configuration. The @local, @prerelease and @release views are read-only: you publish to the base feed and promote validated versions, which are exempt from retention.
  • SemVer uses Major.Minor.Patch: major signals breaking changes, minor compatible features and patch fixes; hyphenated labels mark prereleases and build metadata follows a plus sign. CalVer encodes the date but not the scope of a change, so Microsoft recommends SemVer with the date in metadata. NuGet uses interval ranges and Dependabot lets you set versioning-strategy.
  • In Azure Pipelines, the name property sets the run number with tokens such as $(Date:yyyyMMdd), $(SourceBranchName) and $(Rev:r), which resets to 1 when the rest of the number changes; counter() keeps one counter per prefix. Pipeline resources pick the artifact version by run number, branch or tags, and GitHub Actions artifacts carry a name and retention-days.

Design and implement a testing strategy for Azure DevOps pipelines and GitHub Actions

  • Quality gates block merging: branch policies with build validation and status checks in Azure Repos, or rulesets with required checks, code scanning results and successful deployments in GitHub. Release gates control deployment: Azure Pipelines approvals and checks defined outside the YAML on protected resources, and deployment protection rules on GitHub environments.
  • Copilot code review can run automatically through rulesets, but its reviews do not count as approvals unless Copilot approvals are enabled. The repository MCP configuration is shared by the cloud agent and code review, which only uses tools marked readOnlyHint; secrets start with COPILOT_MCP_. The Azure DevOps MCP Server exposes builds, pull requests and work items to agents.
  • A shift-left strategy classifies tests by dependencies and run time (L0/L1 unit tests, isolated L2 functional tests, L3 against a test deployment, L4 against production) and runs most of them before code merges to main. Load tests are automated with Azure Load Testing (AzureLoadTest task or azure/load-testing action) and failure criteria in the YAML configuration file.
  • In Azure Pipelines, VSTest@3 spreads tests across agents with strategy: parallel and batching by test cases, execution time or assembly, and PublishTestResults@2 documents JUnit, NUnit, TRX, xUnit or CTest results in the Tests tab. Copilot generates tests with /tests, Copilot cloud agent prepares its environment with copilot-setup-steps.yml, and the Azure DevOps MCP Server exposes a testplan toolset.
  • PublishCodeCoverageResults@2 publishes coverage (Cobertura, JaCoCo, .coverage and others) to the Code Coverage tab; in Azure Repos, azurepipelines-coverage.yml configures diff coverage for pull requests, and a branch policy makes it mandatory. Copilot helps cover branches and edge cases, and the Azure DevOps MCP Server can download build artifacts for analysis.

Design and implement Azure DevOps pipelines and GitHub Actions

  • Azure Pipelines offers YAML and the classic editor (needed for TFVC, Subversion or Bitbucket Server), stages in one YAML file, and environments with history and traceability. GitHub Actions uses only YAML stored in the repository, environments with required reviewers, wait timers and allowed branches, and connects to Azure with the Azure Login action, preferably through OpenID Connect.
  • Microsoft-hosted agents and GitHub-hosted runners give a fresh machine per job with no maintenance, but no access to your network. Managed DevOps Pools adds custom images, virtual networks and multi-organization use; GitHub larger runners support Azure private networking; self-hosted machines give full control but require maintenance and should almost never serve public repositories.
  • An Azure Pipelines self-hosted agent is registered with config.sh or config.cmd (using --unattended, --pool, --replace) and runs as a service through svc.sh. In GitHub, runners are targeted with runs-on by labels or by group, and ungrouped runners land in the default group. Managed DevOps Pools joins your network through one subnet per pool delegated to Microsoft.DevOpsInfrastructure/pools.
  • Azure Pipelines accesses GitHub through the GitHub App (Azure Pipelines identity and GitHub Checks), OAuth or a PAT. It validates pull requests with the pr trigger, supports /azp run comments and status checks on protected branches, and doesn't expose secrets to forks by default. Azure Boards links GitHub commits, pull requests and issues to work items.
  • Copilot generates GitHub Actions and Azure Pipelines YAML; .instructions.md files with applyTo scope rules to .github/workflows, and Copilot can convert cron schedules to UTC. Agentic workflows are written in markdown with frontmatter (on, permissions, safe-outputs, engine) and compiled with gh aw compile; the Azure DevOps MCP Server can create pipelines when it isn't read-only.

Design and implement deployments

  • Progressive exposure limits the blast radius: canary releases go first to a small group, blue-green keeps two environments that can each carry the full load and shifts traffic, and rings widen the audience after bake time. Feature flags decouple deployment from exposure and allow switching off without redeploying; variant flags support A/B testing.
  • To order dependent deployments, Azure Pipelines offers pipeline completion triggers through resources: pipelines with branch, tag or stage filters, and dependsOn plus stageDependencies inside a pipeline. In GitHub Actions, needs orders jobs and workflow_run chains workflows. In Bicep, Resource Manager infers implicit dependencies and deploys independent resources in parallel.
  • App Service deployment slots let you validate in a staging slot, warm up every instance and swap it into production without dropping requests; swapping again rolls back. Swap with preview applies the target settings first. Scale sets with a rolling upgrade policy update in batches using health probes, and Load Balancer stops sending new connections to unhealthy instances.
  • In the Microsoft release flow, an urgent fix is first made in main through a pull request and then brought into the release branch with cherry-pick, so the bug does not come back in the next release. Depending on severity, it may skip rings or tiers, and emergency protocols speed up approvals and reduce bake time.
  • A resilient deployment stops as soon as a health model detects a problem and recovers by rolling back, rolling forward with a fix, or redeploying the last known good configuration. In Azure Pipelines, retryCountOnTaskFailure and on: failure hooks help; Traffic Manager provides health-monitored failover, and point-in-time restore protects data.

Design and implement infrastructure as code (IaC)

  • An IaC strategy uses versioned declarative files such as Bicep or ARM templates, which are idempotent and prevent drift between environments; Bicep needs no state files and offers modules and what-if. Deployment stacks, not complete mode, are recommended for deleting resources, and operating system settings are managed as code with Azure Machine Configuration.
  • Azure App Configuration centralizes settings and feature flags outside the code and complements Key Vault. Labels create per-environment variants of the same case-sensitive key. In Azure Pipelines, the Import and Export tasks sync files and variables (with Dry Run and deletion of missing keys), and GitHub Actions uses az appconfig kv import with OIDC.

Maintain Azure DevOps pipelines and GitHub Actions

  • Azure Pipelines provides pass rate (top failing tasks), duration (slowest tasks) and test failures reports, filterable by date and branch. Flaky test management detects flaky tests through reruns or an API and can exclude them from the summary so they don't fail the pipeline. In GitHub, performance metrics show run and queue times and failure rates.
  • To optimize pipelines: Cache@2 reuses dependencies across runs with lock-file keys, restoreKeys and cacheHitVar; batch: true groups pushes and fetchDepth reduces downloaded history; retryCountOnTaskFailure retries tasks with transient errors. In GitHub Actions, concurrency with cancel-in-progress cancels outdated runs for the same branch.
  • In Azure Pipelines, run retention is set only at project level, keeps recent runs for the default branch, protected branches and the pipeline, and doesn't govern packages; retention leases extend specific runs. Azure Artifacts feeds have their own retention and views exempt versions; in GitHub, retention-days adjusts each artifact.

4. Design and implement a security and compliance plan

15–20%

Design and implement authentication and authorization methods

  • For Azure-hosted workloads a managed identity is preferred, because Azure manages its credentials; a system-assigned identity lives and dies with its resource and a user-assigned one is shared across resources. Outside Azure, use a service principal with federation or a certificate rather than a secret. In Azure DevOps the identity is added explicitly to the organization and authorized with access levels and groups.
  • GITHUB_TOKEN is an installation token limited to the workflow's repository; the permissions key enforces least privilege and anything unspecified becomes none. For other repositories or long-lived integrations, use a GitHub App, which isn't tied to a user, with actions/create-github-app-token. Personal access tokens suit short scripts, and fine-grained tokens are preferred over classic ones.
  • Secretless authentication uses OIDC and workload identity federation: in GitHub Actions the job needs id-token: write and azure/login exchanges the token for a short-lived Azure token, with the federated credential on an Entra application or a user-assigned managed identity. In Azure Pipelines, federated service connections remove stored secrets.
  • Service connections authenticate Azure Pipelines to external services; for Azure Resource Manager, workload identity federation is recommended because it removes secrets, and each pipeline should be authorized individually. Use PATs only when Microsoft Entra authentication isn't available: organization-scoped, minimal scopes, short lifetime and kept in a secret store.
  • In Azure DevOps, access levels decide which portal features are visible and security groups grant Allow or Deny; a Deny from another group at the same scope generally wins, and an explicit assignment on a child node replaces the inherited one. In GitHub you pick repository roles from Read to Admin, and the permissions key limits the GITHUB_TOKEN.

Design and implement a strategy for managing sensitive information in automation

  • In Azure Pipelines, the AzureKeyVault@2 task downloads secrets as variables through a service connection with Get and List permissions, and a variable group can be linked to a vault so values are read at run time. In GitHub Actions you sign in with azure/login and OIDC, read the secret with the CLI and mask it with ::add-mask::.
  • Key Vault stores secrets, keys and certificates; with Azure RBAC you assign the minimum role, such as Key Vault Secrets User to read secrets. Soft-delete lets you recover objects and purge protection blocks purging before retention ends. Rotation policies create new key versions that services pick up through the versionless URI, and integrated-CA certificates renew automatically.
  • Azure Pipelines secure files store encrypted certificates, profiles and keys; they're protected resources with approvals and pipeline permissions, and DownloadSecureFile@1 downloads them at the start of the stage and deletes them when the job ends. In GitHub Actions, secrets can be repository, organization or environment secrets, and environment secrets are released only after protection rules pass.
  • Secret masking is best effort, not a guarantee: substrings and parts of structured data aren't redacted, so use one secret per value, map secrets to environment variables instead of passing them on the command line, and register derived values with ::add-mask::. Fork builds must not receive secrets or run untrusted code with privileges.

Automate security and compliance scanning

  • A scanning strategy combines tools by stage and content type: dependency review on every pull request to block vulnerable packages, CodeQL for code, the Microsoft Security DevOps extension for IaC templates, containers and binaries, and Defender for Cloud to see findings from Azure DevOps, GitHub and GitLab in one console.
  • In Azure Repos, GitHub Advanced Security for Azure DevOps turns on push protection and history secret scanning; dependency scanning and CodeQL run as pipeline tasks, and AdvancedSecurity status checks block vulnerable pull requests. In GitHub, CodeQL default setup requires Actions, and delegated bypass limits who can bypass push protection.
  • Defender for Cloud connects Azure DevOps, GitHub and GitLab from Environment settings with native connectors. GitHub requires installing the DevOps security GitHub app as organization owner; Azure DevOps requires Project Collection Administrator, Basic access and third-party OAuth access On. Operations run under the authorizing identity, so a dedicated service account is recommended.

5. Implement an instrumentation strategy

15–20%

Configure monitoring for Azure DevOps and GitHub platforms

  • In Azure DevOps, the Lead Time widget measures from work item creation to Completed and Cycle Time from when work starts; both show a moving average and standard deviation for one team. The Cumulative Flow Diagram shows flow of work per column and reveals bulges. For recovery, track mean time to restore service after an incident.
  • Azure DevOps can stream its audit log to Azure Monitor Logs, where you query the AzureDevOpsAuditing table and create alerts; Splunk and Event Grid are also supported. GitHub Enterprise Cloud streams audit and Git events to Azure Event Hubs or Blob Storage from the time it's enabled. Application Insights receives release annotations from Azure Pipelines and creates work items in GitHub or Azure DevOps.
  • GitHub offers insights at several levels: Pulse and traffic per repository, GitHub Actions usage and performance metrics per organization, and charts in insights for Projects. Current charts group items by a field and historical charts put Time on the X-axis; the Y-axis can sum or average a number field. A custom role lets non-owners view Actions metrics.
  • In Azure Pipelines, alerts come from team or project notification subscriptions, the Azure Pipelines app for Slack or Teams, which can filter on failed builds and approve stages, and the Query Azure Monitor Alerts check on environments. In GitHub Actions, users are notified about runs they trigger, and workflow_run with a condition on the conclusion builds custom alerts.

Monitor Azure workloads by using AI agents

  • Azure Copilot Observability Agent lets you chat with logs and metrics and investigate incidents with no provisioning. For autonomous operations, which correlate alerts and create Azure Monitor issues, you create an Observability Agent resource with a managed identity, an Application Insights scope and custom instructions. The agent never restarts resources or changes configuration: people decide.
  • Creating Azure SRE Agent requires Owner, or Contributor plus User Access Administrator, and the creator receives SRE Agent Administrator. You then connect code repositories, log sources such as Application Insights and, optionally, resource groups at the Reader or Privileged level for its managed identity. Tool access policies can only deny at the global scope.
  • Azure SRE Agent investigates by validating or ruling out hypotheses, proposes mitigations and, in Review mode, waits for an SRE Agent Administrator to approve Azure infrastructure operations. It never runs deletes, respects ReadOnly locks and logs every az command as an AgentAzCliExecution event in Application Insights. It can also create work items, notify or trigger workflows.

Analyze metrics from instrumentation by using AI agents

  • VM host metrics (CPU, network and disk utilization) are available without an agent; guest memory and free disk space need the Azure Monitor agent and a DCR, for example through VM insights, which writes to InsightsMetrics. Azure SRE Agent queries metrics and logs with its managed identity without connectors and analyzes time series; the Observability Agent correlates better when VMs are monitored.
  • Application Insights provides the Performance, Failures and Search views plus End-to-end transaction details; Live metrics shows data with one-second latency without retaining it. The Azure Copilot Observability Agent runs deep investigations from an alert that correlate application, infrastructure and platform signals; results are temporary and are preserved by saving them as an Azure Monitor issue.
  • Application Insights groups the telemetry of a distributed transaction with operation_Id (the root operation) and links each item to its immediate parent through operation_ParentId. Application map identifies components by cloud role name, and End-to-end transaction details shows a Gantt chart of requests, dependencies and exceptions. Sampling in the distro avoids broken traces; ingestion sampling makes them more likely.
  • Copilot agent activity on GitHub is reviewed in the enterprise audit log with actor:Copilot; each event includes user and agent_session_id. For long-term history it is streamed to a destination such as Azure Event Hubs. Local client data is collected with OpenTelemetry, and the identity capture class attributes activity without capturing prompts or responses.
  • From the Logs page, the Observability Agent answers natural-language questions about logs and metrics, and Azure Copilot generates example KQL. In case-sensitive KQL, where filters (== exact, =~ case-insensitive), summarize with bin groups by time intervals, project and extend shape columns, and top sorts and limits; search is slower than filtering.
Practice this certification