Develop a security and compliance plan →mediumMultiple ChoiceObjective-mapped

AZ-400 Develop a security and compliance plan Practice Question

You are designing a compliance plan for Azure DevOps. The compliance officer requires that all changes to build pipelines are audited and cannot be reverted without approval. What should you implement?

⚠ Common exam trap

A common mix-up: candidates confuse audit logging (which only records events) with enforcement mechanisms (like branch policies) that actually prevent unapproved changes and reverts.

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

✓

Store pipeline YAML in a repository with branch policies

Storing pipeline YAML in a repository with branch policies ensures that every change to the pipeline definition goes through a pull request (PR) process, which is auditable and requires approval before merging. Once merged, the change is recorded in the Git history, and reverting it requires another PR with approval, meeting the compliance requirement that changes cannot be reverted without approval.

Answer analysis

Option-by-option breakdown

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

✗
Enable Azure DevOps audit logs
Why it's wrong here
Azure DevOps audit logs provide a detailed, searchable record of who performed what action and when, but they are purely reactive and do not enforce any approval workflow or block unauthorized modifications to pipeline definitions. Consequently, they cannot prevent a user with edit permissions from directly reverting the YAML pipeline; they only support post-incident forensics and compliance reporting.
✓
Store pipeline YAML in a repository with branch policies
Why this is correct
Storing the pipeline YAML in a Git repository with branch policies enforces mandatory peer review and approval for any pull request that modifies the pipeline definition. This creates a gated change process with full traceability, ensures separation of duties, and directly prevents unauthorized or accidental reverts, making it the appropriate compliance control for protecting pipeline definitions.
✗
Use release approval gates
Why it's wrong here
Release approval gates are runtime quality checks that can pause or block a specific release deployment based on criteria like work items, queries, or Azure Monitor alerts, but they operate after the pipeline definition has already been changed and a release has been triggered. They do not govern who can edit the pipeline YAML or require approval for definition changes, so they cannot prevent malicious or accidental reverts to the pipeline code itself.
✗
Set pipeline retention policies
Why it's wrong here
Pipeline retention policies are a storage-management feature that controls how many pipeline runs and artifacts are kept, typically to limit costs and comply with data-retention requirements. They have no effect on user permissions or the change-approval process for pipeline definitions, so they cannot stop someone from reverting the YAML or modifying the pipeline without authorization.

Go deeper

AZ-400 Develop a security and compliance plan Practice Question

Why each option matters

Option-by-option breakdown

Related to this question