Ntp practice questions

Match each network service to its primary function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Resolves hostnames to IP addresses

Assigns IP configuration to clients

Synchronizes device time

Collects and stores log messages

Trap 1: DNS: Assigns IP addresses dynamically to devices on a network

Dynamic IP assignment is the job of DHCP (Dynamic Host Configuration Protocol), which leases IP addresses, subnet masks, default gateways, and other parameters to clients for a set duration. DNS is a peer-to-peer name-resolution service that stores resource records; it has no mechanism for leasing or reclaiming IP addresses. So, attributing dynamic address assignment to DNS is incorrect because that service belongs exclusively to DHCP.

Trap 2: DNS: Synchronizes time across network devices

Precise time synchronization across network devices is handled by NTP (Network Time Protocol), which distributes Coordinated Universal Time (UTC) to maintain accurate clocks for log correlation, authentication, and timestamping. DNS handles only name-to-address (and related) queries, and it has no protocol operations for reading or setting device clocks. Therefore, DNS cannot serve as a time-synchronization protocol.

Trap 3: DNS: Manages and monitors network devices

Managing and monitoring network devices—such as polling CPU, memory, interface status, and generating alerts—is the function of SNMP (Simple Network Management Protocol), whose managed objects are defined in MIBs. DNS is strictly a resolution service that translates names to IP addresses as part of application-layer lookups; it does not collect device metrics or perform management operations. Describing DNS as a network management protocol is inaccurate because that role belongs to SNMP.

A
DNS: Translates domain names to IP addresses
The Domain Name System acts as the internet's distributed directory, mapping human-readable fully qualified domain names like www.example.com to the numeric IP addresses needed for packet forwarding. Without this lookup, users would have to memorize and manually enter raw IPv4 or IPv6 addresses, which is impractical. DNS uses hierarchical caching servers to resolve names rapidly and efficiently.
B
DNS: Assigns IP addresses dynamically to devices on a network
Why wrong: Dynamic IP assignment is the job of DHCP (Dynamic Host Configuration Protocol), which leases IP addresses, subnet masks, default gateways, and other parameters to clients for a set duration. DNS is a peer-to-peer name-resolution service that stores resource records; it has no mechanism for leasing or reclaiming IP addresses. So, attributing dynamic address assignment to DNS is incorrect because that service belongs exclusively to DHCP.
C
DNS: Synchronizes time across network devices
Why wrong: Precise time synchronization across network devices is handled by NTP (Network Time Protocol), which distributes Coordinated Universal Time (UTC) to maintain accurate clocks for log correlation, authentication, and timestamping. DNS handles only name-to-address (and related) queries, and it has no protocol operations for reading or setting device clocks. Therefore, DNS cannot serve as a time-synchronization protocol.
D
DNS: Manages and monitors network devices
Why wrong: Managing and monitoring network devices—such as polling CPU, memory, interface status, and generating alerts—is the function of SNMP (Simple Network Management Protocol), whose managed objects are defined in MIBs. DNS is strictly a resolution service that translates names to IP addresses as part of application-layer lookups; it does not collect device metrics or perform management operations. Describing DNS as a network management protocol is inaccurate because that role belongs to SNMP.

Question 2hardScenario

You are connected to R1. Configure NTP client so that R1 synchronizes with the NTP server at 198.51.100.10, using its Loopback0 (10.0.0.1/32) as the source interface. Also configure syslog to send messages of severity 5 (notifications) and above to 192.0.2.20. The current configuration shows a misconfigured NTP server address and an incorrect logging trap level. Verify with 'show ntp status' (stratum should not be 16) and 'show logging'.

Exhibit

R1#show running-config | include ntp|logging
ntp server 203.0.113.5
logging host 192.0.2.20
logging trap debugging
!
R1#show ntp status
Clock is unsynchronized, stratum 16, no reference clock
R1#show ip interface brief | include Loopback0
Loopback0               10.0.0.1       YES manual up                    up
R1#

Trap 1: ntp server 198.51.100.10 source Loopback0 logging trap 4

This is incorrect because 'logging trap 5' uses the numeric severity level, but the question expects the keyword 'notifications' for severity 5. While both are technically valid, the question specifies 'severity 5 (notifications)', and the correct answer uses the keyword.

Trap 2: ntp server 198.51.100.10 logging trap notifications

This is incorrect because it omits the 'source Loopback0' parameter. Without specifying the source interface, the NTP client will use the outgoing interface IP, which may not be Loopback0, potentially causing reachability or authentication issues.

Trap 3: ntp server 203.0.113.5 source Loopback0 logging trap 7

This is incorrect because it uses the wrong NTP server address (203.0.113.5 instead of 198.51.100.10) and sets the logging trap level to debugging (7), which sends all messages instead of only notifications (5) and above.

