AZ-400 Secure CD

Implement secure continuous deployment

4-secure-cd-moc

Implement Secure Continuous Deployment — MOC

MS Learn path: Implement secure continuous deployment · Shipping fast without compromising security.

Planned concepts

Azure Key Vault/secret stores · variables-groups · dynamic-approval-checks · deployment security · service connections · environment-approvals · best-practice-secrets

Planned modules

Secure CD overview · Manage secrets with Key Vault · Variable groups & libraries · Approvals & gates

Modules in this path

Skills

Secure CD, secret handling, approvals & gates.

Practice questions

secure-cd-overview

Implement Secure Continuous Deployment — Overview

MS Learn path: Implement secure continuous deployment — module 1.

Overview

Frames the path: shipping continuously while keeping the release pipeline secure and governed. Introduces the pillars — secret handling, least-privilege Azure access, and per-environment approvals/gates — that the later modules detail.

Units

  • Continuous deployment and its security surface
  • Preventing secrets in pipelines
  • Azure access for pipelines (service connections)
  • Environments, approvals, and gates as release guards

Concepts introduced

Key terms & commands

  • CD releases validated build artifacts; secure CD adds governance.
  • Service connection (azureSubscription:) is how pipeline tasks authenticate to Azure.
  • Environment checks (approvals) gate stages before production.
  • Azure DevOps: key vault → variable group → pipeline reference at runtime.

Hands-on

⚠ verify — add a hands-on step: create a Key Vault, a linked variable group, and a multi-stage pipeline with a prod approval.

Exam focus

  • Recall the pillars of secure CD: secrets hygiene, least-privilege connections, approvals/gates.
  • CD is the “what”; secure CD is the “how governed”.
  • Know that secrets are referenced, never embedded.

secure-cd · secrets-management · subscription-connection · Path MOC

manage-secrets-keyvault

Manage Secrets Using Azure Key Vault

MS Learn path: Implement secure continuous deployment — module 2.

Overview

Where to hold the credentials a pipeline needs. Covers Azure Key Vault as the centralized secret store, how to grant the pipeline access, and how to surface secrets as variables so they’re consumed by reference — never embedded.

Units

  • Why a dedicated secret store (vs files/repo)
  • Azure Key Vault: secrets, keys, certificates, access policies
  • Granting a pipeline/service connection access to the vault
  • Exposing vault secrets to pipelines as variables

Concepts introduced

Key terms & commands

  • az keyvault create/set/secret/list — create vault, store a secret.
  • Access policy (or RBAC) on the vault controls who may read/write secrets.
  • Secret-variable: pipeline variables whose values are masked and never returned by the API.
  • Link a variable group to the vault so each variable maps to a named secret, fetched at runtime.

Hands-on

⚠ verify — add: create a Key Vault, add a secret, create a Key Vault-linked variable group, consume it in a pipeline variables: - group.

Exam focus

  • Secrets live in Key Vault; pipelines reference by variable group, not embed.
  • Runtime fetch enables rotation without a rebuild.
  • Access is governed by access policies/RBAC and restricted to the service connection (least privilege).

secrets-management · variables-groups · best-practice-secrets · secure-cd · Path MOC

variable-groups-and-libraries

Variable Groups and Libraries

MS Learn path: Implement secure continuous deployment — module 3.

Overview

Reusing configuration across pipelines and runs. Covers the Libraries hub, variable groups (plain and Key Vault–linked), and sharing non-secret settings centrally without duplicating them in YAML.

Units

  • What problem variable groups solve
  • Plain vs Key Vault–linked variable groups
  • Referencing groups from pipelines and releases
  • Securing groups (protected, pipeline-scoped) and value limits

Concepts introduced

Key terms & commands

  • variables: - group: <name> — consume a variable group in YAML.
  • Library: the Azure Pipelines hub where groups and secure files live.
  • Project vs pipeline scope: pipeline-scoped groups can be consumed org-wide and can be protected.
  • Plain group = visible non-secrets; Key Vault-linked group = secrets fetched at runtime.

Hands-on

⚠ verify — add: create a variable group in Libraries, reference it from a YAML pipeline, and link one to Key Vault.

Exam focus

  • Variable groups = shared variables, single source of truth across pipelines.
  • Key Vault-linked group = variables resolve to secrets at runtime (rotation-friendly).
  • Protected/pipeline-scoped groups restrict who can use them (security).

