What is failing forward?
Failing forward, also called fixing forward or rolling forward, is a way to recover from a change that went wrong: instead of restoring the previous state, the team deploys another change that corrects the problem. The system ends up in a new, working state rather than back where it started. SY0-801 added failing forward to its change management material, where it is weighed against the backout plan.
When failing forward makes sense
- Rolling back would reopen a vulnerability. An out-of-band patch for an actively exploited web server flaw changes a default header and breaks one internal dashboard. Reverting would expose the server again to fix a minor problem.
- Rolling back would lose data. A release has already rewritten live customer records into a new format while new orders keep arriving.
- The old state no longer works. The previous release relied on an API version that the cloud provider has since retired.
- The change can't be reversed. Some firmware has anti-rollback protection that refuses older versions by design.
- The cause is understood and the fix is small. Teams with automated build and test pipelines can ship a tested one-line fix in minutes.
When to back out instead
Back out when the cause is unknown, the impact is wide, the previous state was stable and secure, and the backout is tested and fits the window. A firewall upgrade that blocks all payment traffic for reasons nobody can explain calls for a backout, not experiments. Failing forward isn't permission to keep trying fixes until one sticks. A sound plan sets a deadline: if the corrective change hasn't worked by a stated time, the team falls back to the backout or a restore.
Example: the invoice release
A billing release at 22:00 converts every invoice record to a new tax format. At 22:30 support finds that PDF invoices for one region print the wrong currency symbol. Restoring the database would discard every invoice issued since 22:00. Developers find the formatting bug, test the fix in staging and deploy it at 23:15 as an emergency change. The release stays, and the defect is gone.
Failing forward is still a change
The corrective change goes through the emergency process: expedited approval, as much testing as time allows, and a full record. The record matters for security because a rushed fix is less tested than the original change, and the next reviewer needs to know why it exists. Rolling back has its own risk too: restoring a vulnerable version is a decision to accept that vulnerability again, and it should be documented as one.
Failing forward on the CompTIA Security+ exam
Failing forward is new in SY0-801 objective 1.2, the change management scenario objective. Scenario wording such as rolling back would reintroduce the vulnerability, the previous version can't be restored without losing data, or deploying a corrective update points to it. The main distractor is executing the backout plan, which is right when the old state is safe and reachable. Another is troubleshooting past the end of the window with no decision, which abandons the plan. Whichever way a team goes, the correct answer records the fix as a controlled change.