Azure Learning

compliance-gate

Properties2
tagsdevops, security, gates, compliance, pipeline
aliasescompliance gate, quality gate, security gate, policy gate, build gate

2 min read

Compliance gate

What it is

A compliance gate (a.k.a. quality/security gate) is an automated checkpoint inside the continuous integration/delivery pipeline that blocks the build or release until defined policies are satisfied — e.g. no critical vulnerabilities, SAST passes, code coverage ≥ threshold, no secret/banned-license violations. It makes compliance an enforced, continuous condition of shipping, not a manual audit.

Why it exists

Without gates, “we did security checks” doesn’t translate to “no known-unsafe code shipped.” A gate converts scan results into an objective go/no-go decision: if a critical finding exists, the artifact cannot proceed, forcing the team to fix it before it reaches the next (more expensive) stage. This is how shift-left security becomes enforced rather than advisory.

Key ideas

  • Policy-authored — the rules (“fail on critical vuln”, “no GPL code”, “no secret in a commit”) are codified and, ideally, version-controlled (policy as code).
  • Integrates scan outputs — consumes results of SAST, DAST, SCA/vulnerability scanning, secret scanning, unit/coverage tests.
  • Fails fast — gate evaluated in the pipeline; on failure the run is blocked/failed with who-and-why, driving the fix close to the change.
  • Evasion responsibility — findings must be triaged (e.g. approved baseline/exceptions) or the gate stays red; prevents silent offset.
  • Distinct from deployment gates — deployment gates pause a release stage (approval/metrics around promotion); a compliance gate runs on build/quality criteria about the artifact. In AZ-400 they often layer: quality gates build-time, deployment gates release-time.

How it fits

The enforcement point that makes the whole DevSecOps approach real: every scanner feeds a gate, and the gate decides “ships / doesn’t ship.” It sits in the build phase of the pipeline, upstream of release, and pairs with compliance monitoring for runtime.

Exam notes

  • Gate = automated, pipeline-blocking, policy-driven go/no-go on scan/test results — memorize “fails the build/release”.
  • Types of criteria: vulnerabilities (critical=block), SAST/DAST findings, code coverage, secret scanning, license policy.
  • Don’t confuse with deployment gates (release-stage approvals/monitoring) — quality vs deployment.
  • Exam scenario: an org wants “no vulnerable or licensed problem code to ship” → configure a quality/compliance gate in the build.

dev-sec-ops · static-analysis · dynamic-analysis · dependency-vulnerabilities · software-composition-analysis · secret-scanning · deployment-gate

📘 Source: Microsoft Learn — Compliance Gate

Graph View

Backlinks