variables-groups · secrets-management · secure-cd · Path MOC

approvals-and-gates

Approvals and Deployment Gates

MS Learn path: Implement secure continuous deployment — module 4.

Overview

The human and automated guardrails on a CD pipeline. Covers environments, the checks attached to them (approvals, branch protection, invoke REST/metrics gates), and dynamic approval targeting so the right approver is reached at the right time.

Units

  • Environments as deployment targets with checks
  • Approval checks: pre-deployment human sign-off
  • Dynamic approval targeting (choose approvers at runtime)
  • Additional checks & gates: branch policy, metrics/work-item, invoke REST

Concepts introduced

Key terms & commands

  • Environment with an Approval check; stage targets environment: prod.
  • Dynamic approvers resolved from variables/groups/fields at run time.
  • Gates = automated: watch Azure Monitor metrics/logs or work items; pass/fail over a window with retries.
  • Approvals = who says yes; gates = does health say yes.

Hands-on

⚠ verify — add: create an environment, attach an approval check (dynamic approver), and add a metrics/work-item gate.

Exam focus

  • Approvals & gates attach to environments, evaluate before the stage runs (pre-deployment).
  • Typical: approval on production only; dynamic targeting for on-call/branch-aware routing.
  • Post-deployment monitoring gates drive canary/ring expansion.

environment-approvals · dynamic-approval-checks · deployment-gate · secure-cd · Path MOC

Securing the pipeline

secure-cd

Secure Continuous Deployment

What it is

Secure continuous deployment (secure CD) is continuous delivery/deployment run with security and governance baked into every release stage: secrets are centralized, connections are least-privileged, and each environment keeps human/automated checks before production. It’s the “ship often, but safely and accountably” discipline for release pipelines.

Why it exists

Continuous deployment removes the manual checkpoint, but automation without control is a liability — a compromised credential or a secret in a build log is a breach, and auto-releasing everywhere can cascade a bad change. Secure CD reconciles speed (automation) with safety (guards), so releasing frequently doesn’t lower the security bar.

Key ideas

  • Run deployments under governed identities: use least-privilege service principals/managed identities, scoped RBAC per environment.
  • Centralize secrets in Azure Key Vault and reference them via linked variable groups — no secrets in repo or YAML.
  • Per-environment checks & approvals: gate production behind environment approvals and deployment gates.
  • Separate identities per environment: don’t let the dev subscription identity also deploy to prod.
  • Progressive exposure: combine with canary/rings to limit blast radius and let post-deployment gates verify health.
  • Audit & observe: log everything, in case a rollout must be rolled back.

How it fits

Secure CD is the umbrella that secrets-management, variables-groups, dynamic-approval-checks, environment-approvals, service connections, and best-practice-secrets hang under. It answers “how do we automate releases without creating a back door?”

Exam notes

  • Secure CD = CI/CD + secrets hygiene + least-privilege + approvals/gates.
  • Key Vault for secrets, service connections for Azure access, environment approvals for human control.
  • Least-privilege and separation of dev vs prod credentials are core model answers.
  • Know the difference: CD automates the release; secure CD governs how that automation is permitted, secured, and checked.

cd · secrets-management · environment-approvals · deployment-gate · subscription-connection · best-practice-secrets

📘 Source: Microsoft Learn — Secure Cd

secrets-management

Secrets Management

What it is

Secrets management is the practice of securely storing, retrieving, rotating, and guarding the non-public values a deployment depends on — passwords, API keys, connection strings, certificates, service principal credentials. In Azure DevOps the canonical secret store is Azure Key Vault, referenced from pipelines via variable groups or service connection linkings.

Why it exists

Secrets are dangerous to version. A secret committed to a Git repo or baked into a pipeline definition is effectively public once anyone with read access touches it. Secrets management centralizes secrets in an audited, encrypted, access-controlled store so pipelines reference a secret instead of embedding one.

Key ideas

  • Never commit secrets to source control or embed them in YAML/definition files — reference them instead.
  • Azure Key Vault is the recommended store: encryption at rest, RBAC/access policies, audit logging, and key/cert/secret vaults.
  • Decouple secret from location: a pipeline uses a secret variable whose value never appears in plaintext logs or pipeline UI.
  • Rotation: rotate secrets on schedule and make deployments resilient to rotation (fetch fresh values per run).
  • Availability: fetch secrets at runtime/deployment time, not bake time, so rotation doesn’t force a rebuild.

