Cisco Certified Network Associate (CCNA) 200-301 Practice Test 48
Question 470
R1 reports NTP stratum 16 and `show ntp status` says the clock is unsynchronized. The configured NTP server IP is present, but reachability to it is not verified. How should the status be interpreted?
- Stratum 16 confirms the most precise synchronized server in the hierarchy.
- The presence of an `ntp server` line proves that time synchronization has succeeded.
- Changing the router hostname is the required fix for a stratum-16 state.
- Stratum 16 means this router is not synchronized to a valid time source; check peer reachability and NTP association state.
Explanation
Correct Answer
D:An unsynchronized NTP client is not a trustworthy clock source, and Cisco commonly presents stratum 16 for unsynchronized status. Verify actual association, peer reachability and access controls.
Incorrect Answers
A:High stratum does not indicate better precision, and stratum 16 is an unsynchronized condition rather than the best upstream clock.
B:A configuration line expresses an intended peer, not evidence of successful reachability or synchronization.
C:Hostname changes do not establish NTP exchange or cause a router to synchronize to a peer.
Question 471
Several routers were manually set to the correct time yesterday but have drifted apart today. `show ntp status` reports unsynchronized on all of them. What explains this pattern?
- A successful manual adjustment guarantees a synchronized NTP state indefinitely.
- A syslog facility ID mismatch changes the hardware oscillator frequency on each router.
- A one-time manual clock set did not discipline ongoing clock drift; the devices need working NTP associations to maintain a shared timebase.
- A lower NTP stratum number must be the entire fault even if no NTP peers are selected.
Explanation
Correct Answer
C:Independent clock oscillators drift over time; manual correction is transient. NTP synchronization continually estimates offset/delay and adjusts time so distributed device logs can be compared.
Incorrect Answers
A:Manual setting is not NTP association and cannot guarantee future clock agreement.
B:Syslog metadata classification has no effect on device clock synchronization.
D:Stratum indicates hierarchy, not by itself a proof of precision or a substitute for reachable selected peers.
Question 472
R1 can ping its configured NTP server but previously listed no selected synchronized peer. Which IOS output after repair establishes NTP synchronization rather than mere IP reachability?
- The server responds to ICMP echo while `show ntp status` remains unsynchronized.
- Syslog timestamps appear in the correct timezone but NTP peers are not synchronized.
- `show ntp status` reports synchronized and `show ntp associations` identifies a usable selected system peer with valid reachability.
- A static default route exists and no NTP association output is inspected.
Explanation
Correct Answer
C:An ICMP ping verifies IP delivery only. NTP uses time exchanges and association selection; operational status and selected peer information demonstrate that the router is actually disciplining its clock.
Incorrect Answers
A:Generic reachability is insufficient when NTP exchanges, filtering or clock validity still prevent selection.
B:Matching timezone labels do not establish that the time source was selected or clock corrected.
D:Routing permits possible access to a server but cannot prove NTP time synchronization occurred.
Question 473
A Windows workstation starts without an IPv4 lease on a switched VLAN. A packet capture on the client VLAN shows its initial broadcast request, a DHCP server response, the client's selection of the offered address, and the final server acknowledgment. Which packet order represents the standard successful DHCPv4 address-allocation exchange?
- Discover → Offer → Request → ACK
- Discover → ACK → Offer → Request
- Request → Discover → ACK → Offer
- Offer → Discover → ACK → Request
Explanation
Correct Answer
A:The client first broadcasts DHCPDISCOVER to find available servers; a server answers with DHCPOFFER; the client sends DHCPREQUEST to select and request the offered lease; and the server finalizes with DHCPACK, typically including address lifetime and configuration options. The sequence establishes the lease-handshake order, not necessarily that the assigned gateway or DNS settings are correct. If the capture shows no Offer, examine DHCP server reachability and relay; if an Offer arrives but no ACK follows, investigate the client's request and server allocation decision.
Incorrect Answers
B:The ACK is the server's confirmation of a requested lease. It cannot logically precede the Offer and Request in the normal new-client DORA exchange because the client has not yet selected an address and requested it. Some renewal paths differ from first acquisition, but the question describes a workstation with no initial lease performing standard allocation. An immediate ACK after Discover is therefore not the expected exchange. Inspect the order of packet message types rather than treating any four messages as interchangeable.
C:A DHCPREQUEST can occur during lease renewal or after a client has an offer to select, but a first-time client seeking servers normally begins with Discover. This proposed sequence has the client issue a Request before discovery and places the server's Offer last, after an ACK, which reverses the allocation logic. The scenario specifically mentions a new workstation starting without a lease, so renewal-only traffic is not the tested case. The correct packet capture follows the client discovery, server offer, client request, and server acknowledgment order.
D:A DHCP server does not ordinarily originate an Offer to a new, previously unknown client before its discovery step in the classic DORA exchange. The final Request shown here would also occur after the claimed ACK, which is inconsistent with the server acknowledging a selected lease. This is not a question about DHCP relay interfaces or static host configuration; it tests the observed negotiation sequence. The relevant client/server transaction ordering is Discover, Offer, Request, ACK.
Question 474
A dual-stack application needs DNS records for the same host name `app.example.test`. The IPv4 service uses 192.0.2.25 and its IPv6 address is 2001:db8:20::25. Which DNS resource-record mapping correctly gives clients protocol-specific addresses?
- Publish PTR records for both addresses under `app.example.test` and omit forward address records.
- Publish an AAAA record holding 192.0.2.25 and an A record holding 2001:db8:20::25.
- Publish only a CNAME record from `app.example.test` to itself so both addresses can be inferred.
- Publish an A record for 192.0.2.25 and an AAAA record for 2001:db8:20::25.
Explanation
Correct Answer
D:An A record maps a hostname to an IPv4 address, so 192.0.2.25 belongs in the A record for `app.example.test`. An AAAA record carries the IPv6 address, so 2001:db8:20::25 belongs in its AAAA record. Dual-stack clients can request whichever address family they support and choose a suitable endpoint according to client policy. Verify using separate `dig A app.example.test` and `dig AAAA app.example.test` queries, then test connectivity to each returned address. DNS correctness alone does not guarantee firewall or route reachability.
Incorrect Answers
A:PTR records support reverse mapping from an IP address to a name, typically under the relevant reverse lookup namespace. They are not a substitute for forward address records that IPv4 and IPv6 clients query to obtain endpoints. A client asking for the A or AAAA record for `app.example.test` needs a corresponding forward answer. Reverse-name accuracy may help troubleshooting or logging but does not solve the dual-stack application discovery requirement described in the question.
B:The proposal reverses the address families. A record data is an IPv4 address with 32 bits, while AAAA record data is an IPv6 address with 128 bits. An IPv4 dotted-quad value cannot be represented as the expected AAAA resource-record address, and an IPv6 address is not valid A-record data. A dual-stack hostname may publish both records, but each must carry the matching address family. This mistake is not corrected by changing DHCP server options or routing preferences.
C:A CNAME aliases one DNS name to another canonical name; it does not by itself encode IPv4 or IPv6 address values. A self-referential CNAME would create an unusable alias loop rather than allow clients to infer the dual-stack addresses. Even a proper alias requires the target name to resolve through A and/or AAAA records. Here the service owner has concrete IPv4 and IPv6 addresses, so it should publish the corresponding forward address records instead of relying on an alias without address data.
Question 475
The authoritative DNS A record for `app.example.test` was changed from 192.0.2.10 to 192.0.2.20. Some clients still connect to 192.0.2.10; an affected recursive resolver reports an unexpired cached answer. What explains the temporary inconsistency?
- The client's subnet mask has changed the DNS record's IP address from .20 back to .10.
- DHCP renewal forces every resolver on the Internet to adopt the new authoritative DNS answer instantly.
- The recursive resolver is serving its cached old record until its remaining TTL expires or the relevant cache is invalidated.
- An OSPF router ID mismatch changes the authoritative DNS zone contents without a DNS update.
Explanation
Correct Answer
C:DNS caches can reuse a previously obtained resource record for its time-to-live instead of querying the authoritative server for every request. A recursive resolver with a still-valid cached A record may continue returning 192.0.2.10 even after the authoritative zone now contains 192.0.2.20. Compare answers from the authoritative server and affected recursive resolvers, including remaining TTLs; if operationally necessary, invalidate an appropriate cache following policy. For future changes, shorten record TTLs ahead of a planned migration when feasible. This is name-resolution freshness, not proof that routing to either IPv4 address is broken.
Incorrect Answers
A:A subnet mask changes how a host or router interprets local-network membership and route boundaries. It does not rewrite an authoritative DNS A record or change a resolver's cached RDATA to a different IPv4 address. The stated evidence already identifies a still-valid cached DNS answer as the immediate cause.
B:DHCP renewal can update a client's address, gateway and configured DNS servers, depending on options. It does not force external recursive DNS caches to abandon their record TTLs or fetch a new authoritative answer at once. Some client-side caches may also retain records independently of the DHCP lease.
D:OSPF router IDs are identifiers in routing adjacency and link-state processes. A mismatch may affect route learning, but it does not silently edit an authoritative DNS zone or produce a previously cached address. The observed stale DNS response has its own TTL-driven explanation.
Question 476
A PC repeatedly broadcasts DHCPDISCOVER but receives no DHCPOFFER and eventually selects an APIPA 169.254/16 address. What is the immediate DHCP failure evident in the exchange?
- A correct DHCPOFFER reached the client, but DNS A and AAAA records disagreed.
- No usable DHCP server offer reaches the client; investigate server availability, VLAN relay path and blocked DHCP replies.
- A DHCPACK was accepted and the host is using a valid leased site address.
- The IPsec tunnel phase 2 failed after the DHCP client obtained its gateway.
Explanation
Correct Answer
B:Normal DHCP address assignment begins with DISCOVER then OFFER before REQUEST and ACK. Without a received OFFER, the client cannot proceed to obtain the intended lease and may fall back to link-local addressing.
Incorrect Answers
A:No OFFER was observed; DNS answer selection occurs after IP configuration and cannot account for this early DHCP exchange failure.
C:The observed link-local fallback and absence of OFFER contradict a completed lease exchange.
D:The client never obtained a usable site lease, so this is not a later IPsec problem.
Question 477
A dual-stack service has correct A and AAAA DNS records. An application selects the AAAA address, but the client has no usable IPv6 default route; IPv4 connections to its A address work. Which layer is responsible for the failure?
- The A record is invalid because any successful IPv4 connection necessarily requires an AAAA route.
- IPv6 forwarding to the AAAA destination is unavailable; DNS supplied an address, but the chosen address family has no working route.
- The DNS resolver failed to answer because the application received a valid AAAA record.
- A DHCPv4 lease is missing even though the client can establish working IPv4 connections.
Explanation
Correct Answer
B:An AAAA answer supplies an IPv6 destination, not IPv6 transport connectivity. The application needs a valid IPv6 source and path, or it must fall back to a usable IPv4 A destination.
Incorrect Answers
A:IPv4 and IPv6 have separate routing tables; successful IPv4 says nothing about IPv6 default routing.
C:The name was resolved; the failure occurs after address selection at IPv6 routing/connectivity.
D:Working IPv4 connections contradict the proposed lack of IPv4 addressing; the evidence concerns IPv6 path selection.
Question 478
A new hostname `preview.example.test` was created with A address 192.0.2.44 ten minutes after a recursive resolver had received an authoritative NXDOMAIN response for the previously nonexistent name. The authoritative server now answers correctly, but that resolver still returns NXDOMAIN within its negative cache lifetime. Which DNS mechanism explains the difference?
- An NXDOMAIN response is never cacheable, so the recursive resolver must rewrite the authoritative zone itself.
- IPv4 longest-prefix matching converts nonexistent hostnames into NXDOMAIN and changes the DNS zone automatically.
- All recursive resolvers must immediately know about a newly created A record because DNS push-notifies every cache.
- The recursive resolver cached the earlier negative NXDOMAIN answer; it can continue serving that negative response until its permitted negative-cache TTL expires or the entry is flushed.
Explanation
Correct Answer
D:RFC 2308 defines negative caching of name- or type-nonexistence responses. An authoritative DNS update does not automatically invalidate negative responses retained by every recursive resolver. Testing both authoritative and recursive answers, including the remaining negative TTL where observable, separates this from stale positive A-record caching.
Incorrect Answers
A:Negative caching is a defined DNS resolver behavior; the authority and cache can temporarily disagree after a name is created.
B:Route selection moves packets to an IP destination; it does not generate negative cache entries from a new A-record update.
C:DNS typically relies on queries and TTL-controlled caching; an authoritative change does not synchronously flush remote negative caches.
Question 479
After restoring DHCP service for a client that formerly fell back to 169.254/16, which host-side check best verifies a complete usable IPv4 lease?
- The PC still has only 169.254/16 and no default gateway, but its network link icon is lit.
- The client receives a site-subnet address and expected mask, gateway and DNS options in a completed DHCP exchange and can reach the gateway.
- An unrelated DNS A-record query succeeds from another server.
- Only a DHCPOFFER is seen, with no selected lease or DHCPACK.
Explanation
Correct Answer
B:Successful DORA exchange provides a lease, but the options must also match the client VLAN. Seeing a valid address, gateway and DNS configuration confirms more than simply observing any DHCP server packet.
Incorrect Answers
A:Physical association can work while DHCP has failed and the client stays link-local.
C:DNS resolution elsewhere cannot prove that this client received its DHCP lease and options.
D:An offer alone does not establish that the client committed the lease and received final configuration.
Question 480
A workstation chooses a valid AAAA answer but its IPv6 connection fails while IPv4 to the same service succeeds. After restoring the IPv6 route, which combined test most directly validates the original dual-stack failure is gone?
- Test only the IPv4 A destination and ignore the AAAA result.
- Query A and AAAA records, inspect an installed IPv6 route and source address, and establish a permitted connection to the returned IPv6 destination.
- Check that the DNS recursive cache has a low TTL, without transmitting IPv6 traffic.
- Assume a valid-looking AAAA record proves the client has an IPv6 default route.
Explanation
Correct Answer
B:Name resolution and forwarding are separate. A valid AAAA result confirms the requested address; a successful IPv6 path/connection confirms that address is actually usable, while IPv4-only success would miss the prior fault.
Incorrect Answers
A:IPv4 success was present before the repair and cannot validate the missing IPv6 route.
C:TTL says how long an address is cached, not whether the IPv6 data path works.
D:DNS servers do not inspect the client routing table when returning an address record.