Microsoft AZ-400: Security, Compliance and DevSecOps — Study Guide

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Part of the Microsoft DevOps Engineer Expert AZ-400 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Security, compliance, and DevSecOps in Azure-focused delivery pipelines demand shifting risk detection to the earliest possible stages, enforcing policy continuously, and automating evidence collection. Effective implementations unify application security testing (SAST/DAST/SCA), secrets governance, infrastructure-as-code (IaC) scanning, and regulatory controls into the CI/CD lifecycle. In Azure DevOps and GitHub, this means running analyzers on every pull request, gating merges with quality thresholds, deploying with least-privilege identities that retrieve time-bound secrets from Azure Key Vault, and continuously monitoring posture with Microsoft Defender for DevOps and Defender for Cloud. The goal is not only to find issues, but to prevent unsafe changes from reaching protected resources, prove compliance through audit trails, and sustain secure velocity.

Shift-left security, OWASP Top 10 mitigations, and pipeline hardening

Shift-left security starts with PR-time SAST and SCA, augmented by secrets scanning and targeted DAST before promotion. SAST surfaces code-level vulnerabilities such as injection points, unsafe deserializers, and missing output encoding. Integrate SonarQube/SonarCloud or GitHub code scanning (e.g., CodeQL) to analyze every change set; decorate pull requests with issues tied to specific lines; and enforce quality gates that fail the build when vulnerability or coverage thresholds are not met. Focus SAST on OWASP Top 10 classes:

• Injection: mandate parameterized queries/ORM usage, validate/normalize input, and ban dynamic SQL/string concatenation. Enforce via SAST rulesets and unit tests that assert use of vetted data access helpers.
• Cross-Site Scripting (XSS): require output encoding and Content Security Policy. SAST taint analysis should track untrusted input to sinks (innerHTML, Response.Write).
• Cross-Site Request Forgery (CSRF): enforce anti-forgery tokens and SameSite cookies. Pipelines can run framework analyzers to assert middleware/settings are enabled.
• Insecure Deserialization: disallow unsafe binary/XML serializers, limit allowed types, and prefer JSON serializers configured to safe defaults. SAST checks and dependency policies prevent use of known-unsafe libraries.

DAST validates running builds in a staging environment. Automate OWASP ZAP or equivalent as a pipeline job post-deploy to non-production, using authenticated scans and a ruleset tuned to your app profile. Gate promotion on a vulnerability baseline: block on newly introduced High/Critical findings and persist accepted exceptions with expiry.

Software Composition Analysis (SCA) detects vulnerable third-party packages before merge. Use Dependabot to raise version-bump PRs and OWASP Dependency-Check to produce SBOMs and CVE reports in CI. Enforce license compliance by defining allow/deny lists (e.g., deny copyleft for proprietary products) and failing builds that include disallowed licenses. Secrets scanning must run on commit and in CI: adopt GitHub Advanced Security secret scanning or integrate Gitleaks/Microsoft Security DevOps to catch hardcoded credentials, tokens, and keys; block the merge when a secret pattern is detected and rotate affected credentials.

Pipeline hardening is non-negotiable. Lock down branch protections, require PR reviews, and enforce status checks for SAST/SCA/DAST. In Azure Pipelines, use protected resources, environment approvals and checks, and required templates to standardize security stages. Prefer short-lived, least-privilege tokens; avoid static credentials entirely with workload identity federation. Restrict self-hosted agents to private networks, scope their identities minimally, and disable script injection by enforcing templates that disallow arbitrary script steps for untrusted repositories.

Secrets, identities, Azure Key Vault, and certificate rotation

Azure Key Vault is the authoritative store for secrets, keys, and certificates. Integrate it directly with CI/CD to eliminate plaintext secrets:

• Pipeline secrets: in Azure DevOps, link a variable group to a Key Vault using a service connection scoped to only required secret names. Secrets are retrieved at runtime and masked in logs. In GitHub Actions, use azure/login with federated identity to obtain tokens and call Key Vault; avoid storing client secrets in repository settings.
• Managed identity access: whenever possible, let workloads and deployment agents authenticate with Microsoft Entra ID using managed identity or workload identity federation so no secrets are stored. Scope Key Vault access using RBAC or access policies following least privilege (get/list only for specific secret versions; no purge/delete).
• Certificate rotation: store TLS/MTLS certs in Key Vault Certificates with auto-rotation via integrated CAs. Configure consuming services (App Service, Application Gateway, AKS Ingress via CSI Secrets Store) to reference Key Vault so renewed certs are picked up without redeploy. Use Event Grid on Key Vault certificateNearExpiry events to trigger an automation runbook or Function that validates bindings and warms caches. Track certificate version usage in deployment manifests; pin versions when needed and deliberately roll forward during maintenance windows.

