AZ-400 notes: the flow, the pipeline, and the proof

Domain 1: Traceability and flow of work

Pick one way work moves. GitHub Flow keeps a single main branch and merges short-lived topic branches through pull requests. GitHub Issues and Azure Boards are the feedback and planning records. GitHub Projects is the board that sits on GitHub. The exam cares that a commit or pull request references the work item, not that you can recite a ceremony name.

Source, bug, and quality traceability means you can walk from a requirement or bug to the change and then to the test that proved it. A branch name is a hint. A link is evidence. If two teams keep two trackers, design one integration rather than a third status meeting.

Study evidence: take one production bug and write the three ids you would show an auditor: work item, commit, test run. Add the artifact identifier and deployment record to demonstrate which tested change reached production.

Metrics and queries

On an Azure Boards work-item chart, lead time runs from creation to completion, while cycle time begins when the item enters an in-progress state. Delivery-performance lead time for changes commonly measures commit to production instead. Name the start and end events on the dashboard; these measurements are not interchangeable. Time to recovery measures restoration after a service failure. Those three numbers answer different questions, and a build-success badge answers none of them.

The study guide also asks for queries aimed at planning, development, testing, security, delivery, and operations. Planning shows blocked work. Development shows review wait. Testing shows pass rate and flakes. Security shows open vulnerabilities. Delivery shows deployment frequency and change fail rate. Operations shows incidents and recovery. Put the query where that decision is made. Do not collapse them into one vanity chart.

Wikis, release notes, webhooks, and Teams

Project documentation in the guide is Markdown, with Mermaid for process diagrams. Release documentation includes release notes and API docs produced with the release. Automating notes from Git history keeps them tied to the merges. A PDF edited on a laptop goes stale on the next commit.

A webhook is an HTTP callback when an event happens. Microsoft Teams is the named chat integration for GitHub or Azure DevOps. Use one of those when the stem says people must hear about a deploy without polling. A shared mailbox that someone checks hourly is the habit the control replaces.

References: Azure Boards and GitHub and GitHub Flow.

Domain 2: Branch strategy and pull requests

Trunk-based development keeps one main line and short-lived branches. A feature branch isolates a change until review. A release branch stabilizes a version while main continues. A hotfix still has to land on the release line and come back to main. A commit that exists only on a laptop is not a strategy.

Azure Repos branch policies and GitHub branch protection rules are the enforcement pair. They can require a pull request, reviewers, and a successful build, and they can block a direct push. A README comment cannot. Required reviewers plus a green build is the pull-request workflow the guide names.

Large files, permissions, tags, and history

Git LFS and git-fat keep large content out of ordinary blobs so clones stay usable. Git Scalar is the named tool for scaling a large repository. Cross-repository sharing, or a versioned package, replaces copy-paste when two products need the same component. Permissions should let a contractor read one repository without owning the organization.

Tags mark the commit a release built. They do not replace branch protection. To recover a deleted file that still exists in history, restore it from that commit. git revert adds a new commit that undoes an earlier one and is the safe choice on a shared branch. git reset --hard changes local state; a subsequent force-push can rewrite history other people already have.

Deleting a secret in a new commit leaves it in older commits. First revoke or rotate the exposed credential. Then assess whether coordinated history cleanup is necessary and address reachable copies and caches. Rewriting one repository cannot guarantee that every external clone has been erased. Making the repository private does not remove the blob.

Study evidence: say out loud which command you would run on a shared main branch, and which command you would refuse. If both answers are a force-push, stop and reread this section.

Separate local and remote effects: git reset --hard moves the local branch and overwrites tracked working-tree changes. It does not update the remote by itself. A subsequent forced push can replace shared branch history. For a public fix, a revert usually preserves collaboration better; inspect merge commits carefully because reverting one requires selecting the intended parent.

References: Git reset and credential exposure and history cleanup.

Domain 3: Packages and versions

GitHub Packages fits when the repository and the consumers already live on GitHub. Azure Artifacts fits when Azure DevOps pipelines publish and consume the feed. An upstream source can save packages from configured public or private sources through your feed. A view such as @Release can expose versions your process has validated and promoted. Promoting a package keeps the same bits. Rebuilding can produce different bits.

