A fire district configures closet switches to synchronize time from a core NTP server. What NTP role are those closet switches playing?
Select an answer to reveal the explanation.
Short Explanation
Closet switches asking the core for the time are NTP clients—plain and simple. They are not pretending to be atomic clocks for the planet. Get them pointed at the core server so fire-district logs line up.
Full Explanation
Fire-district closet switches configured to synchronize time from a core NTP server are operating in NTP client mode: they obtain time from the configured server rather than acting as the authoritative source for the Internet. Consistent timestamps across access closets improve log correlation, certificate validation, and incident response for municipal infrastructure. Client-mode sync to a trusted core NTP source is the CCNA role association in this scenario and is how closet devices inherit a common time base from the district’s hierarchy.
Claiming those switches are an NTP stratum-0 atomic-clock source for the entire Internet fails by concept: stratum 0 refers to reference clocks such as GPS or atomic oscillators, not closet switches polling a core server. Calling them the authoritative DNS primary for reverse zones only fails by concept: DNS name service and NTP time service are different functions with different configuration and verification commands. Saying they are an SNMP trap receiver that replaces the need for synchronized clocks fails by concept: trap receivers collect SNMP notifications; they do not substitute for synchronized timekeeping across devices.
Exam caveat: client devices point at reachable NTP servers; stratum hierarchy matters for resilient design, but “closet switch = NTP client to core” is the expected association on this item. Operational check: configure NTP server statements toward the core, verify NTP associations and sync status on closet switches, and confirm logs across fire-district devices share coherent timestamps during troubleshooting drills.