How it fits

Secrets management underpins secure continuous deployment: CI/CD pipelines that connect to Azure subscriptions (service connections) or deploy external resources must authenticate, and that authentication routinely depends on stored secrets. Variable groups link pipeline variables to Key Vault secrets.

Exam notes

  • Azure DevOps has a built-in concept of secret variables (values are masked everywhere, never returned by the API).
  • Variable groups linked to Azure Key Vault let you reference Key Vault secrets as variables; the value is fetched at runtime.
  • “Lock secrets in vault, reference in pipelines” — secrets protected by RBAC, revocable on rotation.
  • Avoid “hardcoded = easy to fix later” — rotation requires reference-based auth.

secure-cd · best-practice-secrets · variables-groups · subscription-connection · environment-approvals · azure-pipelines · service-principal

📘 Source: Microsoft Learn — Secrets Management

best-practice-secrets

Best Practices for Secrets

What it is

Best practices for secrets are the proven rules for handling credentials across the software lifecycle: where to store them, what to avoid, and how to reference them so they never end up in source control, logs, or build output. They’re the practical guardrails that make secure continuous deployment actually secure.

Why it exists

The highest-probability security failure in CI/CD is secret leakage: a .env committed, a key printed in a build log, a token pasted into YAML. Because leaked secrets are near-impossible to un-leak, the discipline is prevention — treat every secret as if someone will read your repo and your logs.

Key ideas

  • Never commit secrets to Git or paste them in pipeline YAML/UI definitions → reference them instead.
  • One central store — Azure Key Vault — with RBAC/access policies and audit logging; don’t scatter secrets in custom files.
  • Use secret variables / variable groups linked to Key Vault, fetched at runtime, so rotation doesn’t require a rebuild or a pipeline edit.
  • Never print secrets to logs; Azure DevOps masks secret variable values automatically.
  • Least privilege + separation: distinct credentials per environment/app; revoke what’s not needed.
  • Rotate on schedule and on suspected leak; prefer workload identity federation / managed identities to avoid storing secrets at all.
  • Audit & restrict: who can use a secret, which pipelines/agents can access it (protected, pipeline-scoped access).

How it fits

The best practices are the how behind linked variable groups and Key Vault, and they connect to identity via service connections. Adopt them wholesale for secure CD and for validating pipelines in security/compliance reviews.

Exam notes

  • Core rule to quote: secrets in a store, referenced at runtime, never in source/YAML/logs.
  • Azure DevOps secret variables are masked everywhere and not returned by the API.
  • Key Vault–linked variable group + runtime fetch = rotation-friendly.
  • Prefer federated/managed identities to minimize stored secrets.
  • Separate dev vs prod credentials; least-privilege, audit, rotate.

secrets-management · secure-cd · variables-groups · subscription-connection · environment-approvals

📘 Source: Microsoft Learn — Best Practice Secrets

variables-groups

Variable Groups

What it is

A variable group is a set of variables stored once in Azure DevOps and shared across many pipelines/pipeline runs, rather than redefined per pipeline. Variable groups live under the Libraries hub and can be plain variables or Azure Key Vault–linked (each group variable maps to a secret value fetched at runtime).

Why it exists

Deploying to multiple environments (dev, test, prod) or many pipelines means the same connection strings, endpoints, and settings are needed everywhere. Duplicating them per pipeline causes drift and secrets sprawl. Variable groups give a single source of truth — one place to store, approve, and update values that many releases consume.

Key ideas

  • Plain variable group: stores non-secret values (server names, flags, URLs) — values visible in the UI.
  • Key Vault–linked variable group: each variable pulls its value from a named Azure Key Vault secret at runtime → good for secrets, enables rotation without editing the group.
  • Library scope: a group can be project-scoped (default) or pipeline-scoped (can be consumed across the whole org when protected).
  • Reference it via YAML variables: - group: <name> or in a release definition’s variable section.
  • Limits: up to a certain number of variables per group; secret-variable values cannot be read back via API.
  • Permissions: groups can be secured so only authorized roles/queues can use them (approvals for protected resources apply to secrets).