A
ntp server 198.51.100.10 source Loopback0 logging trap notifications
This is the correct configuration because it specifies the exact NTP server 198.51.100.10 and uses the `source Loopback0` keyword to force all NTP packets to originate from Loopback0’s IP address. That guarantees a consistent source IP for NTP, which is essential when the NTP server is configured to accept requests only from that address or when building an NTP access-group. The `logging trap notifications` command sets the syslog trap severity to level 5 (notifications), matching the requirement to send severities 5 and above—keyword and numeric severity are equivalent, but the keyword is used here as specified.
B
ntp server 198.51.100.10 source Loopback0 logging trap 4
Why wrong: This is incorrect because 'logging trap 5' uses the numeric severity level, but the question expects the keyword 'notifications' for severity 5. While both are technically valid, the question specifies 'severity 5 (notifications)', and the correct answer uses the keyword.
C
ntp server 198.51.100.10 logging trap notifications
Why wrong: This is incorrect because it omits the 'source Loopback0' parameter. Without specifying the source interface, the NTP client will use the outgoing interface IP, which may not be Loopback0, potentially causing reachability or authentication issues.
D
ntp server 203.0.113.5 source Loopback0 logging trap 7
Why wrong: This is incorrect because it uses the wrong NTP server address (203.0.113.5 instead of 198.51.100.10) and sets the logging trap level to debugging (7), which sends all messages instead of only notifications (5) and above.

Question 3hardmultiple choice

A network administrator notices that syslog messages from a core router are arriving at the syslog server with timestamps that are hours behind other devices. The router’s NetFlow exports also show incorrect start and end times for flows, making traffic analysis unreliable. The administrator verifies that all router interfaces are up and that the SNMP community strings on the router match the NMS.

Trap 1: The logging trap level is set to informational, so only…

Setting the logging trap level to informational actually allows all messages of severity informational and higher (levels 0–6) to be sent. Even if only emergencies were sent, their timestamps would still be accurate if the router’s clock is correct.

Trap 2: The SNMP v3 user’s privacy password is incorrect, causing the NMS…

SNMP v3 authentication and privacy settings control SNMP traps, which are separate from syslog messages. Syslog uses UDP port 514 and does not depend on SNMP v3 credentials. An SNMP v3 misconfiguration would affect trap delivery, not syslog timestamps or NetFlow exports.

Trap 3: The IP flow cache timeout is set too low, causing NetFlow…

The flow cache timeout determines how long an active flow is kept in the cache before it is exported. A lower timeout exports flows more frequently but does not alter the actual start or end times recorded in the flow records. The timestamps in NetFlow records come from the system clock, not the cache timer.

A
The logging trap level is set to informational, so only high-severity messages are sent with correct timestamps.
Why wrong: Setting the logging trap level to informational actually allows all messages of severity informational and higher (levels 0–6) to be sent. Even if only emergencies were sent, their timestamps would still be accurate if the router’s clock is correct.
B
The router’s NTP client is configured with an incorrect authentication key.
NTP can use authentication keys to verify server identity. If the client key does not match the server’s key, the router will not trust the time updates and will fail to synchronize. This leaves the router’s clock uncorrected, causing incorrect timestamps in syslog and NetFlow records.
C
The SNMP v3 user’s privacy password is incorrect, causing the NMS to reject syslog traps.
Why wrong: SNMP v3 authentication and privacy settings control SNMP traps, which are separate from syslog messages. Syslog uses UDP port 514 and does not depend on SNMP v3 credentials. An SNMP v3 misconfiguration would affect trap delivery, not syslog timestamps or NetFlow exports.
D
The IP flow cache timeout is set too low, causing NetFlow timestamps to appear skewed.
Why wrong: The flow cache timeout determines how long an active flow is kept in the cache before it is exported. A lower timeout exports flows more frequently but does not alter the actual start or end times recorded in the flow records. The timestamps in NetFlow records come from the system clock, not the cache timer.

Question 4mediummatching

Match each operations or assurance technology to its most accurate purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Centralized event and message reporting

Monitoring and management information exchange

Visibility into traffic flows and conversations

Clock synchronization for consistent timing

Trap 1: NetFlow - Device management; SNMP - Flow analysis; Syslog -…

It swaps the purposes of several technologies: NetFlow is not for device management, SNMP is not for flow analysis, Syslog is not for performance measurement, IP SLA is not for logging, SPAN is local not remote, and RSPAN is remote not local.

Trap 2: NetFlow - Logging; SNMP - Performance measurement; Syslog - Flow…

It misassigns each technology: NetFlow is not for logging, SNMP is not for performance measurement, Syslog is not for flow analysis, IP SLA is not for device management, SPAN is local not remote, and RSPAN is remote not local.

Trap 3: NetFlow - Performance measurement; SNMP - Logging; Syslog - Device…

It misassigns several technologies: NetFlow is not for performance measurement, SNMP is not for logging, Syslog is not for device management, and IP SLA is not for flow analysis. However, SPAN and RSPAN are correctly matched.

A
NetFlow - Flow analysis; SNMP - Device management; Syslog - Logging; IP SLA - Performance measurement; SPAN - Local traffic mirroring; RSPAN - Remote traffic mirroring
Ly matches each technology to its primary purpose as defined in Cisco networking: NetFlow analyzes traffic flows, SNMP manages devices, Syslog provides logging, IP SLA measures performance, SPAN mirrors traffic locally, and RSPAN mirrors traffic remotely.
B
NetFlow - Device management; SNMP - Flow analysis; Syslog - Performance measurement; IP SLA - Logging; SPAN - Remote traffic mirroring; RSPAN - Local traffic mirroring
Why wrong: It swaps the purposes of several technologies: NetFlow is not for device management, SNMP is not for flow analysis, Syslog is not for performance measurement, IP SLA is not for logging, SPAN is local not remote, and RSPAN is remote not local.
C
NetFlow - Logging; SNMP - Performance measurement; Syslog - Flow analysis; IP SLA - Device management; SPAN - Remote traffic mirroring; RSPAN - Local traffic mirroring
Why wrong: It misassigns each technology: NetFlow is not for logging, SNMP is not for performance measurement, Syslog is not for flow analysis, IP SLA is not for device management, SPAN is local not remote, and RSPAN is remote not local.
D
NetFlow - Performance measurement; SNMP - Logging; Syslog - Device management; IP SLA - Flow analysis; SPAN - Local traffic mirroring; RSPAN - Remote traffic mirroring
Why wrong: It misassigns several technologies: NetFlow is not for performance measurement, SNMP is not for logging, Syslog is not for device management, and IP SLA is not for flow analysis. However, SPAN and RSPAN are correctly matched.

