SY0-701 Security Program Management and Oversight Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Apply the change directly in production so users get the fix immediately

  Why it's wrong here

  Hotfixing directly in production bypasses every change control gate and creates an unversioned, undocumented environment state; if the change is misconfigured there is no clean rollback path and the team cannot reproduce the exact released artifact. This anti-pattern also violates separation of duties and auditability requirements, and in regulated environments may constitute a compliance failure. Production should only be changed through the same automated, tested release process used for any other update.

• ✓

  Use an approved pipeline with peer review, automated testing, and rollback steps

  Why this is correct

  An approved pipeline that enforces peer review, automated testing, and rollback steps aligns with secure change and release management: the code is built once into an immutable artifact, tested automatically against unit, integration, and security regression suites, and deployed in a controlled manner with rollback procedures defined in advance. This reduces the probability of introducing new vulnerabilities while ensuring that, if an issue occurs, the team can rapidly restore service. It also provides a full audit trail for compliance and accountability.

• ✗

  Skip testing because security fixes should always be deployed quickly

  Why it's wrong here

  A security fix that skips testing is still code, and it can regress business logic, break downstream dependencies, or fail to actually close the vulnerability—silent failures that are far more expensive than a short test cycle. Automated scanning, regression tests, and smoke tests are precisely what verify both that the exploit path is closed and that nothing else is broken; deploying an untested fix to a customer-facing system risks a P0 outage alongside the vulnerability. Speed cannot come at the cost of basic verification in a production environment.

• ✗

  Let any on-call developer approve and deploy without documentation

  Why it's wrong here

  Allowing any on-call developer to approve and deploy without documentation removes all traceability and accountability, making it impossible to determine who changed what, why, and when—essential information for incident response and post-incident reviews. It also destroys the separation of duties required to prevent unauthorized or malicious changes from reaching production, and without a written record rollback becomes guesswork. Change management is not bureaucracy; it is the control that lets a team know the current production state and recover from any failure.