How it fits

Variable groups are the mechanism that connects secret stores to pipelines: a single Key Vault-linked group means your YAML just names secrets, and the actual rotation happens in the vault. Part of secure deployment because they keep secrets out of pipeline definitions.

Exam notes

  • Two kinds: variable group (Libraries) vs individual pipeline variables — group = shared across pipelines.
  • Link a group to Azure Key Vault to reference secrets by name and fetch at runtime.
  • Use protected / pipeline-scoped groups for security so untrusted pipelines can’t read secret values.
  • Group variables referenced in YAML by - group: <groupName>.

secrets-management · azure-pipelines · secure-cd · environment-approvals · deployment-gate

📘 Source: Microsoft Learn — Variables Groups

subscription-connection

Subscription (Service) Connection

What it is

An Azure service connection (historically service endpoint) is the secure, reusable link between Azure DevOps and an Azure subscription that lets pipeline tasks (ARM deploy, Key Vault read, storage, etc.) authenticate to Azure without embedding credentials. Most commonly it’s backed by a service principal created in the target subscription and granted the minimal RBAC the pipeline needs.

Why it exists

A pipeline deploying to Azure must authenticate as something — but embedding username/password or a client secret in the repo or YAML is unacceptable. Service connections wrap an identity (service principal, managed identity, workload identity federation) plus its scope/authorization, and reference it by name in tasks (azureSubscription: $(conn)). This centralizes authentication, enables rotation, and supports least-privilege.

Key ideas

  • Approaches: create it interactively (automatic SPN creation), or provide an existing service principal (manual). Workload identity federation is the modern, secret-less option.
  • RBAC scope: the SPN is granted role assignments (e.g. Contributor, or check-scoped least-privilege) on a subscription/RG — grants the pipeline those abilities.
  • vs. managed identities: inside Azure (e.g. a VM/App Service) prefer a managed identity; from Azure DevOps use a service connection backed by a service principal.
  • Security hygiene: separate connections per environment (dev vs prod), least-privilege roles, never share the SPN’s secret in a repo — store in variable group/Key Vault if needed.
  • Resource type: an ARM connection is the special Azure Resource Manager connection type; others (Git, Docker, NuGet) are separate service-connection kinds.

How it fits

Service connections are part of secure continuous deployment: they carry the identity and authorization for the deploy tasks, while Azure Key Vault carries the application secrets. Together with environment checks they make each stage deploy under the right identity and the right human sign-off.

Exam notes

  • Also called service connection / service endpoint — the azureSubscription task parameter is a service connection.
  • Identity model = service principal + RBAC; prefer least-privilege scoped roles.
  • Workload identity federation avoids storing a client secret (no secret rotation pain).
  • Use separate connections per environment so a compromised dev connection can’t touch prod.

service-principal · rbac · secure-cd · azure-pipelines · secrets-management · environment-approvals

📘 Source: Microsoft Learn — Subscription Connection

Approvals & gates

environment-approvals

Environment Approvals

What it is

Environment approvals (specifically environment checks in Azure Pipelines) are the governance mechanism on an Environment: before a pipeline can deploy a stage that targets that environment, checks must pass. The core check is Approvals — a designated human (or group, possibly chosen dynamically) must explicitly Approve/Reject the deployment. Approval is one of several checks (others: pipeline, protected branch, business hours, custom/InvokeREST gate).

Why it exists

Even a fully automated CD pipeline shouldn’t push to production silently. Environment approvals put human accountability at the right gate: someone reviews and consents to a production deployment — while leaving everything else automatic. They turn the environment into an approval boundary so prod stays guarded without killing velocity.

Key ideas

  • Environment = a logical deployment target with ownership (owner) and checks; stages deploy to an environment.
  • Checks run before a stage that targets the environment; an Approval check schedules a review and blocks until approved/rejected.
  • Approvers can be individuals or teams; support dynamic targeting so the approver is resolved at run time.
  • Combine checks: require branch protection + approval + invoke REST / metrics gate for layered control on prod.
  • Approvals are stage/environment scoped — typically only the production stage carries them; dev/stage are unattended.

How it fits

Environment approvals are the human-control pillar of secure continuous deployment; alongside automated gates (metrics, work items) and secret/identity management they gate each stage of the release. Approvals = who says yes; gates = does health say yes.