SemVer MAJOR is a breaking change, MINOR is a compatible feature, and PATCH is a compatible fix. CalVer encodes a date and does not claim that compatibility meaning. Pin production dependencies. A floating latest tag is how a quiet Tuesday becomes an incident. Pipeline artifact versions should identify the commit that produced them. Artifact retention deletes old build outputs. A package view selects what consumers may take. They are not the same knob.

Publish once, promote the tested version

In Azure Artifacts, publish a package to the base feed, where it appears in @Local; do not publish directly to @Release. After validation, promote that same package version to the desired view. The name @Release is a label, not an automatic scanner or approval. Configure the validation and promotion permissions that give the label meaning.

A Feed Reader can consume available packages. Saving a new version from an upstream requires the relevant collaborator or higher permission. Check both feed and view access when a consumer should see only approved versions. Package versions are immutable: repair a bad release with a new version and a clear consumer plan instead of expecting deletion to free the old version number for reuse.

References: feed views and promotion and feed permissions.

Tests and gates

A comprehensive strategy includes local tests, unit tests, integration tests, and load tests. Local tests run before the pipeline. Unit tests stay small. Integration tests check collaborators. Load tests show behavior under traffic and usually belong later than every commit. A pipeline test task runs the tests and publishes results. Test agents run work, such as UI or load tests, that should not all sit inline on the build agent.

A quality gate stops promotion when tests or coverage fail. A security or governance gate stops promotion when a scan or policy fails. Publishing results is what lets those gates and the testing dashboard see the outcome. Selective tests can shorten a run. They do not erase the rest of the strategy. A mandatory red scan needs a recorded exception, not a silent continue.

Publishing evidence is different from enforcing a gate

A report can display failed tests while a job still succeeds if the test command masks its exit code or the publisher is not configured to fail on failures. For PublishTestResults@2, choose failure behavior explicitly, including missing results when the test run is mandatory. Publish reports on failed runs for diagnosis, but preserve the failed state for downstream promotion.

PublishCodeCoverageResults@2 publishes coverage; its failIfCoverageEmpty setting detects missing coverage, not an 80% minimum. Enforce your threshold through a test tool, a dedicated validation step, or a required coverage status policy appropriate to the repository. High coverage also does not prove that assertions test the important behavior.

References: test-result failure options and coverage publishing options.

YAML pipelines, agents, and templates

Choose GitHub Actions when the workflow should live with a GitHub repository. Choose Azure Pipelines when you want Azure DevOps agents, environments, and the related services. Hosted runners are patched for you and billed by use. Self-hosted runners reach private networks and custom tools, and you patch them. A self-hosted agent usually calls the service outbound. You do not open an inbound shell for Azure DevOps to reach it. Count parallel jobs, licenses, and hosted minutes when you compare cost.

Connect a GitHub repository to Azure Pipelines with a service connection, not a morning zip upload. CI triggers follow matching commits. Pull request triggers follow pull request changes. Scheduled triggers follow a cron. Path filters skip irrelevant folders. YAML belongs in the repo. Classic UI pipelines are what you migrate to YAML so the definition is reviewed with the code.

Parallel jobs run independent work. dependsOn or needs orders the rest. A multi-stage pipeline separates build, test, and deploy. A hybrid pipeline mixes hosted and self-hosted agents. YAML templates reuse steps. Task groups reuse classic tasks. Variable groups share values and can link to Key Vault. Deployment jobs reference environments in YAML, but resource administrators configure environment approvals and checks outside the YAML file in Azure Pipelines. An approval does not erase a failed test. Use both when the strategy requires both.

References: Azure Pipelines concepts and GitHub Actions.

Platform distinctions that change the answer

Azure Pipelines template expressions such as ${{ parameters.name }} are expanded early. Macro variables such as $(name) are expanded for tasks. A value created by a task is not available when the earlier template expansion decides which jobs exist. Use output variables and dependency mappings for values needed in a later job; do not pass credentials as ordinary template parameters.

A custom condition replaces the default condition. For a production stage, checking only the branch name may accidentally omit the successful-validation requirement. Keep both requirements explicit. Put diagnostic publishing in a step that may run after failure, while leaving deployment blocked.

References: Azure Repos PR validation, resource approvals and checks, and pipeline conditions.

Deployment patterns

Blue-green keeps two environments and switches traffic after the new one is healthy. A canary sends a small slice first. Rings widen the audience in stages. Progressive exposure continues only while health holds. A/B testing compares product variants. It is not the same decision as an infrastructure cutover. Feature flags, through Azure App Configuration Feature Manager, change behavior without a full redeploy. They do not remove a rollback plan if the default is unsafe.