Harden Key Vault with private endpoints, firewall rules, purge protection, soft-delete, and logging to Log Analytics or storage for audit. Deny cross-tenant access unless explicitly justified, and routinely rotate access for break-glass accounts.

Dependencies, containers, IaC, and compliance as code

Dependency scanning must handle both security defects and licensing. Dependabot continuously proposes secure updates; use dependency review policies to block PRs that introduce vulnerable versions. OWASP Dependency-Check (or ecosystem-native tools like npm audit, pip-audit) should run in CI to generate SBOMs (CycloneDX/SPDX) and fail the build when severity thresholds or license rules are violated. For advanced license governance, pair with an SCA platform capable of legal policy enforcement and remediation workflows.

Container image security begins in CI and continues in the registry and runtime:

• Trivy: run as a pipeline step to scan Dockerfiles and built images for OS/package CVEs and misconfigurations; break the build on Critical/High findings. Enforce minimal base images and rootless containers.
• Azure Container Registry vulnerability scanning: enable Microsoft Defender for Containers to scan images on push/import and on a schedule. Surface findings in Defender for Cloud, export to work items, and enforce deployment gates that block images with unresolved Critical/High issues.
• Defender for Containers: extend protection to AKS/ECS/Kubernetes with runtime threat detection, kube-bench-style checks, and admission control. Use policy to only pull from trusted ACRs signed with Notation/ACR content trust and verify signatures in CI and at cluster admission.

IaC security ensures cloud resources are provisioned safely by default:

• Checkov and tfsec: scan Terraform and Kubernetes manifests for insecure configurations (public storage, open security groups, missing encryption). Fail builds on severity thresholds; baseline existing debt to focus on new/changed resources.
• ARM/Bicep linting: enable the Bicep linter (bicepconfig.json) and ARM Template Tool Kit (arm-ttk) to enforce rules for tagging, HTTPS-only endpoints, customer-managed keys, and diagnostics settings. Combine with what-if deployments to detect drift before apply.

Compliance as Code uses Azure Policy and Defender for Cloud to continuously enforce and report on controls:

• Assign Azure Policy initiatives aligned to CIS, NIST, ISO 27001, or internal baselines; select effects like Deny for critical guardrails (e.g., public IPs on databases), DeployIfNotExists for diagnostics, and Audit for observability. Store policy definitions as versioned artifacts, test with policy-as-code pipelines, and promote via pull requests.
• Use Defender for Cloud’s regulatory compliance dashboards to visualize control conformance across subscriptions and management groups. Integrate with Azure Monitor and export evidence to Log Analytics or Event Hubs for SIEM ingestion.
• Maintain audit trails: Azure Activity Logs for policy events and assignments, Resource Graph for compliance queries, Azure DevOps/GitHub audit logs for repo and pipeline changes, and release evidence captured automatically as pipeline run artifacts.

SonarQube/SonarCloud, pipeline security, and Microsoft Defender for DevOps

SonarQube/SonarCloud provides enforceable quality gates that align engineering quality with security. Adopt “Clean as You Code” by setting gates on new code: minimum code coverage on new/changed lines (e.g., 80%+), zero new Critical vulnerabilities or blocker code smells, and low duplication. Failing the gate must fail the pipeline. Publish coverage from test frameworks (JaCoCo, Cobertura, VSTest) and tune quality profiles per language to include security hotspots and OWASP-aligned rules. Track technical debt ratios and remediation times; report trends to drive team accountability.

Pipeline security hinges on least-privilege service connections, protected resources, and comprehensive secret masking:

• Service connections should use workload identity federation or managed identities with narrow scopes (subscription/resource group, specific ACR, or Key Vault). Enable approvals and checks on service connections and environments so owners must authorize usage. Limit “Use” permissions to trusted pipelines; disable “Grant access permission to all pipelines.”
• Protected resources in Azure DevOps guard service connections, variable groups, secure files, and environments. Require checks such as approvers, business-hours windows, Azure Monitor query results, and external REST policy engines. Treat them as gates before deployments and as preconditions for sensitive reads (e.g., retrieving production secrets).
• Secret masking must be enforced across all logs; restrict variable expansion in scripts; avoid echoing secrets; and prefer system.accessToken-scoped APIs over storing PATs. Periodically scan pipeline logs for accidental secret leaks and rotate on detection.

