Competition Strategy 11
Use the final phase to verify requirements, revisit high-value unresolved work, confirm forensic answers, and protect the progress your team has already made.
Final review is not a last-minute hardening sprint. It is a structured verification phase where the team confirms the image is secure, functional, and consistent with the scenario.
Lesson Snapshot
Learning objectives
Explain why the final review phase should focus on verification and unresolved high-value work rather than random last-minute changes.
Re-read the scenario and confirm required users, administrators, services, software, and restrictions are still satisfied.
Review risky changes and verify that networking, authentication, permissions, and required services still function.
Revisit unresolved tasks using evidence and priority instead of panic.
Confirm forensic answers are supported by evidence and directly answer the question asked.
Use a structured final-review workflow that reduces the chance of undoing earlier progress.
Core concept
The final phase should answer one question: Is the system now in a secure, functional, scenario-compliant state that the team can explain and defend?
That means re-checking the work with the highest impact, not trying to touch every remaining setting.
Late-round discipline
As time decreases, the team should become more conservative about disruptive changes. A new issue may be real, but if the evidence is weak and the effect is broad, guessing can damage verified work.
Six-phase review
Phase 01
Return to the source of truth. Confirm the team has not accidentally violated a requirement while hardening the image.
Phase 02
Look at Done / Verify, Revisit, Investigate, and Coordinate items. Decide which unresolved tasks still deserve attention.
Phase 03
Re-check the changes most likely to cause broad side effects before time expires.
Phase 04
Review every forensic answer and make sure the supporting evidence still makes sense.
Phase 05
Test what the system is supposed to do. Security changes are not complete if required functionality is broken.
Phase 06
As time becomes limited, raise the evidence threshold for new changes. Unverified high-impact guesses can undo strong earlier work.
Final review questions
What does the scenario still require?
Did any defensive change remove required functionality?
Are all authorized users and administrators correct?
Are required services still running and reachable?
Did any firewall, network, or permission change create a hidden failure?
Are completed tasks actually verified?
Which unresolved tasks still offer meaningful value?
Are forensic answers supported by evidence?
Did we create any temporary workaround that should be cleaned up?
Is there enough time to verify any new change we are considering?
Highest-risk areas
Re-check firewall rules, interfaces, DNS, routing, remote access, and other connectivity that may have been altered.
Confirm administrator access, account state, login paths, and any policy changes that could lock out authorized users.
Verify services, server roles, applications, and dependencies remain available after hardening.
Re-check file, share, group, and service permissions that could block legitimate access.
Confirm update activity or restarts did not leave the system in an unexpected state.
Make sure cleanup did not destroy evidence needed for unresolved forensic questions.
Unresolved work
Not every unresolved task should be touched at the end. Re-rank by value, confidence, risk, and available verification time.
Handle now if there is enough time to verify the result.
Investigate quickly or ask for a second review before changing the system.
Proceed only if the evidence is strong and verification can be completed.
Leave documented rather than making a last-minute guess.
Final minutes
The less time remains, the stronger the evidence should be before making a disruptive change.
Confirm known work before opening entirely new lines of investigation.
If required functionality is working and the suspected issue is weakly supported, avoid risky experimentation.
If you must make a late change, know how to restore the previous state if verification fails.
Team review
Runs the final review sequence, checks the task board, confirms scenario requirements, and prevents random last-minute changes.
Verify their major changes, required services, account state, permissions, updates, and unresolved tasks.
Confirm connectivity, device state, addressing, access controls, and any changes that could affect multiple systems.
Review every answer, supporting evidence, and any unresolved investigation that still needs attention.
Worked final-review cases
A teammate narrowed firewall access earlier. The required remote function worked at the time, but no one has checked it since other changes were made.
Weak response
Assume it is fine because it worked once.
Better response
Re-test the required remote function, confirm the intended rule remains in place, and check for later changes that may have altered connectivity.
An unfamiliar user remains on the system and the team still lacks strong evidence about whether it is authorized.
Weak response
Delete the account because the round is almost over.
Better response
Re-check the scenario and available evidence. If the conclusion remains uncertain and deletion could be disruptive, document the unresolved risk instead of guessing.
A required service was hardened earlier by changing permissions and network exposure.
Weak response
Check only that the service process is running.
Better response
Verify the service state, authorized access, required user workflow, and the security condition that was supposed to improve.
A forensic answer was written based on one ambiguous timestamp.
Weak response
Leave it because time is short.
Better response
Check whether another log, file, or event can confirm the conclusion. If not, clearly distinguish what is known from what is inferred.
Common mistakes
Large new changes are difficult to test under time pressure and can create failures that are harder to recover from.
The team may have accidentally violated a requirement while focusing on security settings.
A task marked done may never have been verified. Final review should separate changed from verified.
A hardened system that cannot perform its required role is not a successful final state.
Time pressure does not turn weak evidence into strong evidence.
The team should coordinate final checks so two people do not undo each other's work or miss shared dependencies.
Reflection
Question 1
Why should the scenario be re-read during final review?
Question 2
What kinds of changes deserve extra verification near the end of the round?
Question 3
Why should the evidence threshold rise as time becomes limited?
Question 4
What is the difference between a completed task and a verified task?
Question 5
How should the team handle a high-value unresolved issue with weak evidence?
Question 6
Why is required functionality part of final security verification?
Final review checklist
Re-read the scenario and ReadMe.
Confirm authorized users and administrators.
Confirm required services and applications.
Confirm restrictions and exceptions are still satisfied.
Review all Done / Verify tasks.
Review unresolved high-value tasks.
Re-check firewall and networking changes.
Re-check authentication and permission changes.
Test required services and user workflows.
Review every forensic answer and supporting evidence.
Look for temporary workarounds or unfinished changes.
Avoid broad new work that cannot be verified.
Document unresolved risks.
Finish with known-good, verified state whenever possible.
Final strategy lesson
The final lesson will combine the entire strategy section into one practical competition checklist that students can use during authorized practice rounds.