Review the full routing breakdown →

Question 5hardmultiple choice

A network administrator notices that the NTP server on Router R1 is not synchronizing with the upstream NTP server at 192.0.2.1. The router is configured as an NTP client, but show ntp status indicates the clock is unsynchronized and the stratum is 16. There is no firewall between R1 and 192.0.2.1. What is the most likely cause of this issue?

Exhibit

R1# show ntp status
Clock is synchronized, stratum 16, reference is 0.0.0.0
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
ntp uptime is 100 minutes, resolution is 4000 msec
reference time is D8C4E1C0.00000000 (12:34:56.000 UTC Mon Mar 15 2021)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec

R1# show ntp associations
  address         ref clock     st  when  poll reach  delay  offset   disp
*~192.0.2.1      0.0.0.0       16    -    64    0     0.000  0.000   16000.
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Trap 1: The NTP server at 192.0.2.1 is not configured as a peer on R1.

The output of `show ntp associations` displays a `~` beside 192.0.2.1, which indicates that the peer or server is indeed configured on R1. The fact that it is not reachable is a separate operational issue, not a configuration omission. Re-issuing the `ntp peer` or `ntp server` command would not fix the problem because the configuration already exists; the actual failure is the missing route.

Trap 2: The NTP server at 192.0.2.1 is not using NTP version 4.

NTP version negotiation is inherent in the protocol: NTPv4 clients can communicate with servers running older versions, and a version mismatch would not typically cause the reach register to be zero or the stratum to remain at 16. The output shows the server is reachable (albeit unsynchronized) and there is no indication of a version error in the status flags or association details. Thus, the problem is not the server's NTP version.

Trap 3: The NTP server at 192.0.2.1 has a firewall blocking NTP traffic.

A firewall blocking NTP would prevent UDP port 123 traffic, but it would not cause the remote server itself to advertise stratum 16. The reach value of 0 and stratum of 16 indicate that R1 cannot obtain a valid NTP response, which is more consistent with a missing route or an unsynchronized server than a firewall filter. Furthermore, if a firewall were silently dropping packets, R1 would show the server as configured but unreachable, while the server's own stratum would remain independent of the firewall.

A
The NTP server at 192.0.2.1 is not configured as a peer on R1.
Why wrong: The output of `show ntp associations` displays a `~` beside 192.0.2.1, which indicates that the peer or server is indeed configured on R1. The fact that it is not reachable is a separate operational issue, not a configuration omission. Re-issuing the `ntp peer` or `ntp server` command would not fix the problem because the configuration already exists; the actual failure is the missing route.
B
Router R1 does not have a route to reach 192.0.2.1.
For NTP to function, R1 must have a valid IP route to 192.0.2.1 in its routing table. Without that route, outgoing NTP packets are discarded with a 'no route to host' condition, and no replies ever arrive, leaving the server at stratum 16 with a reachability of 0. The `show ntp status` command would report the clock unsynchronized, and `show ntp associations` would show the peer as configured but unreachable.
C
The NTP server at 192.0.2.1 is not using NTP version 4.
Why wrong: NTP version negotiation is inherent in the protocol: NTPv4 clients can communicate with servers running older versions, and a version mismatch would not typically cause the reach register to be zero or the stratum to remain at 16. The output shows the server is reachable (albeit unsynchronized) and there is no indication of a version error in the status flags or association details. Thus, the problem is not the server's NTP version.
D
The NTP server at 192.0.2.1 has a firewall blocking NTP traffic.
Why wrong: A firewall blocking NTP would prevent UDP port 123 traffic, but it would not cause the remote server itself to advertise stratum 16. The reach value of 0 and stratum of 16 indicate that R1 cannot obtain a valid NTP response, which is more consistent with a missing route or an unsynchronized server than a firewall filter. Furthermore, if a firewall were silently dropping packets, R1 would show the server as configured but unreachable, while the server's own stratum would remain independent of the firewall.

Question 6hardmultiple choice

A network engineer notices that the system clock on a Cisco IOS-XE router is incorrect, causing syslog timestamps to be unreliable. The router is configured as an NTP client to synchronize with a remote NTP server at 192.168.1.10. However, the show ntp status command indicates the clock is unsynchronized. What is the most likely cause of this issue?

Exhibit

Router# show ntp status
Clock is synchronized, stratum 16, reference is 0.0.0.0
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
reference time is 0.0.0.0
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec

Router# show ntp associations

  address         ref clock     st  when  poll reach  delay  offset   disp
*~192.168.1.10    .INIT.          16    -    64    0     0.0    0.00  16000.
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Router# show running-config | include ntp
ntp server 192.168.1.10

