Design and implement a source control strategy →hardMultiple SelectObjective-mapped

AZ-400 Practice Question: Design and implement a source control strategy

Your organization uses GitHub for source control. You need to implement a secure source control strategy that prevents secrets from being exposed and ensures code quality. Which THREE practices should you implement?

⚠ Common exam trap

It's easy for candidates to confuse commit signing (which ensures authenticity) with secret scanning or code quality enforcement, leading them to select option C instead of recognizing that it does not address the stated goals of preventing secret exposure or ensuring code quality.

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

✓

Configure branch protection rules requiring status checks to pass

Branch protection rules enforce required status checks (e.g., CI builds, code reviews) before merging, ensuring only validated changes enter protected branches—this supports code quality. GitHub secret scanning automatically detects known types of secrets in repositories and alerts on exposure, directly preventing secret leaks. Pre-commit hooks scan code for secrets before a commit is created, blocking accidental commits of credentials or tokens. Together, A, D, and E address both secret prevention and code quality. Commit signing (C) verifies authorship but does not prevent secret exposure or enforce code quality checks.

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 branch protection rules requiring status checks to pass
Why this is correct
Configure branch protection rules to require status checks to pass, so pull requests cannot be merged unless the specified CI checks (e.g., tests, builds, and linting) succeed. This enforces code quality gates automatically, ensuring that only code meeting defined criteria is integrated into the main branch.
✗
Store secrets in a .env file committed to the repository
Why it's wrong here
Storing secrets in a .env file committed to the repository exposes credentials to anyone with read access and permanently embeds them in version history, even if later deleted. This is insecure and violates best practices; instead, use GitHub Actions secrets or an external secret manager like Azure Key Vault.
✗
Require commit signing using GPG keys
Why it's wrong here
Requiring commit signing with GPG keys verifies the identity of the committer, preventing impersonation, but it does not protect against secret exposure or enforce code quality. It is an authenticity control, not a mechanism for validating code or safeguarding sensitive data.
✓
Enable GitHub secret scanning for the repository
Why this is correct
Enabling GitHub secret scanning automatically detects known secret formats (e.g., AWS access keys, GitHub tokens, private keys) in the repository and raises alerts, helping prevent credential leakage. This is part of a defense-in-depth strategy to catch accidentally committed secrets before they are exploited.
✓
Use pre-commit hooks to scan for secrets before commits
Why this is correct
Pre-commit hooks run locally before each commit, scanning files for patterns that match common secret formats (such as API keys or passwords) and aborting the commit if any are found. This prevents secrets from ever being pushed to the remote GitHub repository, adding a proactive security layer at the developer's workstation.

Go deeper

AZ-400 Practice Question: Design and implement a source control strategy

Why each option matters

Option-by-option breakdown

Related to this question