AZ-400 Certification in Practice: Applying Azure DevOps to Real Delivery Problems

One of the most common challenges for AZ-400 candidates is turning exam objectives into work that resembles a real delivery pipeline rather than a set of disconnected study notes.

The AZ-400 exam, officially Designing and Implementing Microsoft DevOps Solutions, assesses whether a professional can design and implement DevOps practices across source control, continuous integration, continuous delivery, infrastructure, security, and instrumentation. The useful way to prepare is therefore not to memorise tool names, but to build a working delivery path and understand why each control exists.

That distinction matters because Azure DevOps work is rarely a clean sequence of isolated tasks. A team must choose a branching strategy, define build validation, protect environments, manage secrets, provision infrastructure, release safely, and measure the result. The AZ-400 exam reflects that connected reality: version control decisions affect pipeline design, infrastructure choices affect governance, and monitoring determines whether a release is genuinely healthy after deployment.

AZ-400 as a Real Delivery Scenario

A practical AZ-400 preparation project can begin with a small application in Azure Repos, a YAML pipeline in Azure Pipelines, work tracking in Azure Boards, and infrastructure defined through Bicep or Terraform. The application itself does not need to be complex. A simple API deployed to Azure App Service or Azure Container Apps is enough if the surrounding delivery system is realistic.

The repository should contain application code, tests, pipeline YAML, and infrastructure code. Pull requests should trigger build validation before changes reach the main branch. The main branch should produce a versioned build artifact or container image, then deploy through development, test, and production environments. Production should not be a casual pipeline step; it should be protected with environment approvals, branch controls, and deployment checks that match the organisation’s risk tolerance.

Example multi-stage Azure DevOps delivery flow from repository change to production deployment:

1. Developer change
2. Pull request in Azure Repos
3. Build validation: restore, compile, unit tests, static analysis
4. Merge to main
5. CI pipeline publishes artifact or container image
6. Deploy to dev -- automated smoke tests
7. Deploy to test -- approval or quality gate
8. Deploy to production -- environment approval, monitoring, rollback path

This is where many candidates lose practical depth. They can describe continuous integration and continuous delivery, but their lab work stops at a classic pipeline, a manual deployment, or a single environment. Current Azure DevOps practice is heavily YAML-driven, and AZ-400 preparation is stronger when it includes multi-stage YAML, protected environments, service connections, test publication, and deployment evidence.

A YAML Pipeline That Matches Real Work

The following pipeline is intentionally compact, but it shows the shape of a realistic Azure Pipelines implementation. It builds a .NET application, runs tests, publishes an artifact, deploys to development, runs a smoke test, and then deploys to production through an Azure DevOps environment. The production approval is not declared directly in YAML; it is configured on the production environment in Azure DevOps so that the same pipeline definition can remain version-controlled while operational approval rules are managed by environment owners.

trigger:
  branches:
    include:
      - main

pr:
  branches:
    include:
      - main

variables:
  buildConfiguration: 'Release'
  azureServiceConnection: 'sc-azure-prod'
  webAppNameDev: 'app-demo-dev'
  webAppNameProd: 'app-demo-prod'

stages:
- stage: Build
  displayName: Build and test
  jobs:
  - job: Build
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - task: UseDotNet@2
      inputs:
        packageType: 'sdk'
        version: '8.x'

    - script: dotnet restore
      displayName: Restore dependencies

    - script: dotnet build --configuration $(buildConfiguration) --no-restore
      displayName: Build application

    - script: dotnet test --configuration $(buildConfiguration) --no-build --logger trx
      displayName: Run unit tests

    - task: PublishTestResults@2
      condition: succeededOrFailed()
      inputs:
        testResultsFormat: 'VSTest'
        testResultsFiles: '**/*.trx'

    - script: dotnet publish src/App/App.csproj --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)
      displayName: Publish application

    - publish: $(Build.ArtifactStagingDirectory)
      artifact: drop

- stage: Deploy_Dev
  displayName: Deploy to development
  dependsOn: Build
  condition: succeeded()
  jobs:
  - deployment: DeployDev
    environment: 'dev'
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop

          - task: AzureWebApp@1
            inputs:
              azureSubscription: $(azureServiceConnection)
              appType: 'webAppLinux'
              appName: $(webAppNameDev)
              package: '$(Pipeline.Workspace)/drop'

          - script: curl --fail https://$(webAppNameDev).azurewebsites.net/health
            displayName: Smoke test development

- stage: Deploy_Prod
  displayName: Deploy to production
  dependsOn: Deploy_Dev
  condition: succeeded()
  jobs:
  - deployment: DeployProd
    environment: 'prod'
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop

          - task: AzureWebApp@1
            inputs:
              azureSubscription: $(azureServiceConnection)
              appType: 'webAppLinux'
              appName: $(webAppNameProd)
              package: '$(Pipeline.Workspace)/drop'

In practice, this YAML file is only one part of the control plane. Branch policies should require a successful build before merging into main. The production environment should require approval from an authorised group, and the service connection should be scoped to the subscription, resource group, or workload boundary it genuinely needs. If the organisation uses pipeline templates, the build, security scan, and deployment tasks can be centralised so that teams inherit consistent controls without copying fragile YAML between repositories.

