Courseiva
Develop a security and compliance planmediumMultiple ChoiceObjective-mapped

AZ-400 Develop a security and compliance plan Practice Question

Your organization uses Azure DevOps for a multi-tier web application. The application consists of a React frontend, a Node.js API, and a SQL database. The security team has mandated the following: (1) All code changes must be scanned for secrets before merging to the main branch. (2) Infrastructure-as-code templates (ARM) must be validated for security compliance before deployment. (3) Production deployments must use a service connection with a managed identity that has only the required permissions. You have set up a CI/CD pipeline with two stages: Build and Release. The Build stage runs on pull requests and the Release stage deploys to a production environment. Recently, a developer accidentally committed a secret (API key) to a configuration file. The secret was not caught by the pipeline, and the code was merged to main. You need to prevent this in the future. What should you do?

⚠ Common exam trap

It's easy for candidates to confuse Azure Policy (which governs Azure resource compliance) with code scanning tools, or mistakenly think that manual reviews or approval gates are sufficient to catch secrets before merge, when automated scanning is required by the mandate.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Add a 'Credential Scanner' task to the Build pipeline and configure it to fail the build if any secrets are found. Also, move all secrets to Azure Key Vault and reference them via variable groups.

It directly addresses the root cause: secrets were not being scanned before merge. The Credential Scanner task (part of Microsoft Security Code Analysis) scans for hardcoded secrets and can fail the build, preventing the merge. Moving secrets to Azure Key Vault and referencing them via variable groups (linked to the vault) ensures secrets are never stored in the repository, eliminating the risk of accidental commits.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Configure a branch policy to require at least two reviewers on pull requests to the main branch.

    Why it's wrong here

    Requiring at least two reviewers on pull requests relies on manual code inspection and does not reliably detect hardcoded secrets, especially in configuration files or large diffs. Automated secret scanning in the build pipeline is necessary to enforce that credentials never enter the repository.

  • Implement a manual approval gate on the Release stage to review each deployment for secrets.

    Why it's wrong here

    A manual approval gate before deployment is a human checkpoint that adds latency and cannot consistently identify every secret in the code or artifact, and it does not prevent secrets from being merged into the repository in the first place. Secret detection must run automatically at build time rather than during a manual release review.

  • Use a pipeline decorator to inject a validation step that runs Azure Policy on the code repository.

    Why it's wrong here

    Azure Policy evaluates Azure resource configuration and compliance, not source code content or repository files. While a pipeline decorator can inject extra steps into a pipeline, running Azure Policy on the code repository does not scan for secrets; a dedicated credential scanning task is required.

  • Add a 'Credential Scanner' task to the Build pipeline and configure it to fail the build if any secrets are found. Also, move all secrets to Azure Key Vault and reference them via variable groups.

    Why this is correct

    Adding a Credential Scanner task to the Build pipeline and configuring it to fail the build when secrets are found automatically blocks hardcoded credentials from being merged into the codebase. Moving secrets to Azure Key Vault and referencing them via variable groups centralizes secret management and removes the need to store sensitive values in source code.

Visual reference

Client DHCP Server 1 Discover (broadcast) 2 Offer (IP: 192.168.1.10) 3 Request (I accept) 4 Acknowledge (lease confirmed) DORA — the four-step DHCP lease process

About these practice questions

Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.