Write a change request that would actually be approved

short · 40 min · Objective 3.1

Task

Produce a complete change request for a real change to your lab, execute it under that plan, and then close it properly. Change management is examined as a process, and writing one real request teaches the process faster than reading the stages.

Steps

  1. Pick the change: add a third subnet, 192.168.30.0/24, on a new router interface, and make it reachable from both existing subnets.
  2. Write the request with every section the objective names. Reason for the change — what problem it solves. Scope — exactly which devices and which config. Risk assessment — what could break, rated. Test plan — how you will know it worked. Rollback plan — the exact steps to undo it, which here is "restore snapshot pre-change-30". Schedule — when, and why that window.
  3. Have the plan reviewed. If you are working alone, leave it for an hour and reread it as a reviewer: the question a reviewer asks is "what happens if this fails at 03:00 and you are asleep?"
  4. Execute it, following your own steps exactly. If you deviate, write down the deviation — that is what a real change record captures.
  5. Close it: run the test plan, record the result, update the four documents from the previous lab, and mark the change complete.

Verify

ip addr show | grep -E "192.168.(10|20|30)"
ip route show
ping -c 2 192.168.30.1
sudo sysctl net.ipv4.ip_forward

The new interface must be present and addressed, the route table must include the new subnet, and forwarding must still be enabled. Then prove the rollback is real by restoring the snapshot and running the same four commands — the third subnet must be gone. A rollback plan you have never tested is a wish.

Notes

The step people skip is step 5, and it is the one that makes the difference. A change executed without updating documentation leaves the network correct and the records wrong, which is worse than either being wrong alone — because the next engineer trusts the record.

The exam also asks about the surrounding lifecycle. End-of-life is when a vendor stops selling; end-of-support is when it stops patching, and that is the date that matters for risk. A device past end-of-support with a published vulnerability has no fix coming, which makes replacement a security decision rather than a budget one.

Configuration backup belongs here too. Take a copy before the change and after it, and the difference between them is the most precise change record you can have.