Trap 1: The NTP server is using TCP instead of UDP for NTP communication.

NTP is a protocol that exclusively uses UDP port 123 for both client requests and server replies; it does not have a TCP implementation for standard time synchronization. If the server were somehow configured to use TCP, the router's NTP client would still send its requests via UDP and would simply receive no response, but this scenario does not occur in practice because TCP is only used for NTP-over-TCP tunneling or diagnostic utilities, not for production NTP. Therefore, a TCP/UDP mismatch is not a plausible explanation for the reachability failure shown by the reach counter.

Trap 2: The NTP server has a higher stratum level than the router's local…

A server with a higher stratum number (e.g., stratum 4) is considered less authoritative than the router's own local clock if the router is running as stratum 3, so the NTP selection algorithm would choose not to synchronize to that server. However, this stratum-based preference only affects which of multiple reachable servers is selected as the synchronization source; it does not affect the router's ability to exchange NTP packets with the server. The reach counter would still reflect successful NTP packet exchanges even if the server's stratum caused it to be rejected for sync, so a reach of 0 cannot be explained by stratum alone. In fact, the router would still receive and process NTP messages, just not use them for clock synchronization.

Trap 3: NTP authentication is misconfigured on the router.

NTP authentication is a security feature that uses MD5 or SHA1 keys to verify the authenticity of NTP messages, but the running-configuration on the router does not display an 'ntp authentication-key' or 'ntp trusted-key' statement, so authentication is not enabled on this device. Even if authentication were enabled, a mismatch of keys would cause the router to drop the NTP response immediately after receiving it, which would typically update the reach counter to a nonzero value or generate an authentication failure log, rather than keeping reach at zero. The absence of any authentication configuration and the complete lack of received packets point to a connectivity issue, not a key mismatch.

A
The NTP server is using TCP instead of UDP for NTP communication.
Why wrong: NTP is a protocol that exclusively uses UDP port 123 for both client requests and server replies; it does not have a TCP implementation for standard time synchronization. If the server were somehow configured to use TCP, the router's NTP client would still send its requests via UDP and would simply receive no response, but this scenario does not occur in practice because TCP is only used for NTP-over-TCP tunneling or diagnostic utilities, not for production NTP. Therefore, a TCP/UDP mismatch is not a plausible explanation for the reachability failure shown by the reach counter.
B
The router cannot reach the NTP server due to a missing route or firewall blocking UDP port 123.
The reach value of 0 in the 'show ntp status' output indicates that the router has not received any successful NTP responses from the configured server across the last eight polling attempts. This is typically caused by a Layer 3 routing problem preventing the router from sending packets to the server's IP address, or by a firewall/ACL dropping either the outbound request or the inbound reply because NTP uses UDP port 123. Without reachability, the router can never achieve synchronization, even if the server is running correctly and all other NTP settings match.
C
The NTP server has a higher stratum level than the router's local clock, so the router ignores it.
Why wrong: A server with a higher stratum number (e.g., stratum 4) is considered less authoritative than the router's own local clock if the router is running as stratum 3, so the NTP selection algorithm would choose not to synchronize to that server. However, this stratum-based preference only affects which of multiple reachable servers is selected as the synchronization source; it does not affect the router's ability to exchange NTP packets with the server. The reach counter would still reflect successful NTP packet exchanges even if the server's stratum caused it to be rejected for sync, so a reach of 0 cannot be explained by stratum alone. In fact, the router would still receive and process NTP messages, just not use them for clock synchronization.
D
NTP authentication is misconfigured on the router.
Why wrong: NTP authentication is a security feature that uses MD5 or SHA1 keys to verify the authenticity of NTP messages, but the running-configuration on the router does not display an 'ntp authentication-key' or 'ntp trusted-key' statement, so authentication is not enabled on this device. Even if authentication were enabled, a mismatch of keys would cause the router to drop the NTP response immediately after receiving it, which would typically update the reach counter to a nonzero value or generate an authentication failure log, rather than keeping reach at zero. The absence of any authentication configuration and the complete lack of received packets point to a connectivity issue, not a key mismatch.

Question 7mediummultiple choice

Which service would a client most directly rely on to convert `server.example.com` into an IP address?

Trap 1: ARP

Address Resolution Protocol operates at Layer 2 (data link) and maps a known IPv4 address to a MAC address on a local subnet. It is used after a host already knows the destination IP, typically obtained via DNS, and needs to encapsulate frames. ARP never resolves hostnames; it resolves IP-to-MAC mappings within a broadcast domain. Thus, it cannot convert a hostname into an IP address.

Trap 2: NTP

Network Time Protocol is used to synchronize the clocks of network devices and hosts to a time source such as an atomic clock or GPS. It ensures that timestamping for logs, authentication, and scheduling is consistent across devices. NTP has no role in name resolution; it operates on the application layer to distribute time, not addressing information. A client would never query NTP to convert a hostname.

Trap 3: CDP

Cisco Discovery Protocol is a proprietary Layer 2 protocol that allows Cisco devices to share information about directly connected neighbors, such as device type, IP address, and platform. CDP is used for network discovery and mapping, not for resolving hostnames requested by a client. A client application does not rely on CDP to translate a name into an IP; CDP advertisements are sent to a multicast address and are not consulted by typical host processes. Therefore, CDP is unrelated to hostname resolution.