Deploy dependencies before the app that needs them. Deployment slots warm a version and then swap, which cuts app downtime and does not rewind a failed database migration. Rolling updates keep some instances serving. Load balancing keeps traffic on healthy instances. A hotfix still goes through source control and a pipeline. Include database tasks in that pipeline so the schema does not drift in a separate untracked step. Containers ship an image. Binaries ship a built artifact. Scripts and IaC apply a declared change.

Database compatibility sets the rollback boundary

For a database shared by old and new application versions, use an expand-and-contract sequence: add a compatible schema, deploy code that works during coexistence, migrate data with an observable process, and remove obsolete fields only after the old version is retired. A destructive migration followed by a slot swap can break both slots because they may use the same database.

Define a canary's decision before rollout: compare error rate and latency with a baseline, require enough requests, observe for a stated interval, and identify who or what stops expansion. Keep the tested artifact available for recovery. Rollback, roll-forward, and disabling a feature flag address different failure modes; select the action that preserves data and restores the user journey.

Infrastructure as code

An IaC strategy is the template in source control plus automated test and deployment. Bicep is a declarative language for Azure resources over the Azure Resource Manager model. Azure Automation State Configuration applies desired state through Automation. Azure Machine Configuration applies and audits in-guest configuration at scale. Desired state means the tool converges to a declaration. A portal click is drift unless you then author it.

Test templates with lint, what-if, or a non-production deployment before production. Azure Deployment Environments give developers on-demand environments that still follow project guardrails. A self-service subscription with no policy is not that product.

Lifecycle note, reviewed October 28, 2026: Azure Automation State Configuration remains named in the study guide, but the service is scheduled to retire on September 30, 2027. Learn its role for the exam and evaluate Azure Machine Configuration for migration and new designs. A what-if preview helps review planned resource changes; it does not prove that runtime behavior, permissions, or the deployment itself will succeed.

Reference: State Configuration migration guidance.

Keeping the pipeline healthy

Watch failure rate, duration, and flaky tests. A flaky test alternates between passing and failing under apparently unchanged conditions; investigate isolation, timing, dependencies, and possible product races. Optimize cost by cutting unused hosted minutes and caching repeated restores. Optimize time with parallelism and path filters. Improve reliability by fixing flakes and controlling toolchain versions. A named hosted image such as ubuntu-24.04 still receives updates; record exact SDK and dependency versions when reproducing a failure. Caching does not replace a lockfile. Disabling tests is not an optimization.

Concurrency limits protect licenses, quotas, and shared environments. Retention should bound storage without deleting an artifact a later deployment still needs. A long queue wait is not compiler execution time. Inspect parallel-job entitlement, busy or offline agents, demands and capabilities, and any resource checks before buying more capacity. Migrating classic to YAML puts the definition where review can see it.

Separate a cache from a release artifact. A cache accelerates disposable inputs such as package restores and must tolerate a miss. Key it by relevant operating system and lockfile information. A deployment artifact is the output you deliberately retain and promote. Review retention against the rollback window and record the immutable version or digest rather than a floating latest label.

Self-hosted agents also create a trust boundary. A runner that can reach production and holds credentials must not execute untrusted pull-request code. Isolate pools by trust level, use supported ephemeral execution where practical, and remove persistent workspace residue. Hosted networking capabilities vary; private connectivity is a requirement to evaluate, not proof that every hosted option is unsuitable.

Domain 4: Who the automation is

A system-assigned managed identity belongs to one Azure resource and dies with it. A user-assigned managed identity is its own resource and can be attached to several. A service principal represents an application identity in a tenant. Depending on the design, authentication can use a secret, certificate, or federation; managed identities are represented by a special service principal whose credentials Azure manages. Prefer a managed identity when the Azure resource supports it.

GITHUB_TOKEN is created for each GitHub Actions job and limited to the workflow repository, with permissions constrained by the applicable settings and workflow permissions. A GitHub App is an installation identity you permission on purpose. A personal access token belongs to a person; minimize its scope and lifetime when a supported app or federated identity is unsuitable. Azure DevOps service connections are how a pipeline reaches Azure or another service. Stakeholder access is a limited Azure DevOps access level. An outside collaborator is a GitHub user who can receive repository access without joining the organization. Teams inside an Azure DevOps project group people for boards, area paths, and permissions.

