If you do not secure your delivery pipeline, you could accidentally deploy software that leaks customer credit card numbers or gives hackers remote control of your servers. That is the problem that implementing security and compliance in pipelines solves: it makes sure every piece of code is automatically checked for safety and legal rules before it ever reaches a real user. For the AZ-400 exam, this topic is critical because Microsoft wants to certify that you can design pipelines that protect both the company and its customers from disaster.
Jump to a section
A simple way to picture Implementing Security and Compliance in Pipelines
A building security inspector is the person who makes sure a new office block is safe before anyone can move in. They don't just check the front door lock; they examine every window latch, every fire alarm, every stairwell exit, and every electrical panel. They also check that the builders followed the original blueprints and didn't take dangerous shortcuts. If the inspector finds a problem — say, a back door that doesn't lock properly — they stop everything until it's fixed.
Now think about a software pipeline. It is the automated assembly line that takes new code from a developer's laptop, runs tests, and eventually releases it to customers. The "security and compliance" part is like hiring that inspector inside the assembly line itself. Every time a piece of code moves from one stage to the next, automated inspectors check that the code contains no secret passwords, that the servers it will run on are configured safely, and that the whole process follows company rules (like keeping customer data private). If a violation is spotted — for example, a configuration that leaves a database exposed to the internet — the pipeline halts the build and alarms the team, exactly like an inspector refusing to sign off on a building until the exposed wiring is fixed. Without these automated inspectors, you might accidentally ship code with a back door wide open, and not know until a real intruder walks through it.
Let us start with a clear picture of what a pipeline is. A pipeline is an automated series of steps that takes source code (the human-written instructions for a program) and turns it into a running application. The steps typically include: fetching the code from a repository (like GitHub), running automated tests, building the code into a deployable package, and then deploying that package to servers. Without security, this entire process is vulnerable to attacks. An attacker could inject malicious code into the pipeline, or a well-meaning developer might accidentally commit a file containing a database password.
Security and compliance in pipelines means adding automated checks at every stage to prevent such problems. The technical term for these checks is policy-as-code or compliance gates. A policy is simply a rule, written in a language a computer can understand, that says things like: "All passwords must be stored in a vault, not in the source code" or "Every deployed container must be scanned for known vulnerabilities."
How does this work in practice? Azure DevOps (Microsoft's set of tools for building and deploying software) includes several features for this. The first is Azure Key Vault. This is a secure, cloud-based locker for secrets — things like API keys (a secret code that allows one program to talk to another), connection strings (the address and password needed to connect to a database), and certificates (digital ID cards for servers). Instead of writing a secret directly in the code, a developer stores it in Key Vault. The pipeline, when it runs, requests the secret from the vault at the moment it is needed. This way, the secret never sits in the source code where an attacker could read it.
The second major concept is branch protection policies. In a source control system like Git, developers work on separate copies of the code called branches. A branch protection policy prevents anyone from merging code into the main branch (the version that gets released) unless certain conditions are met. For example, the policy could require that at least one other person has reviewed and approved the code, and that all automated security tests have passed. This replaces the old way where a single developer could push broken or insecure code directly to production.
The third concept is vulnerability scanning. Azure DevOps integrates with Microsoft Defender for Cloud and other tools to automatically scan every build artifact (the final packaged software) for known security holes. If a library (a pre-written piece of code that your software uses) has a known vulnerability, the scanner flags it and the pipeline can be configured to fail — meaning it refuses to produce a deployable package until that library is updated.
Compliance is a related but distinct idea. Compliance means following external regulations like GDPR (a European law about protecting personal data), HIPAA (a US law for healthcare data), or industry standards like PCI DSS (for credit card handling). A compliance check in a pipeline might verify that the software does not log credit card numbers, or that it encrypts data both when stored and when transmitted. These checks are often implemented using Azure Policy, a service that enforces rules across your entire cloud environment. For example, you can have a policy that says: "Every virtual machine must have its operating system patched to the latest security update." The pipeline can check this policy before deploying the virtual machine.
The last building block is logging and auditing. Everything the pipeline does — every check that passes or fails, every approval given, every secret accessed — is recorded in a log. This is essential for compliance: if an auditor (a person who inspects your company's practices) asks "Did you check for passwords in your code before the release?", you can point to the pipeline logs and prove that yes, the automated check ran and passed.
To tie it all together: implementing security and compliance in pipelines replaces a chaotic, trust-based process with an automated, verifiable one. In the old days, a senior developer might manually review code for security, but humans make mistakes and get tired. The new approach uses machines to enforce the same checks every single time, consistently and without fail. For the AZ-400 exam, you need to know the specific Azure DevOps tools — Azure Key Vault, Azure Policy, branch protection policies, and vulnerability scanners — and how they fit together in a YAML pipeline definition (a text file that describes the pipeline steps). You should also understand the difference between prevention (stopping bad code before it deploys) and detection (finding problems after deployment), because the exam will ask you to choose the right approach for a given scenario.
Remove Secrets from Source Code
Identify any passwords, API keys, or certificates in your codebase. Replace each with a reference to Azure Key Vault. This means the pipeline will fetch the real secret at runtime from Key Vault, never exposing it in the repository.
Configure Branch Protection Policies
In your source control repository (GitHub or Azure Repos), turn on branch protection for the main branch. Require a minimum number of reviewers and require that all status checks (including the pipeline) pass before a pull request can be merged. This prevents insecure code from entering the main branch.
Add Static Code Analysis to the Pipeline
Insert a task early in your pipeline YAML file that runs a static analysis tool (like SonarQube or Microsoft Defender for Cloud's secret scanning). This will scan each commit for hard-coded secrets and common coding vulnerabilities. If issues are found, the pipeline fails and alerts the team.
Configure Compliance Gates with Azure Policy
Define Azure Policy rules that match your organisational or regulatory requirements. Assign these policies to the subscriptions or resource groups where you deploy. In your pipeline, add a task that checks the policy compliance status of the target resources before deployment, and stop the pipeline if non-compliant.
Implement Deployment Approvals and Gates
In Azure Pipelines, define a manual approval for the production stage, requiring a specific person or group (e.g., 'Security Team') to authorise the release. Add an automated gate that checks for zero critical vulnerabilities in the container scan before allowing deployment to proceed.
Enable Audit Logging and Monitoring
Configure Azure Monitor to collect pipeline logs, including secret accesses and approval actions. Set up alerts for suspicious patterns, such as a secret being retrieved from Key Vault outside of normal pipeline runs. This satisfies audit requirements and enables forensic investigation if a breach occurs.
Imagine you work for a mid-sized online retailer called ShopFast. You are the DevOps engineer responsible for the pipeline that deploys the company's website. The website handles credit card payments, so your company must comply with PCI DSS (Payment Card Industry Data Security Standard). This means you cannot store credit card numbers in logs, and you must encrypt all network traffic.
Here is what a typical day implementing security in your pipeline looks like. A developer named Priya writes new code for a checkout page. She commits her changes to a feature branch on GitHub. As soon as she pushes the code, Azure Pipelines (the part of Azure DevOps that runs pipelines) automatically triggers a build. The first step in the pipeline is a static code analysis scan using a tool like SonarQube or Microsoft Defender for Cloud. This scan looks for hard-coded secrets (like passwords or API keys). The scan finds that Priya accidentally included a test API key in the code. The pipeline fails immediately and sends an alert to Priya and the security team.
Priya removes the key, stores it in Azure Key Vault instead, and updates her code to fetch it from the vault at runtime. She pushes the commit again. This time the static analysis passes. The pipeline moves to the next stage: building the application into a container (a lightweight, portable package of software). The container is built and pushed to Azure Container Registry (a private storage for containers). Next, the pipeline scans that container using Microsoft Defender for Containers, checking for any known vulnerabilities in the operating system packages inside the container. The scanner finds a critical vulnerability in an old version of an SSL library. The pipeline fails again.
Priya updates the base container image to use the latest patched version. She pushes once more. This time the container scan passes. The pipeline now reaches the deployment stage, but before deploying to production, it must pass a compliance gate defined by Azure Policy. The policy states: "Only deploy to virtual machines that have encryption at rest enabled." The pipeline checks the target virtual machine's configuration. The VM is already compliant, so this gate passes. Finally, a manual approval is required: a senior engineer reviews the change and approves it in the Azure DevOps portal. Once approved, the pipeline deploys the new checkout page to the production servers. All of these steps are automatically logged, including who approved what and when, so the company can demonstrate compliance during the next PCI DSS audit.
What does an IT professional actually do here? They write the pipeline definition file (in YAML format) that describes each of these steps. They configure the Azure Policy rules and assign them to the appropriate scope (the subscription or resource group containing the target servers). They also set up branch protection rules in the GitHub repository to require that all checks pass before merging any code into the main branch. Additionally, they manage the Azure Key Vault access policies, ensuring that only the specific Azure DevOps service principal (a machine identity) can read secrets from the vault, and that individual engineers cannot. They also monitor the pipeline logs using Azure Monitor and set up alerts for repeated failures. In short, the professional's job is to encode the company's security and compliance rules into automated, repeatable checks that run every time code is built.
The AZ-400 exam tests 'Implementing Security and Compliance in Pipelines' in several specific ways. You should expect scenario-based multiple-choice questions where you must choose the correct Azure DevOps tool or service to solve a given security problem. The exam loves to test your ability to distinguish between similar-sounding services. Here are the exact concepts they ask about:
Azure Key Vault integration for secrets. They will give a scenario like: 'A developer hard-coded a database password in the source code. Which service should you use to remove the secret from the code?' The correct answer is Azure Key Vault. A common trap is suggesting Azure App Configuration (which stores application settings, not secrets) or environment variables in the pipeline (which are not secure because they can be seen in logs).
Branch protection policies in Azure Repos or GitHub. They will ask: 'How do you prevent a developer from merging code directly into the main branch without a security review?' Correct answer: Configure a branch protection policy that requires a pull request with a minimum number of reviewers. The trap is suggesting a manual process or a release gate, which occur later in the pipeline.
Azure Policy for compliance. Questions will describe a regulatory requirement (e.g., 'All storage accounts must be encrypted at rest') and ask which service enforces that rule across multiple subscriptions. The answer is Azure Policy. The trap is thinking of Azure Blueprints (which packages multiple resources together) or Role-Based Access Control (RBAC, which controls who can access resources, not what configuration is allowed).
Pipeline approvals and gates. The exam tests the difference between a manual approval (a person clicks 'Approve') and a gate (an automated check, like waiting for a security scan to finish). They will ask: 'Which should you use to require a security team member to review a deployment?' The answer is an approval (manual). Which for an automatic vulnerability check? A gate (automated).
Scanning for secrets and vulnerabilities. They love to compare static analysis (scanning source code without running it) against dynamic analysis (scanning a running application). For the pipeline security context, static code analysis is the correct choice for finding hard-coded secrets. They might also ask about dependency scanning (checking third-party libraries for known vulnerabilities). The trap is offering a tool that scans network traffic or runtime behaviour, which is not suitable for a pre-deployment pipeline check.
YAML pipeline security. They will test your knowledge of specific YAML keywords like 'checkout', 'steps', and 'task'. For example: 'Which task in a YAML pipeline fetches secrets from Azure Key Vault?' The answer is 'AzureKeyVault@2'. The trap is using 'DownloadSecureFile' or 'AzurePowerShell' with manual commands.
Key definitions to memorise: 'Service Principal' (an identity for automated tools), 'Least Privilege Principle' (give only the minimum permissions needed), 'Credential Hygiene' (never hard-code secrets), 'Immutable Infrastructure' (replace servers rather than patch them in place, to ensure consistency and security). The exam also expects you to know that Azure DevOps integrates with GitHub Advanced Security for secret scanning and code scanning. Finally, remember that logging and auditing are considered part of compliance, and the exam may ask which Azure resource stores pipeline logs (Azure Monitor / Log Analytics workspace).
Never hard-code secrets like passwords or API keys in source code; always use Azure Key Vault to store and retrieve them securely.
Branch protection policies in GitHub or Azure Repos enforce that code must be reviewed and pass security checks before merging into the main branch.
Azure Policy is used to define and enforce compliance rules across your cloud resources, such as requiring encryption or specific firewall settings on all resources.
Pipeline gates are automated checks that run before a deployment can proceed, while approvals require a human to manually authorise the release.
Use vulnerability scanning tools integrated into your pipeline to automatically detect known security flaws in your code and dependencies before deployment.
Every pipeline action that touches a secret or makes a deployment decision should be logged to Azure Monitor for audit trails and compliance evidence.
These come up on the exam all the time. Here's how to tell them apart.
Azure Policy
Defines rules about resource configuration (e.g., encryption must be enabled)
Evaluates resources for compliance automatically
Does not control who can perform actions
Role-Based Access Control (RBAC)
Defines who can perform actions (e.g., who can delete a VM)
Applies permissions to identities (users or service principals)
Does not enforce configuration settings
Pipeline Gate
Runs automatically based on conditions (e.g., scan result)
No human interaction required
Used for repeatable, objective checks
Pipeline Approval
Requires a named person or group to explicitly authorise
Human judgement is the deciding factor
Used for subjective or high-risk decisions
Azure Key Vault
Stores secrets in a hardware-backed, encrypted vault
Access is controlled by separate service principal permissions
Secret does not exist in the pipeline definition file
Pipeline Variables (secret type)
Stores secrets as environment variables in the pipeline run
Any code in the pipeline can read the variable if it knows the name
Secret value is masked in logs but can still be exposed by a script
Static Code Analysis
Analyses source code without executing it
Can find hard-coded secrets, SQL injection patterns, etc.
Runs early in the pipeline, before build
Dynamic Code Analysis
Analyses a running application (e.g., scanning web requests)
Finds runtime vulnerabilities like missing authentication checks
Runs after deployment, usually in a test environment
Git Branch Protection
Enforced at the source control level before merge
Blocks merging until all required checks pass
Applies to developers pushing to the repository
Pipeline Run Checks
Enforced during the pipeline execution after merge or push
Blocks deployment if checks fail, but does not block merge
Applies to the build and release process itself
Mistake
If I use a secret variable in the pipeline settings, it is completely secure and cannot be exposed.
Correct
Pipeline secret variables are masked in logs, but they can still be exposed if a developer writes a script that outputs the variable. The only truly secure way is to use Azure Key Vault and reference the secret directly from the vault.
Many beginners confuse UI masking with true encryption and access control. They think hiding the value from display makes it safe, but a malicious script can still read the environment variable at runtime.
Mistake
Compliance checks are only needed for government or healthcare projects.
Correct
Compliance applies to any industry that handles sensitive data, including retail (PCI DSS), general business (GDPR), and even internal HR systems. Azure Policy can enforce company-specific security standards, not just external regulations.
People often associate 'compliance' narrowly with laws like HIPAA, forgetting that any organisation can define its own internal compliance rules to reduce risk.
Mistake
Once a pipeline passes all security checks, the deployed software is guaranteed to be secure.
Correct
Pipeline checks reduce the risk, but they cannot catch zero-day vulnerabilities (flaws that are unknown to vendors) or logic flaws that bypass security controls. Security is a continuous process, not a one-time gate.
Beginners want a binary 'safe vs unsafe' result, but real-world security has shades of grey. The pipeline is a safety net, not an impenetrable fortress.
Mistake
Azure Policy and Role-Based Access Control (RBAC) do the same thing: they both control who can access resources.
Correct
RBAC controls who can perform actions (e.g., who can deploy a VM). Azure Policy controls the configuration of resources (e.g., all VMs must have encryption enabled). They are different layers: RBAC is about identity, Policy is about compliance rules.
Both involve 'rules' and 'access', so beginners lump them together. The exam deliberately tests this distinction.
Mistake
Storing secrets in an encrypted file in the Git repository is safe as long as the repository is private.
Correct
No encryption is safe in source control because the encryption key must also be stored somewhere, and any developer with access to the repo can potentially retrieve and brute-force the encrypted file. Secrets must never be in source code.
Many developers come from a background where 'private repo' felt secure enough. They underestimate how easily a repository can be accidentally made public or leaked through a third-party service.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A gate is an automated check that runs code (like a vulnerability scan) and passes or fails automatically. An approval requires a human to click a button to authorise the deployment. Use gates for automated conditions, approvals for human judgement.
Variable groups are more secure than hard-coding, but they are not as secure as Azure Key Vault. Secrets in variable groups can be exposed if the variable group is misconfigured or if a pipeline step logs environment variables. Key Vault provides hardware-backed encryption and fine-grained access control.
Use Azure Policy. Create a policy that audits or denies deployment of virtual machines without encryption at rest. Assign that policy to the entire subscription, so it is enforced automatically before any VM is created.
It means giving the pipeline's service principal (the automated identity it runs under) only the permissions it absolutely needs. For example, it should have read access to Key Vault secrets, but not permission to delete secrets or create new vaults.
Microsoft Entra ID (formerly Azure AD) manages the identities that access Azure DevOps, including users and service principals. You use Entra ID to control who can create pipelines, who can approve releases, and which identities the pipeline uses to connect to Azure resources.
A service principal is a machine identity — like a username and password for an automated tool. Your pipeline uses a service principal to authenticate with Azure services (like Key Vault or Azure Policy) without requiring a human to log in. It is created automatically when you set up your Azure DevOps connection to Azure.
You've finished Implementing Security and Compliance in Pipelines. Continue through the AZ-400 study guide to build a complete picture of the exam.
Done with this chapter?