AZ-400 Practice Question: Design and implement a source control strategy
Which TWO actions should you take to proactively protect your repository from accidentally committing secrets? (Choose two.)
⚠ Common exam trap
Many exam-takers confuse reactive security measures (like alerts or branch policies) with proactive, blocking controls (like pre-commit hooks and push protection) that prevent secrets from being stored in the first place.
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
✓
Use pre-commit hooks with tools like detect-secrets
Pre-commit hooks, such as those using the detect-secrets tool, scan staged changes before a commit is finalized. This prevents secrets from ever entering the repository history, providing a proactive, client-side guard. Option C is correct because push protection in secret scanning blocks pushes that contain known secret patterns at the server side, preventing the secret from being stored in the remote repository.
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 branch protection rules
Why it's wrong here
Branch protection rules enforce review and status-check requirements on pull requests, but they do not scan file contents for secrets. They can prevent force-pushes or require CI checks, yet neither of those mechanisms inspects committed code for embedded credentials, so they fail to proactively block secret leakage.
- ✓
Use pre-commit hooks with tools like detect-secrets
Why this is correct
Pre-commit hooks run locally before a commit is finalized, allowing tools like detect-secrets to scan staged files and reject the commit if a potential secret is found. This shifts security left, stopping credentials from ever entering the Git history, which is a proactive measure because it prevents secret exposure before the commit is created.
- ✓
Enable push protection in secret scanning
Why this is correct
Push protection in secret scanning is a GitHub Advanced Security feature that blocks pushes containing known secret patterns, such as API keys or tokens, before they reach the remote repository. It actively intercepts the push and requires the user to acknowledge or remove the secret, thus preventing the secret from being persisted in the shared codebase.
- ✗
Use signed commits
Why it's wrong here
Signed commits provide cryptographic proof of authorship and integrity using GPG or SSH keys, but they verify who made the commit, not what the content contains. A signed commit can still include a hardcoded secret, so signature validation does nothing to detect or prevent secret leakage in the committed code.
- ✗
Configure secret scanning alerts
Why it's wrong here
Secret scanning alerts notify repository administrators after a secret pattern is detected in committed content, typically triggering a remediation workflow. This is a reactive measure because the secret has already been pushed and recorded in history, so it does not proactively prevent the secret from being introduced in the first place.
Go deeper
Related to this question
About these practice questions
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
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.