Secrets, federation, and leakage

Azure Key Vault holds secrets, keys, and certificates. Reference them from the pipeline. Do not copy them into Git. Workload identity federation, using OpenID Connect, lets GitHub Actions or Azure Pipelines obtain a token without a stored client secret. Secure files in Azure Pipelines hold files such as certificates that a task downloads for the run.

Mask secrets. Do not echo them. Do not write them into logs or artifacts. If a personal access token was printed, revoke it and change the pipeline identity. Deleting one log line leaves a valid token behind.

Federation removes a stored credential, not authorization checks

In GitHub Actions, id-token: write permits requesting an OIDC token; it does not grant Azure deployment rights. The Azure identity must trust the actual issuer, audience, and subject claims, and it still needs suitable Azure RBAC at the intended scope. Subject formats can differ with repository creation or migration, so use the current provider guidance rather than copying an old repository-name string blindly.

Distinguish token issuance failures from a successful login followed by an authorization failure. Check the workflow permission and federated trust for the first; check the identity, role, scope, and resource access for the second. Do not solve an environment mismatch by trusting every repository or assigning subscription Owner.

Masking reduces accidental display but is not a guarantee. Encoded values, transformed secrets, and artifacts can evade log redaction. Avoid printing them in the first place. Do not run untrusted pull-request code in a privileged pull_request_target or follow-up workflow merely because the workflow file came from a trusted branch.

References: GITHUB_TOKEN lifetime and scope, OIDC with Azure, and workflow security boundaries.

Security and compliance scanning

Dependency scanning and Dependabot alerts look for known-vulnerable open-source components. Code scanning such as CodeQL looks at your code. Secret scanning looks for committed credentials. License scanning looks for dependencies whose licenses violate policy. For CodeQL in containers, verify supported operating systems, languages, build mode, and where analysis observes the build. A container-image vulnerability scan is a separate check; putting CodeQL in a container does not make it an image scanner. Scan container images before deployment.

GitHub Advanced Security covers GitHub and, as GitHub Advanced Security for Azure DevOps, Azure DevOps repositories. Microsoft Defender for Cloud DevOps Security is the posture view across those connected environments. Integrate the two so findings are not trapped in the repository UI. A gate that continues silently is not a strategy.

References: Defender for Cloud DevOps and Key Vault overview, and CodeQL with containerized builds.

Finding a vulnerability does not automatically block a merge or deployment. Connect the scanner's result to the required check or release policy, define severity and exception rules, and give exceptions an owner and expiry. Dependabot alerts report known dependency issues; an update pull request still needs testing and review. A container can include vulnerable operating-system packages even when an application's CodeQL analysis is clean.

Domain 5: What you collect

Azure Monitor collects metrics and logs. Azure Monitor Logs is the store you query. Application Insights collects application requests, dependencies, and traces. VM Insights covers virtual machine performance. Container Insights covers workloads such as AKS. Azure Monitor for Storage and Azure Monitor for Networks cover those platform signals. They do not replace traces inside your code.

GitHub insights charts show repository and Actions activity. They are not distributed traces. Alert on failed GitHub Actions and Azure Pipelines runs. An alert that watches only build-agent CPU misses an application failure that happens after a green deploy. Connect monitor signals to the DevOps tools so an incident can open work or notify the same channel the pipeline uses.

Reading the telemetry

During an incident, inspect CPU, memory, disk, and network before you assume the application code is the cause. Usage metrics say how much a feature is used. Performance metrics say how slow or how often it fails. Distributed tracing follows one request across services. If CPU is idle and users are slow, look at dependency duration in the trace.

A basic KQL query starts at a table, filters with where, and shapes rows with project or summarize. After a bad deploy, filter requests by the release window and the result code, then group failures by operation name. Restarting everything first destroys the comparison. A green pipeline plus user harm means the feedback loop stopped at the pipeline badge.

Study evidence: write a one-line KQL sketch for failed requests in the last hour grouped by operation. If you cannot name the table you would start from in your own app, practice against the Application Insights schema before you book.

References: KQL starter queries and Application Insights distributed tracing.

A concrete failure-rate query

In a Log Analytics workspace containing Application Insights data, this example uses AppRequests and its PascalCase columns. The Application Insights query experience may expose requests with names such as timestamp, success, and operation_Name. Confirm the schema in the query editor before copying a query between scopes.

