A transit IT lead requires that all active testing occur only after hours. How should that requirement be handled?
Select an answer to reveal the explanation.
Short Explanation
After-hours windows are traffic lights, not suggestions. Put them in the RoE so everyone knows when engines may run and whom to call if something breaks. Skill level does not buy a free pass around the client's clock.
Full Explanation
When a transit IT lead requires after-hours active testing, that constraint belongs in the rules of engagement as an operational bound on scheduling, on-call contacts, maintenance windows, and technique timing. It is not optional guidance that testers may discard when findings feel urgent; urgency still routes through the designated notification path. After-hours work is common and compatible with professional methodology, so rejecting the engagement solely for that reason is unnecessary. Moving everything to a cloud scanner does not erase local time-window needs for any on-network or production-impacting checks that still touch transit systems. Exam caveat: after-hours windows may still forbid noisy or availability-impacting techniques even when clocks allow packets, and emergency stops remain binding. Operational check: record permitted start/stop times, escalation contacts, and blackout dates in the RoE, sync calendars with transit operations, and pause active testing outside those windows unless a signed exception is granted by the transit security owner. In municipal operations, record the decision and residual risk in the engagement notes so future civic responders understand which control or boundary was honored and which failure modes the rejected approaches would create for public services. Re-check the same control at the next maintenance window or retest cycle.