2.2 Process flow, debugging approaches & elimination
Key Takeaways
- In a flowchart, a diamond is a two-way decision, a rectangle is an action, and you never move against an arrow.
- Tracing a loop means updating every variable at each step and watching the exit condition so you neither loop forever nor stop one iteration early.
- The best debugging test is the one that eliminates the largest share of suspects in a single move.
- A self-assigned 169.254 address is a high-information clue that points at a DHCP failure and rules out the cable and link at once.
- Checking the most recent change first is usually cheaper than auditing an entire system when something worked yesterday but not today.
Reading a process flow
A flowchart is a map of decisions. On the DoD Cyber Test you will trace inputs through boxes and diamonds to predict an output, so learning the shapes pays off immediately.
Flowchart symbols
| Symbol | Meaning | Reading tip |
|---|---|---|
| Rounded rectangle | Start or end (terminator) | Every valid path begins and ends here |
| Rectangle | Process step (an action) | Do exactly what it says, once |
| Diamond | Decision (yes/no branch) | Only two exits; follow the one your data satisfies |
| Parallelogram | Input or output | Read or write a value |
| Arrow | Flow of control | Never move against an arrow |
To trace a flow, keep a running value of every variable on paper and update it at each box. At a diamond, evaluate the condition with the current values and take the matching branch. Loops send an arrow back to an earlier point, so you repeat until the decision finally sends you out; watch the exit condition or you will loop forever.
Worked example: tracing a loop
A flow sets a number N equal to ten. The loop says: while N is greater than one, subtract three from N and print N.
- Start: N is ten. Ten is greater than one, so subtract three, making N seven. Print seven.
- Seven is greater than one, so subtract three, making N four. Print four.
- Four is greater than one, so subtract three, making N one. Print one.
- Is one greater than one? No. Exit the loop.
The printed sequence is seven, four, one. A frequent trap is to print the starting value ten, but the flow subtracts before it prints, so ten never appears. Another trap is a fourth line: once N reaches one the decision fails, so the loop stops there.
Nested decisions multiply the paths: a diamond inside the yes branch of another diamond creates four possible routes, so label each branch as you commit to it. When a question supplies sample inputs, push each one through the entire chart and record its output, then match your traced outputs against the answer choices. That mechanical approach is faster and far safer than trying to reason about the whole chart in the abstract, where it is easy to skip a branch or forget which condition you are inside.
A flow sets N to ten, then repeats: while N is greater than one, subtract three from N and print N. What does it print?
Debugging by isolation and elimination
Debugging is applied divide-and-conquer. The goal is to shrink the set of possible causes as fast as possible, spending each test where it rules out the most.
The elimination grid
When several suspects each could explain a fault, a grid keeps you honest. A workstation cannot reach the internet, and you list four candidate causes.
| Suspect | Test | Result | Eliminated? |
|---|---|---|---|
| Bad network cable | Swap in a known-good cable | Still no connection | Yes, not the cable |
| Wi-Fi disabled | Confirm the wired port shows a link light | Link light is on | Yes, link is up |
| Wrong IP settings | Check the address; it is a self-assigned 169.254 address | No valid lease | No, keep this |
| DNS server down | Cannot test yet; no valid IP at all | Blocked | No, retest later |
The self-assigned address is the strongest lead, because a device only assigns itself a 169.254 address when it cannot reach the DHCP server. That single fact eliminates the cable and the link and points at DHCP, one observation collapsing several branches at once. Good debuggers hunt for exactly these high-information tests.
Isolation tactics
- Swap to a known-good part. If replacing a component fixes the fault, that component was the cause; if not, you have eliminated it.
- Minimal reproduction. Strip the system to the smallest setup that still shows the bug, then add pieces back until it breaks.
- Split the difference. For a chain of dependencies, test the midpoint rather than one end.
- Check the most recent change first. If it worked yesterday and not today, whatever changed between is the prime suspect, far cheaper than auditing the whole system.
A workstation has no internet and shows a self-assigned 169.254 address. Why does this single observation eliminate the cable and the link as causes?
Worked example: which test first?
A message fails to send. It could be the app, the account, the network, or the mail server. You can run only one test. Which is better: sending a different message type from the same app, or pinging the mail server?
Pinging the mail server is the higher-value test. If the ping fails, you have ruled the app and account innocent and localized the fault to the network path or the server. If the ping succeeds, you have eliminated the network entirely and can focus on the app and account. Either outcome cuts the four suspects roughly in half. A test that can only ever implicate one suspect gives you less.
This is the core exam skill: rank the candidate tests by how much of the suspect list each one can remove, then run the highest-payoff test first. A single test that splits the field in half is worth several tests that each clear only one suspect, even if those single-suspect tests feel more direct. Ask of every proposed check, "which outcomes are possible, and what does each outcome rule out?" before you spend the move.
Common traps
- Testing the easy thing instead of the informative thing. Rebooting is easy but rarely tells you why it failed.
- Not resetting variables between tests. If you leave one change in place while making another, you cannot attribute the result.
- Ignoring the error message. The message often names the failing layer; read it before theorizing.
- Assuming correlation is cause. Two events at the same time may share a third cause; verify the link.
On the exam, the best answer is almost always the test that eliminates the largest share of possibilities in one move, not the one that is quickest to perform.