A
DNS
The Domain Name System is the service that directly performs hostname-to-IP address resolution. When a client types a URL like www.cisco.com, it sends a DNS query to a resolver, which returns the corresponding IPv4 or IPv6 address. This is the fundamental name resolution service on which applications rely before establishing TCP connections. Without DNS, users would need to memorize numeric IP addresses.
B
ARP
Why wrong: Address Resolution Protocol operates at Layer 2 (data link) and maps a known IPv4 address to a MAC address on a local subnet. It is used after a host already knows the destination IP, typically obtained via DNS, and needs to encapsulate frames. ARP never resolves hostnames; it resolves IP-to-MAC mappings within a broadcast domain. Thus, it cannot convert a hostname into an IP address.
C
NTP
Why wrong: Network Time Protocol is used to synchronize the clocks of network devices and hosts to a time source such as an atomic clock or GPS. It ensures that timestamping for logs, authentication, and scheduling is consistent across devices. NTP has no role in name resolution; it operates on the application layer to distribute time, not addressing information. A client would never query NTP to convert a hostname.
D
CDP
Why wrong: Cisco Discovery Protocol is a proprietary Layer 2 protocol that allows Cisco devices to share information about directly connected neighbors, such as device type, IP address, and platform. CDP is used for network discovery and mapping, not for resolving hostnames requested by a client. A client application does not rely on CDP to translate a name into an IP; CDP advertisements are sent to a multicast address and are not consulted by typical host processes. Therefore, CDP is unrelated to hostname resolution.

Question 8mediummultiple choice

Why is NTP especially valuable when a network uses centralized Syslog servers?

Trap 1: Because NTP converts Syslog into a routing protocol

NTP is a time-synchronization protocol that exchanges timestamped timing packets over UDP 123; it carries no Syslog payload or routing information. Syslog remains a separate application-layer protocol over UDP 514, and routing protocols such as OSPF or EIGRP have their own update and neighbor mechanisms. Aligning device clocks cannot rewrite or convert one protocol into another, so this option fundamentally misstates NTP's function.

Trap 2: Because NTP automatically creates DHCP pools

DHCP pool creation is a manual configuration task performed on a DHCP server or a router running the DHCP service, involving address ranges, lease times, and options such as default gateway and DNS. NTP has no mechanism for, or interaction with, DHCP address allocation; it operates over UDP 123 and simply adjusts time on clients. Confusing NTP with DHCP pool generation confuses time synchronization with dynamic host configuration.

Trap 3: Because NTP eliminates the need for a Syslog server

A Syslog server is still required as the central collector, storage, and alerting engine for log messages, regardless of how accurate device clocks are. NTP only synchronizes clock time so every device agrees on Coordinated Universal Time; it does not gather, index, or store event messages. Removing the Syslog server would eliminate the central logging plane, leaving time-synchronized logs stranded on individual devices.

A
Because synchronized clocks make log timestamps easier to correlate across devices
When all network devices reference the same authoritative NTP source, their log timestamps are expressed in the same time scale, so an administrator can accurately sequence events across routers, switches, and firewalls during troubleshooting. Centralized log correlation depends on consistent timestamps; without NTP, even devices with identical configurations can drift, making a single incident appear to happen at different times or in the wrong order. NTP therefore makes centralized logging meaningful by providing a common temporal reference.
B
Because NTP converts Syslog into a routing protocol
Why wrong: NTP is a time-synchronization protocol that exchanges timestamped timing packets over UDP 123; it carries no Syslog payload or routing information. Syslog remains a separate application-layer protocol over UDP 514, and routing protocols such as OSPF or EIGRP have their own update and neighbor mechanisms. Aligning device clocks cannot rewrite or convert one protocol into another, so this option fundamentally misstates NTP's function.
C
Because NTP automatically creates DHCP pools
Why wrong: DHCP pool creation is a manual configuration task performed on a DHCP server or a router running the DHCP service, involving address ranges, lease times, and options such as default gateway and DNS. NTP has no mechanism for, or interaction with, DHCP address allocation; it operates over UDP 123 and simply adjusts time on clients. Confusing NTP with DHCP pool generation confuses time synchronization with dynamic host configuration.
D
Because NTP eliminates the need for a Syslog server
Why wrong: A Syslog server is still required as the central collector, storage, and alerting engine for log messages, regardless of how accurate device clocks are. NTP only synchronizes clock time so every device agrees on Coordinated Universal Time; it does not gather, index, or store event messages. Removing the Syslog server would eliminate the central logging plane, leaving time-synchronized logs stranded on individual devices.

Question 9hardmultiple choice

A switch shows a clock that is several minutes off from other devices even though an NTP server has been configured. Which issue is the most likely cause?

Exhibit

show ntp associations
 address         ref clock     st when poll reach delay offset disp
*~10.10.50.5     .INIT.        16   -   64    0  0.000  0.000 16000
Configured server: 10.10.50.5

Trap 1: The device must run Syslog before NTP can sync

Syslog and NTP are entirely separate services: syslog forwards log messages to a collector, while NTP synchronizes wall-clock time. The switch will happily update its clock from an NTP server even if no syslog server is defined, and the absence of syslog configuration cannot stop the NTP process. Mixing these protocols to explain clock drift is a category error.

Trap 2: NTP requires a trunk port on the management VLAN

