AZ-400 exam questions on security scanning focus on which tool belongs at which pipeline stage. The core pillars: differences between SAST, SCA, and DAST; GitHub Advanced Security (GHAS) components; Dependabot's two modes; and the Microsoft Defender for DevOps connector. Shift-left — embedding security from the first commit rather than treating it as a final gate — is the design principle behind nearly every question in this domain.
Security Scanning Categories — SAST, DAST, SCA, IaC
Think of airport security. Checked luggage goes through X-ray at check-in, carry-ons are screened at the gate, and flight attendants watch the cabin throughout. Each checkpoint targets a different threat at a different stage. DevSecOps scanning works the same way: no single tool catches everything, and each category has its own place in the pipeline.
SAST (Static Application Security Testing): Analyzes source code without executing it. Detects SQL Injection, XSS, hardcoded secrets, and code-level vulnerabilities. Runs at build time. CodeQL is the primary example. DAST (Dynamic Application Security Testing): Sends real HTTP requests to a running application to find vulnerabilities from an attacker's perspective. Requires a deployed staging environment — placed after the CD stage. SCA (Software Composition Analysis): Analyzes known CVEs and license compliance in open-source libraries. Parses , , and similar files against the GitHub Advisory Database. Dependabot is the primary example. IaC scanning: Finds misconfigurations in ARM, Bicep, Terraform, and Kubernetes manifests before deployment — open ports, disabled encryption, over-permissive roles. Checkov, tfsec, and Template Analyzer cover this. Container image scanning: Detects CVEs in OS packages and app dependencies inside a Docker image. Needed at both image push time and container runtime.
SAST covers flaws in code you wrote; SCA covers vulnerabilities in libraries you imported; DAST covers runtime weaknesses that only surface in a live application. They are complementary, not substitutes.
!4 security scanning categories: SAST, DAST, SCA, IaC
GitHub Advanced Security — CodeQL and Secret Scanning
Picture a food manufacturing plant with three inspection stages. GitHub Advanced Security (GHAS) layers security the same way. CodeQL scans the code itself, secret scanning watches for leaked credentials, and dependency review checks each new library introduced via pull request.
CodeQL is GHAS's core SAST engine. It converts source code into a relational database and searches for vulnerability patterns with a query language called QL. The workflow runs Init → Autobuild → Analyze: Init creates the CodeQL database; Autobuild compiles languages like Cand Java; Analyze runs query packs and outputs a SARIF file. One file activates the whole thing. Results land in the GitHub Security tab as code scanning alerts and as inline PR comments.
A common exam trap: PR code scanning comparison requires CodeQL results on the base branch (). Without them, CodeQL returns . Fix: add a push trigger on the default branch to run CodeQL once and establish a baseline.
Secret scanning detects committed credential patterns. The secret scanning partner program watches public repos for tokens from 100+ partner providers and immediately notifies the issuer via API, triggering automatic revocation. Push protection (GHAS-exclusive) blocks the push server-side before the credential lands. Exam distinction: → partner program; → push protection.
Dependabot — Security Updates and Version Updates
Two types of car maintenance: a safety recall brings an urgent call from the manufacturer (security updates); the annual inspection runs on a fixed calendar (version updates). Dependabot manages both independently — confusing them is a common exam mistake.
Dependabot alerts fire when a new CVE is registered or updated in the GitHub Advisory Database or NVD. A push or pull request creation is not a trigger. Severity follows CVSSv3: Critical, High, Medium, Low.
Security updates auto-open a PR upgrading the vulnerable package, which triggers CI to verify compatibility. Version updates follow a schedule regardless of security status — ecosystems (npm, Maven, NuGet, pip) and cadence (daily, weekly) are defined there. Both modes are enabled independently.
Without , dozens of PRs pile up and teams start ignoring all Dependabot PRs — including critical fixes. Weekly cadence and scoped dependencies keep the signal healthy.
Microsoft Defender for DevOps and Container Scanning
Imagine a city-wide CCTV network feeding into one control room. Microsoft Defender for DevOps gives the same consolidated view over code repositories, pipelines, and cloud infrastructure — surfaced in the Defender for Cloud dashboard. Connect an Azure DevOps or GitHub organization through the DevOps Security connector, then add the Microsoft Security DevOps (MSDO) task to the pipeline.
MSDO bundles Credential Scanner (exposed credentials), Binskim (binary analysis), and Template Analyzer (ARM and Bicep misconfiguration detection). All findings flow to Defender for Cloud. Microsoft Defender for Containers adds two-phase coverage: a CVE scan fires when an image is pushed to Azure Container Registry (ACR); AKS runtime is scanned continuously for vulnerabilities in running containers.
GHAS owns code and repository-level security — CodeQL, Dependabot, secret scanning. Defender for Cloud owns cloud infrastructure and runtime security. The Defender for DevOps connector ties them together into one view.
Pipeline Integration — Gates, Fail-Fast, and Baselines
A layered building access system: lobby entry needs only a badge tap; the server room demands a fingerprint; classified areas are blocked entirely. Security scan gates in a pipeline work the same way — severity determines the gate level.
Recommended pattern: Critical and High fail the build immediately (fail-fast). Medium produces a warning but proceeds. Low and informational land in the report only. CodeQL, SonarCloud, and Mend Bolt all support severity-threshold build-failure policies.
Baseline matters when introducing scanning to a legacy codebase. Blocking every pre-existing low-severity finding paralyzes the team. GitHub code scanning's mode fixes this: only findings from new commits trigger a block; the backlog is handled separately. For Azure Policy, add the task after the deployment step in a release pipeline to trigger on-demand evaluation — bypassing the default 24-hour cycle. Audit logs non-compliance; Deny blocks the deployment.
Exam Key Takeaways
"Code-level vulnerabilities, no execution" -- SAST (CodeQL) "Running app, HTTP requests, attacker perspective" -- DAST (OWASP ZAP) "Open-source dependency CVEs and license compliance" -- SCA (Dependabot, Mend Bolt) "Block credential-containing push before it lands" -- GHAS Push Protection "Notify issuer and auto-revoke after commit" -- Secret Scanning Partner Program "Triggered by Advisory DB update, not by push or PR" -- Dependabot alerts "Keep dependencies current, security-unrelated" -- Dependabot version updates "ARM / Bicep / Terraform misconfiguration before deploy" -- Template Analyzer / Checkov / tfsec "ACR push + AKS runtime, two-stage container scan" -- Microsoft Defender for Containers "Azure DevOps + GitHub security results, single dashboard" -- Microsoft Defender for DevOps "Signed image / Content Trust / ACR" -- ACR Premium SKU only "Early feedback at PR stage, where to place SAST" -- Build pipeline (not Release pipeline)
Shift-left = security scanning from the first commit onward; GHAS = the integrated security platform at the repository level.