Exam notes

  • Checks attach to environments, run pre-deployment for stages targeting them.
  • Approval check = a person/group approves; can be dynamically targeted.
  • Typical pattern: approval check on the production environment only, heavier automation elsewhere.
  • Distinguish approvals (human sign-off) from gates (automated health/work-item checks).

dynamic-approval-checks · deployment-gate · secure-cd · cd · release-definition

📘 Source: Microsoft Learn — Environment Approvals

dynamic-approval-checks

Dynamic Approval Checks

What it is

Dynamic approval checks are approval rules that are evaluated and targeted at deployment time rather than hard-coded to a fixed approver. In Azure DevOps environment checks, a check can be an Approval check whose approvers are decided dynamically — resolved from variables, groups, user/mail fields, or derived at execution, instead of a static user list typed into the definition.

Why it exists

Release culture wants approvals, but a fixed approver list is brittle: the right owner for a release often depends on the branch, the environment, the change, or on-call rotation. Dynamic targeting lets a single deployment gate send the approval request to the appropriate team or person as circumstances dictate — no pipeline re-edit when ownership or routing changes.

Key ideas

  • A check is configured on an environment and runs before the stage; an Approval check pauses the pipeline until the target approves.
  • Dynamic targeting options let you resolve the approver at runtime from:
    • variables / macro expressions ($(approver)),
    • group memberships (dynamic group chosen at run),
    • filters like branch name or environment attribute — so a release to prod-from-main routes to the Release Managers while a hotfix routes elsewhere.
  • Combine with timeout & approval-time limits so a stuck approval can’t block a release forever.
  • Approvals differ from gates: approvals are human authorization; gates are usually automated checks (metrics, work items).

How it fits

Dynamic approval targeting is the “approval” half of environment checks and of deployment gates. It makes secure continuous deployment governable at scale: human sign-off goes to the right human automatically, without maintaining per-branch approval definitions.

Exam notes

  • Approvals are checks attached to environments/stages.
  • Dynamic approval members = resolved at runtime (from variables/fields/groups) — contrast with a static list of approvers.
  • Approvals pause the deployment (human in the loop); gates typically evaluate health/metrics automatically.
  • For multi-stage CD, approvals on the production environment alone are enough to gate the prod stage.

environment-approvals · deployment-gate · secure-cd · cd · release-definition

📘 Source: Microsoft Learn — Dynamic Approval Checks

deployment-gate

Deployment gates

What it is

Deployment gates are automated or approval-based checkpoints in a release pipeline that pause a release before (pre-deployment) or after (post-deployment) a stage until specified conditions are met. If a gate fails, the release is held or fails rather than continuing to the next environment.

Why it exists

A pipeline that blindly deploys to production is dangerous. Gates let you enforce “is it healthy enough to proceed?” — checking live telemetry, approvals, and work-item status — before expanding a rollout or cutting over. They make release decisions data-driven and governed instead of blind or manual-only.

Key ideas

  • Approval gate: a human (often a different team/role) explicitly approves before/after a stage.
  • Azure Monitor / query-based gates: evaluate a metric/log query (e.g. error rate, latency) and pass only when it’s within threshold.
  • Work item gate: require relevant work items/change-requests to be associated.
  • Pre-deployment vs post-deployment: pre = “can we go to this stage?”, post = “did this stage come out healthy?” — post-deployment gates are key for progressive rollout decisions (canary/ring expansion).
  • Retries & timeout: gates run repeatedly over a window (e.g. every N minutes) and fail if never satisfied.

How it fits

Gates are the control mechanism that turns a release strategy into practice — especially for canary and ring rollouts, where metrics decide whether to widen or stop the rollout.

Exam notes

  • Gates can be pre-deployment or post-deployment and are configured per stage in a release.
  • Types include approvals, Azure Monitor (metrics/logs), and work item gates.
  • Post-deployment monitoring gates are what automate canary/ring expansion and enable safer continuous deployment.

release-definition · canary-deployment · deployment-ring · cd · rollback-strategy

📘 Source: Microsoft Learn — Deployment Gate

path MOCM1: OverviewM2: Key VaultM3: Variable groupsM4: Approvals & gatesSecure CDSecretspracticesvia variable groupsAzure accessApprovalsdynamic targetingautomated gates