AppRequests
| where TimeGenerated > ago(1h)
| summarize Requests = sum(ItemCount),
            Failures = sumif(ItemCount, Success == false)
    by OperationName, bin(TimeGenerated, 5m)
| extend FailureRatePct = iff(Requests > 0,
    100.0 * Failures / Requests, real(null))
| order by TimeGenerated asc

ItemCount weights records by the number of telemetry items they represent when sampling is in use. A raw row count can undercount represented requests. Compare the failure rate and traffic volume before and after a deployment, then inspect a failed operation and its correlated dependencies. A quiet chart can also mean missing instrumentation or delayed ingestion; an empty result is not automatically a healthy service.

Record the deployed version in telemetry or deployment annotations so that the comparison is reproducible. Correlation identifies the path to investigate, not proof that a release caused every failure in the same time window. Include a rollback or mitigation decision and a retest of the affected user journey.

Reference: AppRequests schema.

Five guided labs with expected outcomes

Use a disposable repository, project, and test environment you are authorized to change. Do not introduce a fault into a production service. Hosted jobs, telemetry, and cloud resources may incur charges; check your allowance and remove temporary resources after retaining the useful evidence.

1. Trace a release from the work item to the deployed bits

Create a sample bug and a pull request that references it. Record the commit SHA, test run, produced artifact version, and release entry. Generate release notes from an explicit previous and current release boundary rather than all repository history.

Expected result: another learner can identify exactly which artifact includes the fix and which test evaluated it. As a negative test, use a different run's artifact identifier and explain why a link to a work item alone cannot prove what reached production.

2. Validate branch policy and recover a harmless file

In a sandbox repository, require PR review and build validation on main. Use a test account without bypass permission to check the restriction. Commit and then delete a harmless text file; restore it from its earlier commit through a new reviewed change. Keep an independent copy before experimenting with local reset behavior.

Expected result: the unapproved change cannot enter main, and recovery preserves shared history. Do not use a real secret for this exercise. For a hypothetical credential exposure, document revocation first and the separate decision about coordinated history cleanup.

3. Observe successful, failed, and unapproved release paths

The Azure Pipelines example below performs a dry run and deploys no application. Create an az400-study environment with an approval check configured by a resource administrator, then authorize only the intended pipeline. For Azure Repos PR validation, add a Build validation policy on main; a YAML pr section is not the Azure Repos configuration.

parameters:
- name: failCheck
  type: boolean
  default: false
trigger:
- main
pool:
  vmImage: ubuntu-24.04
stages:
- stage: Verify
  jobs:
  - job: Check
    steps:
    - bash: |
        if [ "$FAIL_CHECK" = "True" ] || [ "$FAIL_CHECK" = "true" ]; then
          echo "Intentional study failure"
          exit 1
        fi
        echo "Study check passed"
      env:
        FAIL_CHECK: ${{ parameters.failCheck }}
- stage: ReleasePreview
  dependsOn: Verify
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  jobs:
  - deployment: Preview
    environment: az400-study
    strategy:
      runOnce:
        deploy:
          steps:
          - bash: echo "Checks passed; no application is deployed by this example."

Expected result: on main with failCheck=false, Verify succeeds and the deployment job waits for the environment check. With failCheck=true, Verify fails and ReleasePreview is skipped. On another branch, the release stage is skipped. A rejected approval must not produce a successful deployment message. Capture these outcomes before adapting the pattern to real deployment tasks.

4. Separate federation trust from resource permission

In an isolated project, configure a workload identity federation connection for a test identity with a narrowly scoped role. Start with a read-only resource query. Record the intended repository, environment, identity, and resource scope without recording tokens. If you cannot create these resources, draw the trust and authorization checks as a tabletop exercise.

Expected result: the intended workflow can perform its permitted query. A workflow outside the trusted subject must fail token exchange, and a correctly authenticated identity must still fail an operation outside its assigned access. Restoring a stored client secret is not the acceptance criterion.

5. Explain an isolated test failure with telemetry

Use a test application or sample dataset. Mark a test release, generate normal requests and a small controlled failure set, then use the AppRequests query above in a workspace containing that data. Compare request volume and failure rate, and inspect a correlated dependency if requests are slow.

Expected result: the query's schema matches its scope, the observed failures align with the test window, and the alert or review leads to a documented recovery decision. Verify the user journey after recovery. When no data appears, check collection and ingestion before declaring the test successful.

Frequently asked questions