NTP is an application-layer protocol that rides on IP and UDP port 123; a trunk port is an Ethernet feature for multiplexing multiple VLANs onto a single link. The switch only needs an IP address in any VLAN that provides a route to the NTP server, whether that VLAN is untagged or trunked. If the clock is off, trunking is completely irrelevant to the failure.

Trap 3: The clock can sync only if DNS is configured

A switch can synchronize its clock to an NTP server using the server's numeric IP address, which requires no name resolution. DNS is only a convenience when the configuration references a hostname like 'time.example.com' instead of an IP. If the clock is off, the root cause must be reachability or synchronization of the NTP server, not a missing DNS record.

A
The NTP server is unsynchronized or unreachable
NTP clients trust time only from a server that is both reachable and itself synchronized to a reference clock. When the server is unreachable (e.g., UDP 123 is filtered) or its stratum is too high because it lost its upstream source, the switch discards the NTP packets and retains the local clock, which drifts after several minutes. The remedy is to verify the server's stratum and reachability before adjusting anything else.
B
The device must run Syslog before NTP can sync
Why wrong: Syslog and NTP are entirely separate services: syslog forwards log messages to a collector, while NTP synchronizes wall-clock time. The switch will happily update its clock from an NTP server even if no syslog server is defined, and the absence of syslog configuration cannot stop the NTP process. Mixing these protocols to explain clock drift is a category error.
C
NTP requires a trunk port on the management VLAN
Why wrong: NTP is an application-layer protocol that rides on IP and UDP port 123; a trunk port is an Ethernet feature for multiplexing multiple VLANs onto a single link. The switch only needs an IP address in any VLAN that provides a route to the NTP server, whether that VLAN is untagged or trunked. If the clock is off, trunking is completely irrelevant to the failure.
D
The clock can sync only if DNS is configured
Why wrong: A switch can synchronize its clock to an NTP server using the server's numeric IP address, which requires no name resolution. DNS is only a convenience when the configuration references a hostname like 'time.example.com' instead of an IP. If the clock is off, the root cause must be reachability or synchronization of the NTP server, not a missing DNS record.

Question 10mediummultiple choice

Why is centralized logging especially useful when combined with NTP?

Trap 1: Because NTP assigns the Syslog server its IP address.

This is wrong because NTP does not provide IP addressing.

Trap 2: Because Syslog replaces authentication when NTP is present.

This is wrong because logging and time sync do not replace access control.

Trap 3: Because centralized logging blocks unauthorized traffic…

This is wrong because logging improves visibility, not traffic enforcement.

A
Because synchronized clocks make centralized log timelines easier to analyze accurately.
Synchronised clocks via NTP ensure that log timestamps across all network devices share a common time reference, eliminating drift that would otherwise scatter events from the same incident across different points in a centralised log timeline. This temporal alignment satisfies the constraint of accurate forensic reconstruction, as analysts can correlate events from routers, switches, and servers without manual offset correction.
B
Because NTP assigns the Syslog server its IP address.
Why wrong: This is wrong because NTP does not provide IP addressing.
C
Because Syslog replaces authentication when NTP is present.
Why wrong: This is wrong because logging and time sync do not replace access control.
D
Because centralized logging blocks unauthorized traffic automatically.
Why wrong: This is wrong because logging improves visibility, not traffic enforcement.

Question 11hardScenario

You are connected to R1, a branch router connected to a central NTP server at 203.0.113.10 and a syslog server at 198.51.100.20. Configure R1 as an NTP client using its Loopback0 interface (192.168.1.1/32) as the source, and ensure syslog messages of severity 'informational' and above are sent to the syslog server. Currently, R1 shows 'Clock is unsynchronized, stratum 16'. Identify and fix the NTP issue, then apply the syslog configuration.

Exhibit

R1#show ntp status
Clock is synchronized, stratum 16, reference is 127.127.7.1
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
reference time is D3A4B2C1.00000000 (00:00:00.000 UTC Mon Jan 1 2024)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec
loopfilter state is 'CTRL' (Normal), drift is 0.000000000 s/s
system poll interval is 64, last update was 0 sec ago.

R1#show ntp associations
  address         ref clock     st  when  poll reach  delay  offset   disp
*~127.127.7.1     .LOCL.        16    25    64   377   0.000  0.000   0.000
 * sys_peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

R1#show running-config | include ntp|logging
ntp server 203.0.113.10
logging host 198.51.100.20
logging trap warnings

Trap 1: Configure 'ntp server 203.0.113.10 source Loopback0' and 'logging…

This is incorrect because the 'ntp server' command does not support the 'source' keyword; the source interface is configured globally with 'ntp source'. Also, 'logging trap warnings' sets severity to 4, which filters out informational (severity 6) messages.

Trap 2: Configure 'ntp source Loopback0' and 'logging trap debugging'.

This is incorrect because 'logging trap debugging' sets severity to 7, which includes all messages (0-7). While this would include informational messages, it is overly broad and not the standard recommended level for informational and above; 'informational' (severity 6) is the correct trap level.

Trap 3: Configure 'ntp source Loopback0' and 'logging host 198.51.100.20'…

This is incorrect because while the NTP source is correctly set, the syslog trap level is not changed. By default, the trap level is 'informational' (severity 6) on some IOS versions, but often it is 'warnings' (severity 4) or lower. The question implies the current configuration filters out informational messages, so the trap level must be explicitly set to 'informational'.