This example also shows why the exam is not only about pressing “run pipeline.” A candidate should be able to explain where gates belong. A unit test failure should stop the build. A smoke test failure should prevent promotion. A production approval should happen after evidence exists, not before the code has even been built. That order is a practical design decision, and it is the sort of reasoning that separates tool familiarity from DevOps competence.

Mapping Exam Objectives to Hands-On Labs

The strongest AZ-400 lab plan treats the Microsoft skills outline as an implementation backlog. Instead of reading about source control, the candidate creates branch policies and pull request validation. Instead of reading about security, the candidate configures secrets, permissions, and scanning. Instead of reading about monitoring, the candidate connects releases to telemetry and work items so that production outcomes can be reviewed.

• Version control: create a repository, protect the main branch, require pull request reviewers, and enable build validation before merge.
• CI/CD: build a multi-stage YAML pipeline with test publication, artifacts, environments, approvals, and deployment history.
• Infrastructure as code: provision an App Service, storage account, Key Vault, and monitoring resources with Bicep or Terraform, then apply the same code to more than one environment.
• Security and compliance: store secrets in Azure Key Vault, use least-privilege service connections, add dependency or container scanning, and enforce Azure Policy during deployment.
• Instrumentation: configure application health checks, alerts, dashboards, and work item links so release quality can be measured after deployment.

Verification is as important as construction. A lab is not complete because a resource exists in Azure; it is complete when the candidate can prove how it was deployed, which commit introduced it, which approval allowed it into production, and which telemetry confirms that it is healthy. This habit builds exam readiness while also producing evidence that would be useful in a real change review.

Branching Strategy Changes the Pipeline

Branching strategy is often treated as a matter of team preference, but it has direct consequences for build validation, release cadence, and exam scenarios. Trunk-based development keeps changes close to the main branch and relies on small pull requests, automated tests, and feature flags to control exposure. It fits teams that want frequent integration and short-lived branches, but it requires discipline because weak tests or large changes quickly create instability.

GitFlow separates feature, develop, release, and hotfix branches. It can suit products with scheduled releases, multiple supported versions, or stricter release separation. The trade-off is pipeline complexity: teams need clear triggers for each branch type, consistent artifact promotion rules, and care to avoid rebuilding different binaries for each environment. In Azure Repos, this choice affects branch policies, pipeline filters, environment approvals, and how work items are linked to releases.

A practical decision framework is to start from release risk rather than ideology. If the team deploys small changes frequently and can hide unfinished work with feature flags, trunk-based development usually produces simpler pipelines. If the organisation must support formal release trains or long validation cycles, a release-branch model may be easier to govern. AZ-400 expects familiarity with designing version control and pipelines, so the reasoning behind the model matters as much as the model itself.

Infrastructure as Code: Bicep, Terraform, and Governance

Infrastructure as code should be part of the same delivery story as application deployment. A team that deploys code through a pipeline but creates production infrastructure manually has only automated part of the system. The more realistic lab is to create the resource group, App Service plan, application, Key Vault, Application Insights, and diagnostic settings from code, then deploy the application into that managed environment.

Bicep is a natural fit for Azure-native teams because it maps closely to Azure Resource Manager and works well with Azure Policy, managed identities, and platform governance. Terraform is often preferred where teams manage several cloud providers, already use Terraform modules, or need a broad ecosystem of providers. Both can be valid for AZ-400 preparation if the candidate understands state, review, promotion, and drift.

Drift deserves special attention because it is a real operational problem. If an engineer changes an App Service setting manually in the portal, the repository no longer describes production accurately. Terraform surfaces this through plan output against state, while Bicep deployments can be combined with Azure deployment records, what-if operations, policy enforcement, and disciplined pull request review. In either case, infrastructure changes should move through the same approval and evidence path as application changes.

Governance on Azure has also moved on from older patterns. Azure Blueprints is deprecated, so current designs should favour Azure Policy, management groups, landing zone patterns, and infrastructure code through Bicep or Terraform. For AZ-400 candidates, that means governance should not be described as a static document. It should appear in the pipeline as deploy-time policy evaluation, naming standards, required diagnostic settings, allowed regions, and managed identity permissions.

Infrastructure repository
      |
      v
Pull request: review Bicep or Terraform change
      |
      v
Plan / what-if: show intended Azure changes
      |
      v
Policy evaluation and approval
      |
      v
Deploy platform resources
      |
      v
Application pipeline deploys into governed environment

DevSecOps Beyond Running a Scanner

Security in a DevOps pipeline is sometimes reduced to adding a scanner task and moving on. Scanning is useful, but it is only one control. A practical Azure DevSecOps implementation also covers identity, secret handling, permissions, dependency risk, artifact integrity, and production access.

