Competition Strategy 04
Decide what to work on first by balancing confidence, security impact, risk, time, and available evidence.
A strong team does not simply complete tasks in the order they are discovered. It continuously asks which action creates the most useful progress without creating unnecessary risk.
Lesson Snapshot
Learning objectives
Prioritize competition tasks using confidence, impact, risk, time, and evidence instead of instinct alone.
Distinguish high-confidence fixes from investigation tasks and risky changes.
Use a revisit queue so difficult problems do not consume the entire round.
Recognize when a technically important task should still be delayed because the evidence is incomplete.
Explain why disruptive changes require stronger justification and verification.
Build a repeatable prioritization process that can be used across Windows, Linux, Server, Cisco, and Forensics.
Core concept
A task can have high security value and still be a poor first move if the evidence is weak or the risk of disruption is high.
Prioritization is the process of deciding not only what matters, but what the team is ready to handle safely right now.
Competition trap
Every minute spent on one task is a minute not spent somewhere else. A low-value mystery can quietly cost more than several clear security fixes.
Five priority factors
How certain are you that the condition is actually a problem and that the proposed change addresses it?
How much security value could the task provide if completed correctly?
Could the change disrupt networking, authentication, required services, permissions, evidence, or another teammate's work?
How long will the task probably take compared with other available work?
What scenario, system, policy, or forensic evidence supports the decision?
Four task categories
Do Now
These tasks are usually good early targets because the team understands the problem, can explain the fix, and knows how to verify the result.
Investigate
These findings deserve attention, but the team needs more context before changing the system.
Coordinate
These tasks may be necessary, but they should be communicated and verified carefully because mistakes can affect the entire image.
Revisit
These tasks should stay visible without dominating the round. Return later with more evidence, a fresh perspective, or teammate help.
Quick decision matrix
Ask before starting
What evidence proves this is a problem?
What security value does the task provide?
What could break if the assumption is wrong?
Does the scenario require the affected user, service, application, or capability?
How long will this probably take?
Can the result be verified quickly?
Is another teammate already working on a related area?
Would a different task provide more value with less uncertainty?
Time traps
Moving on is not giving up. It is a deliberate decision to protect the team's time until new evidence or a new perspective makes the problem easier to solve.
You have repeated the same failed attempt several times.
The task requires more assumptions than evidence.
You are researching a low-impact detail while clear high-value work remains.
You cannot explain what success would look like.
The task depends on another unresolved issue.
A teammate has useful expertise but you have not asked for help.
Revisit queue
Write down what you observed, what you expected, and what remains unknown.
Save the error message, setting, log location, command output, or other clue that will help when you return.
Define what you need to learn next instead of writing a vague note such as 'fix later.'
Use the remaining time on tasks with clearer evidence or better value.
Come back after another task, new evidence, or teammate review changes the situation.
Worked cases
The scenario names one authorized administrator. A second account is clearly in the administrators group with no requirement for elevated access.
Weak decision
Ignore it because there are many other settings to check.
Strong decision
Treat it as high-confidence, high-value work. Confirm the account itself is still required, correct the privilege mismatch, and verify group membership afterward.
A service is running that the student does not recognize, but the scenario says the machine must support a related application.
Weak decision
Disable it immediately because unknown services are suspicious.
Strong decision
Place it in Investigate. Determine what it supports, whether it is required, and what would happen if it were stopped.
A firewall rule appears too permissive, but the machine must remain reachable for a required function.
Weak decision
Delete the rule without checking dependencies.
Strong decision
Place it in Coordinate. Identify the required traffic, narrow the rule if appropriate, and verify the required connection afterward.
A cosmetic configuration inconsistency has taken 15 minutes to diagnose while several clear security issues remain.
Weak decision
Keep working until it is solved because stopping feels like failure.
Strong decision
Record the issue, move it to Revisit, and return only after higher-value tasks are handled.
Common mistakes
A hard problem can feel important simply because it is consuming attention. Judge value separately from difficulty.
Low-value tasks can create activity without meaningful progress. Balance ease with security impact.
A technically valid change can still be dangerous if it affects required functionality or team coordination.
Moving on should be temporary. Keep a visible revisit queue so unresolved work does not disappear.
Impact cannot be judged correctly if the team does not understand what the machine is supposed to do.
New evidence can change what matters. Re-rank tasks as the round develops.
Reflection
Question 1
Why might a high-impact task still be a bad first move?
Question 2
What is the difference between a Do Now task and an Investigate task?
Question 3
When should a task be moved to Revisit?
Question 4
Why does risk matter even when the proposed change improves security?
Question 5
How can a team avoid spending too long on one difficult issue?
Question 6
Why should priorities be updated as new evidence appears?
Prioritization checklist
Confirm the task is supported by evidence.
Estimate the security value.
Estimate the risk of disruption.
Estimate the likely time cost.
Decide whether the task belongs in Do Now, Investigate, Coordinate, or Revisit.
Communicate high-impact tasks before changing the system.
Define how the result will be verified.
Move blocked tasks to the revisit queue instead of repeating failed attempts.
Capture useful evidence before moving on.
Ask for teammate help when another perspective could reduce uncertainty.
Re-rank priorities when new evidence appears.
Use final review time to return to unresolved high-value items.
Next strategy lesson
Next, learn how to divide responsibility across Windows, Linux, Server, Cisco, forensics, and coordination without creating duplicate work or communication gaps.