A
Configure 'ntp source Loopback0' and 'logging trap informational'.
This is correct because the NTP source interface must be specified to ensure the router uses a consistent, reachable source IP (Loopback0) for NTP packets. Additionally, 'logging trap informational' sets the syslog severity to 6, allowing messages of severity 6 (informational) and above (0-6) to be sent to the syslog server.
B
Configure 'ntp server 203.0.113.10 source Loopback0' and 'logging trap warnings'.
Why wrong: This is incorrect because the 'ntp server' command does not support the 'source' keyword; the source interface is configured globally with 'ntp source'. Also, 'logging trap warnings' sets severity to 4, which filters out informational (severity 6) messages.
C
Configure 'ntp source Loopback0' and 'logging trap debugging'.
Why wrong: This is incorrect because 'logging trap debugging' sets severity to 7, which includes all messages (0-7). While this would include informational messages, it is overly broad and not the standard recommended level for informational and above; 'informational' (severity 6) is the correct trap level.
D
Configure 'ntp source Loopback0' and 'logging host 198.51.100.20' without changing the trap level.
Why wrong: This is incorrect because while the NTP source is correctly set, the syslog trap level is not changed. By default, the trap level is 'informational' (severity 6) on some IOS versions, but often it is 'warnings' (severity 4) or lower. The question implies the current configuration filters out informational messages, so the trap level must be explicitly set to 'informational'.

Open the full VLAN trunking answer →

Question 12hardScenario

You are connected to R1 via the console. The network operations center (NOC) has asked you to configure R1 as an NTP client of the NTP server at 192.0.2.10 (reachable via VLAN 100, SVI 192.168.1.1/24). They also need all system messages of level 'debug' (level 7) and higher forwarded to the syslog server at 203.0.113.50. The current configuration shows that NTP is not working (stratum 16) and syslog is only sending critical and higher messages. Fix both issues.

Exhibit

R1#show ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 250.00000 Hz, actual freq is 250.00000 Hz, precision is 2**10
reference time is 0.0.0.0 (00:00:00.000 UTC Mon Jan 1 2000)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec
loopfilter state is 'CTRL' (Normal Controlled Loop)

R1#show ntp associations
  address         ref clock     st  when  poll reach  delay  offset   disp
*~0.0.0.0         0.0.0.0       16   -     64    0     0.00   0.00   16000.
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

R1#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    Console logging: level debugging, 0 messages logged
    Monitor logging: level debugging, 0 messages logged
    Buffer logging: level debugging, 0 messages logged
    Trap logging: level critical, 0 messages logged

Logging to: 203.0.113.50 (udp port 514, audit disabled, link up)

R1#show running-config | section ntp
ntp server 192.0.2.10
!

R1#show running-config | section logging
logging host 203.0.113.50
!

Trap 1: Configure 'ntp server 192.0.2.10' and 'logging trap 7'.

This is incorrect because 'ntp server 192.0.2.10' is already configured (implied by the scenario). The issue is the missing source interface, not the server command. 'logging trap 7' is not a valid command; the correct syntax is 'logging trap debugging' or 'logging trap 7' is not standard (though severity 7 is debugging, the keyword is preferred).

Trap 2: Configure 'ntp source Vlan100' and 'logging trap warnings'.

This is incorrect because 'logging trap warnings' sets the syslog trap level to warnings (severity 4), which filters out messages with severity lower than warnings (like notifications, informational, and debug). The NOC requires all messages up to debug level, so the trap level must be set to debugging.

Trap 3: Configure 'ntp update-calendar' and 'logging trap informational'.

This is incorrect because 'ntp update-calendar' updates the hardware calendar from NTP, but does not fix the source interface issue. 'logging trap informational' sets the trap level to informational (severity 6), which still excludes debug messages (severity 7).

A
Configure 'ntp source Vlan100' and 'logging trap debugging'.
This is correct because 'ntp source Vlan100' ensures NTP packets are sourced from the VLAN 100 interface IP (192.168.1.1), which is reachable to the NTP server. 'logging trap debugging' sets the syslog trap level to debugging (severity 7), allowing all messages from debug and higher to be sent to the syslog server.
B
Configure 'ntp server 192.0.2.10' and 'logging trap 7'.
Why wrong: This is incorrect because 'ntp server 192.0.2.10' is already configured (implied by the scenario). The issue is the missing source interface, not the server command. 'logging trap 7' is not a valid command; the correct syntax is 'logging trap debugging' or 'logging trap 7' is not standard (though severity 7 is debugging, the keyword is preferred).
C
Configure 'ntp source Vlan100' and 'logging trap warnings'.
Why wrong: This is incorrect because 'logging trap warnings' sets the syslog trap level to warnings (severity 4), which filters out messages with severity lower than warnings (like notifications, informational, and debug). The NOC requires all messages up to debug level, so the trap level must be set to debugging.
D
Configure 'ntp update-calendar' and 'logging trap informational'.
Why wrong: This is incorrect because 'ntp update-calendar' updates the hardware calendar from NTP, but does not fix the source interface issue. 'logging trap informational' sets the trap level to informational (severity 6), which still excludes debug messages (severity 7).

Review the full routing breakdown →

Question 13easymulti select

A company wants all routers and switches to use a common time source so log timestamps line up during incident review. Which two statements about NTP are correct?

