AZ-400 Practice Question: Design and implement a source control strategy
Your team uses Azure Repos and wants to prevent developers from committing secrets and large binary files into a shared repository. You plan to enforce this with client-side and server-side controls. Which two actions should you take? (Choose two.)
⚠ Common exam trap
The trap here is treating .gitignore or commit signing as enforcement; only server-side validation reliably blocks content that local controls miss.
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 server-side push hook or pipeline validation that rejects pushes containing files above a size limit or matching secret patterns.
Effective prevention pairs a local pre-commit hook, which gives fast feedback and stops offending content before it enters history, with authoritative server-side validation, which cannot be bypassed by skipping client hooks. Together they cover both the developer experience and the guarantee. .gitignore, reviewer policies, and commit signing each address different concerns and cannot detect or block secrets and large binaries on their own.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Require all contributors to sign commits with a GPG key before they can push to the repository.
Why it's wrong here
Commit signing proves author identity and integrity of the commit object; it says nothing about the content of the files being committed. A properly signed commit can still contain a private key or a multi-gigabyte binary. Signing is valuable for provenance but is orthogonal to secret and size prevention, so it does not meet the requirement.
- ✓
Add a server-side push hook or pipeline validation that rejects pushes containing files above a size limit or matching secret patterns.
Why this is correct
Server-side enforcement is the authoritative control because it applies to every push regardless of local configuration, which developers can bypass or forget to install. A push hook or validation pipeline can inspect incoming objects, reject oversized files, and scan for credential patterns. This guarantees the repository policy is enforced even when client hooks are absent or disabled.
- ✓
Install a pre-commit hook that scans staged changes for high-entropy strings and file size thresholds.
Why this is correct
A pre-commit hook runs on the developer's machine before the commit is created, so it can reject staged secrets or oversized binaries at the earliest point. High-entropy detection catches many credential patterns, and a size threshold blocks large binaries. This provides fast local feedback and prevents the offending content from ever entering local history, complementing server-side controls.
- ✗
Configure a .gitignore file in the repository root to exclude build output and binary artifact folders.
Why it's wrong here
.gitignore prevents untracked files from being staged, which reduces accidental commits of build output, but it has no effect on files already tracked and cannot detect secrets or enforce policy on the server. It is a useful hygiene measure but does not prevent a determined developer from committing a binary or credential. It also cannot block pushes, so it fails the enforcement requirement.
- ✗
Enable a branch policy requiring a minimum number of reviewers on the main branch.
Why it's wrong here
Reviewer policies enforce human approval for pull requests but do not inspect file content for secrets or size. A reviewer might catch an obvious binary, but the policy itself provides no automated detection and does not block a direct push if the pusher has bypass rights. It addresses review governance, not content prevention, so it does not satisfy the stated goal.
Go deeper
Related to this question
Learn chapter
Designing a Security and Compliance Plan
Key term
Repository
A repository is a central storage location where software packages, code, or configuration files are kept, managed, and distributed for use by IT systems.
Key term
Azure Repos
Azure Repos is a set of version control tools that allow teams to manage their source code, track changes, and collaborate on software projects using Git or Team Foundation Version Control (TFVC) within the Microsoft Azure ecosystem.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 696 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 →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
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.