Secrets should not be stored in YAML variables or repository files. Azure Key Vault can hold connection strings, certificates, and application secrets, while pipeline access should be granted through a controlled service connection or managed identity pattern where supported. Service connections should avoid broad subscription-owner permissions; in many cases, resource-group-level access or workload-specific roles are more appropriate. The goal is to make the pipeline powerful enough to deploy and limited enough that a compromised pipeline cannot modify unrelated systems.

Supply chain security also belongs in the pipeline. Dependency scanning, container image scanning, secret detection, and extension review help reduce risk before release. The Azure DevOps Marketplace can extend the platform with additional security and quality tools, but each extension should be reviewed for publisher trust, permissions, maintenance, and whether it sends data outside approved boundaries. Adding an extension is an architectural decision, not just a convenience.

Policy-as-code gives security teams a repeatable way to enforce rules without relying on manual inspection. Azure Policy can deny resources in unapproved regions, require diagnostic settings, enforce tagging, or audit public network exposure. When those policies are visible during infrastructure deployment, developers receive feedback earlier and operations teams gain a clearer audit trail.

Release Safety, Rollbacks, and Feature Control

AZ-400 preparation should include what happens when a deployment is not healthy. Real delivery systems need a rollback path, a release strategy, and a way to separate deployment from user exposure. Without those controls, continuous delivery becomes a faster way to ship incidents.

Blue-green deployment keeps two production-like environments and switches traffic when the new version is ready. Canary deployment releases to a small subset first and expands only if telemetry remains healthy. Feature flags allow code to be deployed while selected functionality stays hidden or limited to certain users. Each approach changes pipeline design: blue-green requires traffic switching, canary requires progressive routing and monitoring, and feature flags require governance so old flags do not accumulate indefinitely.

Rollback planning should be explicit. For an App Service deployment, that might mean retaining the previous artifact, using deployment slots, or redeploying a known-good build. For databases, rollback is more complicated because schema and data changes may not be easily reversible. A mature lab therefore includes forward-compatible database changes, smoke tests after release, and a documented decision point for rollback or roll-forward.

Measuring Outcomes with DORA Metrics

DevOps is easier to improve when the team measures the delivery system rather than relying on opinion. The four DORA metrics are lead time for changes, deployment frequency, change failure rate, and mean time to restore service. In Azure DevOps, those measurements can be approximated by combining repository events, pipeline runs, release records, incidents, and work item data.

Azure Boards can track work from idea to deployment when commits and pull requests are linked to work items. Pipeline history shows deployment frequency and failed deployment attempts. Azure Monitor and Application Insights can indicate whether a release caused errors, latency, or availability issues. Incident records then help calculate restoration time after a production problem.

The practical insight is that metrics need definitions before dashboards. A team must agree what counts as a deployment, what counts as a failed change, when lead time starts, and when service is considered restored. Otherwise, the numbers become inconsistent and hard to trust. For AZ-400 candidates, this connects instrumentation and agile planning to the core DevOps goal: improving the flow of safe, valuable change.

Where AZ-400 Preparation Becomes Work-Ready

Effective AZ-400 preparation should leave a professional with a working delivery system, not only a set of definitions. The most useful study project includes source control policies, YAML pipelines, environment approvals, infrastructure as code, Key Vault integration, policy checks, release strategies, and monitoring that can explain production health after deployment.

Readynez can support structured AZ-400 preparation, but the durable value comes from building and explaining these systems end to end. A practical next step is to choose one small Azure workload and implement the full path from pull request to monitored production release, then revisit each design decision against the AZ-400 skills outline.

FAQ

How should Azure DevOps tools be used when preparing for AZ-400?

They should be used as a connected delivery platform rather than as separate features to memorise. A strong lab links Azure Boards work items to commits and pull requests, runs Azure Pipelines from YAML, deploys to protected environments, and captures evidence through test results, approvals, and monitoring.

What is the most important Azure Pipelines skill for AZ-400?

The most useful skill is designing a multi-stage YAML pipeline that reflects real promotion from build to test to production. Candidates should understand triggers, variables, artifacts, test publication, deployment jobs, environments, approvals, and the difference between pipeline logic in YAML and controls configured on Azure DevOps environments.

Should AZ-400 candidates use Bicep or Terraform for labs?

Either can work if the lab demonstrates infrastructure as code, review, deployment, and governance. Bicep is well aligned with Azure-native resource deployment and policy integration, while Terraform is useful where multi-cloud tooling or established module ecosystems matter. The important point is to show repeatable infrastructure changes through a pipeline, not manual portal configuration.

How does DevSecOps appear in a practical AZ-400 project?

DevSecOps appears through several controls working together: secrets in Azure Key Vault, least-privilege service connections, dependency and container scanning, branch policies, approval checks, and Azure Policy enforcement. A scanner alone is not enough if the pipeline can still expose secrets or deploy resources outside approved governance rules.

How can the Azure DevOps Marketplace improve delivery workflows?

The Azure DevOps Marketplace can add extensions for security scanning, reporting, testing, deployment, and integrations with other systems. Teams should evaluate extensions carefully, especially permissions, publisher trust, maintenance activity, and data handling, because extensions become part of the delivery and security model.