Azure DevOps Pipelines and GitHub Actions
AZ-400 centres on CI/CD implementation. Azure DevOps Pipelines: defined in YAML (azure-pipelines.yml in the repository root). Pipeline structure: trigger (branch and path filters), pool (agent — Microsoft-hosted agent pools for Ubuntu, Windows, macOS, or self-hosted agents for private network access), stages (sequential or parallel), jobs (run on a single agent — parallel jobs on different agents), steps (individual tasks or scripts). Key tasks: AzureCLI@2 (run Azure CLI commands with service connection authentication), TerraformInstaller + TerraformTaskV4 (run Terraform init/plan/apply), DotNetCoreCLI@2 (build, test, publish .NET applications), PublishPipelineArtifact (store build outputs for later stages), DownloadPipelineArtifact (retrieve stored artifacts). Environments: Azure DevOps Environments gate deployments with approvals, checks (branch policy, required reviewers), and deployment history. GitHub Actions: .github/workflows/*.yml, triggered by on: push/pull_request/schedule/workflow_dispatch. Uses composite actions and reusable workflows for shared logic across repositories.
Infrastructure as Code: Bicep and ARM Templates
Azure-native IaC tools for AZ-400. Bicep: domain-specific language that compiles to ARM JSON — cleaner syntax than raw ARM, first-class support in Azure DevOps. Bicep advantages over ARM: no verbose JSON structure, type-safe parameters with decorators, modules for reusable components, output values, string interpolation. Bicep modules: separate .bicep files called from a parent — scope can be resource group, subscription, management group, or tenant. ARM template structure: $schema, contentVersion, parameters, variables, resources, outputs — functions available: resourceGroup(), subscription(), reference(), concat(), uniqueString(). Deployment modes: Incremental (add/update resources in template, ignore resources not in template — safer, default), Complete (deploy exactly what is in template, delete resources not in template — destructive, use carefully). Template spec: store ARM templates in Azure as a versioned resource — share and deploy consistently across teams. What-if: preview ARM or Bicep deployment changes without applying — similar to Terraform plan.
DevSecOps and Supply Chain Security
AZ-400 integrates security into DevOps. Shift left security: integrate security testing early in the pipeline rather than at the end. SAST (Static Application Security Testing): scan source code before build — Checkmarx, SonarQube (integrated as pipeline task), GitHub Advanced Security (CodeQL for code scanning, secret scanning, dependency review). DAST (Dynamic Application Security Testing): test the running application — OWASP ZAP, Burp Suite. Dependency scanning: identify vulnerable open-source libraries — Dependabot (GitHub), Azure DevOps OWASP Dependency Check task. Container security in pipelines: Trivy, Prisma Cloud, or Microsoft Defender for containers to scan images before push to registry. Software supply chain security: SBOM (Software Bill of Materials) generation, Sigstore (Cosign) for container image signing, attestation policies (only deploy images signed by the build pipeline). Policy enforcement: Azure Policy as Code (deploy policies via pipeline — manage as YAML files in Git, apply via Azure DevOps pipeline with az policy commands or Terraform azurerm_policy_definition resources).
Site Reliability Engineering Practices
AZ-400 covers SRE concepts applied to Azure. SLOs (Service Level Objectives): define target reliability (e.g., 99.9% request success rate, p99 latency < 500ms) — measured using SLIs from Application Insights or Azure Monitor. Error budgets: the allowed downtime before missing the SLO — (1 - SLO) x time period. When error budget is exhausted, new deployments are paused until reliability is restored. Feature flags: deploy code to production without enabling it — Microsoft Feature Management library for .NET, LaunchDarkly. Gradual rollout: combine feature flags with deployment rings (canary users > 5% > 20% > 100%). Chaos engineering: Azure Chaos Studio introduces faults (VM shutdown, network partition, CPU pressure) to validate system resilience. Toil reduction: automate repetitive operational tasks — identify toil (manual, repetitive, automatable, tactical work that grows with service scale) and systematically eliminate it through automation. Incident management: integrate Azure Monitor alerts with PagerDuty or Azure DevOps work items for tracked incident response.