Microsoft Defender for DevOps unifies repository and pipeline security posture across GitHub and Azure DevOps. Connect organizations/projects to Defender for Cloud to ingest code, secret, IaC, and dependency risk signals and present consolidated recommendations. It correlates findings to owners, supports suppression workflows with expiry, and measures adoption of branch protections, required reviewers, and status checks. Pair Defender for DevOps with the Microsoft Security DevOps task/action to orchestrate multiple analyzers (e.g., Semgrep, Trivy, tfsec, Gitleaks, Bandit) in one step and publish SARIF to code scanning. Use Defender for Cloud to create governance initiatives that track and enforce DevOps best practices (e.g., secret scanning enabled, required review count ≥ 2, non-admin merges disabled), elevating repository hygiene to an auditable control.

Practical Problem Scenario

Spotify needs to standardize secure delivery for a new AKS-hosted microservice stack spanning .NET and Node.js, with repos in GitHub Enterprise Cloud and deployments through Azure DevOps multi-stage YAML pipelines. The challenge is to stop vulnerable dependencies and misconfigured infrastructure before merge, eliminate static credentials, and block promotion of images with critical CVEs, while producing auditable compliance evidence.

1. Enforce PR-time SAST/SCA and secrets scanning

• Choose SonarCloud for multi-language SAST with PR decoration and quality gates; set new-code coverage ≥ 80% and zero new Critical vulnerabilities. Dependabot is enabled to auto-PR safe upgrades and GitHub dependency review blocks PRs introducing known CVEs. GitHub Advanced Security secret scanning plus Gitleaks in CI ensures defense-in-depth for credential exposure.

2. Add authenticated DAST before promotion

• Use OWASP ZAP in a pipeline stage targeting the staging environment with seeded test accounts. A release check blocks production if new High/Critical issues appear. ZAP is chosen for OWASP-aligned coverage and easy CI automation.

3. Secure identities and secrets with Key Vault and workload identity federation

• Replace service principal client secrets with Microsoft Entra workload identity federation for service connections, removing stored secrets. Pipelines retrieve runtime secrets and DB credentials from Azure Key Vault via least-privilege get/list permissions. This eliminates long-lived credentials and centralizes rotation.

4. Implement certificate automation

• Store ingress and mTLS certificates in Key Vault with auto-rotation. AKS pulls certs via the Secrets Store CSI driver to avoid copying secrets into Kubernetes. Event Grid triggers a Function to verify bindings after renewal. This design minimizes downtime and human error in rotation.

5. Harden containers and registries

• Run Trivy in CI to scan Dockerfiles and built images; fail on Critical/High. Push only clean images to ACR. Enable Defender for Containers to scan ACR on push and periodically, surfacing findings to Defender for Cloud. Policy-backed release checks block deploying images with unresolved Critical/High CVEs. Trivy provides fast feedback; Defender adds continuous, registry-native assurance.

6. Scan IaC and lint Bicep/ARM

• Use Checkov and tfsec to scan Terraform and Helm charts; enforce tagging, encryption, and network controls. Bicep linter and ARM TTK run in CI for Azure-native templates. Failing checks block merges; baselines limit noise to new/changed resources. These tools are chosen for broad rule coverage and strong Azure support.

7. Codify compliance and evidence

• Assign Azure Policy initiatives for CIS Azure and company baselines; enforce Deny on critical guardrails and DeployIfNotExists for diagnostics. Feed results to Defender for Cloud’s regulatory dashboards. Export Activity Logs and Defender recommendations to Log Analytics for immutable evidence. Policy provides continuous enforcement; dashboards give audit-ready views.

8. Lock down pipelines and protected resources

• Restrict service connections to scoped subscriptions/resource groups; require environment approvals and Azure Monitor query checks for production. Protect variable groups and secure files; mask all secrets. Harden self-hosted agents with private networking. These features reduce blast radius and ensure human-in-the-loop for high-risk actions.

9. Consolidate posture with Microsoft Defender for DevOps

• Connect GitHub org and Azure DevOps project to Defender for Cloud to aggregate code, secret, and IaC findings and track adoption of repository protections. Use the Microsoft Security DevOps action/task to orchestrate Semgrep, Trivy, tfsec, and Gitleaks with SARIF publishing, ensuring standardized scanning across services. This centralizes risk management and remediation workflows.

Each tool/feature is selected for earliest feasible detection, automatic enforcement, and auditability: SonarCloud and ZAP gate code and runtime risks; Dependabot and Trivy accelerate safe updates; Key Vault and identity federation remove static secrets; Checkov/tfsec and Azure Policy prevent drift; protected resources and approvals control blast radius; Defender for DevOps and Defender for Cloud deliver unified, actionable posture management.

← Release Management and Deployment Strategies · All domains · Testing Strategy and Quality Engineering →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →