7.1 Objective

Add a safety net so a bad push doesn’t silently go live and stay live - combining prevention (stop bad deploys before they happen) with recovery (undo quickly if one gets through).

7.2 Layer 1: S3 Versioning (recovery)

Enabled Bucket Versioning under S3 → Properties. Every sync now creates new object versions instead of overwriting silently, so any previous version of any file can be restored directly from the S3 console without touching Git.

7.3 Layer 2: Git Revert (recovery, source of truth)

$ git revert <bad-commit-hash>
$ git push origin main

Reverting triggers the pipeline again with the previous good state as the new commit - keeps Git history and the live site in sync, rather than only fixing S3 directly.

7.4 Layer 3: Pre-deploy Sanity Check (prevention)

Added a step to the workflow that runs after AWS credentials are configured but before the sync, so a failure stops the job before anything touches S3.

- name: Sanity check before deploy
    run: |
        if [ ! -s index.html ]; then
            echo "index.html missing or empty - aborting deploy"
            exit 1
        fi

7.5 Tests Performed

Test 1: Git revert

Pushed a change, then ran git revert HEAD and pushed again. Confirmed the pipeline triggered a fresh deploy and the site returned to its prior state.

Test 2: Sanity check blocks a bad deploy

Emptied index.html intentionally, committed, and pushed. Workflow failed at the Sanity check step exactly as designed and never reached the sync step - S3 was untouched. Reverted the test commit afterward to restore the real site.

7.6 Result

Both the prevention check and the recovery paths (git revert, S3 versioning) were confirmed working, not just configured.

7.7 Screenshots