An engineer configures time synchronization through the management GUI on a fresh appliance, enters the site's time servers, closes the browser tab, and marks the checklist item complete. Days later, log correlation against other systems is unreliable. What step was missing?
Select an answer to reveal the explanation.
Short Explanation
Dialing the number is not the same as someone answering. Entering time servers only proves the form accepted your text — the sync state is the proof you actually need. Don't close that tab until you've seen what the platform says the clock is doing right now.
Full Explanation
Applying time settings and having time actually work are different states. The GUI commits the server entries immediately, but synchronization additionally requires network reachability, an operational service on the sources, and time for the adjustment to settle — so the honest completion signal is the platform's own sync status, verified to show a chosen source and an agreement between the system clock and the reference. SSH enablement has no bearing on whether the appliance can reach NTP servers; that is ordinary network reachability on the time protocol, not a privileged management path. The boot-only claim fails because time services consume configuration changes without a chassis restart, and an unnecessary reboot of a freshly commissioned system adds risk instead of verification. The hostname-only assertion is wrong — addresses are accepted — and forcing a DNS dependency into the very service people later need when DNS is degraded adds a failure mode rather than removing one. Exam caveat: a newly added source can take several polling intervals before it is marked as synchronized; the verification step waits and checks status rather than re-entering settings. Operational check: after entering servers, query the time service status, confirm a source is marked synchronized, and compare the displayed time against a known reference before closing the task.