Trap 1: It advertises Layer 3 reachability between routers

NTP is transported over IP, but it does not exchange routing information or build neighbor adjacency for Layer 3 reachability. Routing protocols — such as OSPF, EIGRP, and BGP — are responsible for discovering paths and populating the routing table, while NTP merely carries time-sync packets. Therefore, NTP cannot serve as a substitute for a routing protocol.

Trap 2: It encrypts data traffic between endpoints by default

NTP is strictly a time synchronization protocol, so it does not encrypt or protect data-plane traffic by default. Its messages carry time information, not user payloads, and any confidentiality on the wire is an optional enhancement such as NTP authentication, which only verifies packet integrity, not encrypt traffic. Encryption of endpoints is handled by separate protocols like IPsec, TLS, or SSH, not by NTP itself.

A
It helps synchronize device clocks
NTP uses a hierarchical stratum model to distribute UTC time from authoritative sources down to client routers and switches, typically over UDP port 123. Each device adjusts its local clock gradually to eliminate drift and jitter, converging on a mutually consistent time reference. This is the core synchronization mechanism that makes a common time base possible across all networking devices.
B
Consistent time improves correlation of syslog and other event data
When syslog entries, interface counters, RADIUS/TACACS+ records, and access logs carry trustworthy, synchronized timestamps, administrators can sequence security-related and operational events across multiple devices. If each device ticks to a different clock, a single incident can appear as unrelated entries, and reconstructing the exact order of a DDoS attack or unauthorized access becomes nearly impossible. A common time base enables correlated analysis and accurate forensic timelines.
C
It advertises Layer 3 reachability between routers
Why wrong: NTP is transported over IP, but it does not exchange routing information or build neighbor adjacency for Layer 3 reachability. Routing protocols — such as OSPF, EIGRP, and BGP — are responsible for discovering paths and populating the routing table, while NTP merely carries time-sync packets. Therefore, NTP cannot serve as a substitute for a routing protocol.
D
It encrypts data traffic between endpoints by default
Why wrong: NTP is strictly a time synchronization protocol, so it does not encrypt or protect data-plane traffic by default. Its messages carry time information, not user payloads, and any confidentiality on the wire is an optional enhancement such as NTP authentication, which only verifies packet integrity, not encrypt traffic. Encryption of endpoints is handled by separate protocols like IPsec, TLS, or SSH, not by NTP itself.

Review the full routing breakdown →

Question 14mediummultiple choice

Exhibit: A branch router receives time from an NTP server, but the show output marks the server with a tilde instead of an asterisk. What does that mean?

Exhibit

R1# show ntp associations
  address         ref clock     st   when   poll reach  delay  offset   disp
~192.0.2.50      203.0.113.1    3     12     64   377   22.1    0.8    1.2
*198.51.100.20   .GPS.          1     14     64   377   18.3    0.4    0.9

Trap 1: That server is the current system clock source

The asterisk (*) next to an NTP association in the 'show ntp status' or 'show ntp associations' output indicates the currently selected and synchronized source. If a server is merely reachable but not marked with an asterisk, it is not the system clock source. The system clock is synchronized to the source with the best reference stratum and distance; reachability alone does not make it the clock source.

Trap 2: NTP authentication has disabled the server permanently

NTP authentication failure is indicated by an 'A' flag or specific authentication errors in NTP association output, not by the absence of the selected-source symbol. A reachable but unselected server can still pass authentication; the symbol simply reflects synchronization selection state. Permanent disablement is not a concept in NTP association symbols; authentication is either configured correctly or not.

Trap 3: The router is acting as an NTP master for that server

When a router is configured as an NTP master, it uses its own clock as the reference and does not rely on an external server for synchronization. The association symbol indicates the role of the router as a client or peer relative to the remote server. If the router were acting as a master, it would provide time to other clients, not receive time from this server, and the association would show the server as a client, not as a potential synchronization source.

A
That server is the current system clock source
Why wrong: The asterisk (*) next to an NTP association in the 'show ntp status' or 'show ntp associations' output indicates the currently selected and synchronized source. If a server is merely reachable but not marked with an asterisk, it is not the system clock source. The system clock is synchronized to the source with the best reference stratum and distance; reachability alone does not make it the clock source.
B
The server is reachable but not the one currently selected for synchronization
In Cisco IOS, 'show ntp associations' displays remote servers with symbols like '.' (rejected), 'o' (selected), '*' (system peer). If a server is reachable but not selected, it will appear without the asterisk, meaning the router can communicate with it and receive NTP packets, but it has not been chosen as the synchronization source due to stratum, offset, or reachability comparisons among multiple sources. This is a normal condition when the router has multiple NTP servers configured.
C
NTP authentication has disabled the server permanently
Why wrong: NTP authentication failure is indicated by an 'A' flag or specific authentication errors in NTP association output, not by the absence of the selected-source symbol. A reachable but unselected server can still pass authentication; the symbol simply reflects synchronization selection state. Permanent disablement is not a concept in NTP association symbols; authentication is either configured correctly or not.
D
The router is acting as an NTP master for that server
Why wrong: When a router is configured as an NTP master, it uses its own clock as the reference and does not rely on an external server for synchronization. The association symbol indicates the role of the router as a client or peer relative to the remote server. If the router were acting as a master, it would provide time to other clients, not receive time from this server, and the association would show the server as a client, not as a potential synchronization source.