SY0-701 Question 31
Single answerVersion controlA software company stores infrastructure-as-code templates and application source code in a shared Git repository. During a security review, the team discovers that a developer accidentally committed a cloud API key to the main branch last week. The key has already been revoked and replaced. Management now wants to reduce the chance of similar incidents and improve accountability for future code changes. Which action would BEST address both goals?
- A
Require all developers to use signed commits and enforce pull-request reviews before merging to the main branch
- B
Compress the repository and archive older branches so fewer users can access previous commits
- C
Rely on developers to delete sensitive files locally before each commit and continue committing directly to the main branch
- D
Disable branch history so only the latest version of each file is visible to developers
Show answer and explanation
Correct answer: A
Explanation
The best answer is to require signed commits and enforce pull-request reviews before merging to the main branch. In a Security+ context, version control should support integrity, accountability, and secure change management. Signed commits provide stronger assurance about the identity associated with a change, while pull-request reviews and branch protection reduce the risk of insecure or unauthorized code reaching production branches. These practices align with secure development and change-control best practices commonly recommended in Git platform documentation such as GitHub branch protection and commit signature verification guidance, as well as GitLab protected branches and merge request approval workflows. Although the exposed key was already rotated, preventing recurrence requires process and technical controls, not just cleanup. In mature environments, these controls are often paired with secret scanning and pre-commit hooks, but the option given most directly addresses both future prevention and accountability.
- A. Correct.
Correct. Requiring signed commits strengthens non-repudiation and accountability by helping verify who authored and submitted changes. Enforcing pull-request reviews before merging adds oversight and increases the likelihood that exposed secrets, insecure code, or policy violations are caught before reaching the protected main branch. In version control security, branch protection, code review, and commit signing are practical controls that improve both change accountability and prevention.
- B. Incorrect.
Incorrect. Archiving or compressing branches does not meaningfully prevent future secret exposure or improve accountability. Sensitive data may still exist in repository history, and reducing access to older branches is not a substitute for secure workflows such as protected branches, reviews, and signed commits. Someone might choose this because limiting access sounds secure, but it does not address the root cause of insecure commits.
- C. Incorrect.
Incorrect. This depends on manual user behavior and does not provide strong preventive or detective controls. Continuing to allow direct commits to the main branch reduces oversight and weakens change management. A candidate might pick this because deleting files before committing seems practical, but secrets can still be accidentally staged, included in history, or added in future commits without any formal review.
- D. Incorrect.
Incorrect. Git and similar version control systems are designed to preserve history; disabling branch history is not a standard security control and would undermine traceability, auditing, and rollback capabilities. This option is plausible if someone confuses security with simply hiding old versions, but retaining history is actually important for accountability and incident investigation.