Cisco 200-301 Practice Test 55
Question 540
A learned routing table line has a timer of 00:04:16 next to its next-hop IP. What is that displayed field?
- The wireless channel width in megahertz
- The age since the route information was last updated
- The total number of packet drops on the interface
- The subnet mask in hexadecimal notation
Explanation
Correct Answer
B:An elapsed field such as 00:04:16 beside a learned route indicates its displayed age, typically the time since the routing information was last updated or installed according to the route source and IOS output format. It is useful for diagnosing recent convergence or whether an advertisement has been refreshed. It does not measure packet latency, interface errors or an OSPF cost. The exact timer semantics depend on the route protocol and display, so confirm with the relevant routing diagnostic if investigating a stale path.
Incorrect Answers
A:Wireless channel widths are expressed in megahertz and configured in radio settings, not shown as an elapsed hh:mm:ss value beside an IP route next hop. A route display contains path and update diagnostics rather than 802.11 RF channel data. The presence of a routed next-hop address makes the routing interpretation especially relevant.
C:Packet-drop counters represent failures to forward or accept packets and are usually displayed under interface statistics or traffic policy commands. A route's elapsed age has units of time, not a packet total. Interpreting 00:04:16 as a drop count would mix routing control-plane history with forwarding data-plane statistics and lead to incorrect troubleshooting.
D:An IPv4 subnet mask appears as a dotted-decimal mask or CIDR prefix length such as /24 in configuration and routing output. The displayed 00:04:16 is a clock-like elapsed interval, not hexadecimal notation for a mask. A valid subnet mask is based on contiguous prefix bits, which this timer field does not encode.
Question 541
An access switch receives tagged VLAN 33 traffic from its distribution switch on a link set to switchport mode access. What configuration mismatch is most likely?
- The core router must have a public IP address
- The link should use only a console cable for tagged frames
- The user's DNS resolver must match the distribution router ID
- The interswitch link should be configured as a compatible 802.1Q trunk
Explanation
Correct Answer
D:An access port normally belongs to one data VLAN and is not the suitable endpoint for a distribution-switch trunk sending tagged VLAN 33 traffic. Configure compatible 802.1Q trunking on both ends, allow VLAN 33, and ensure that VLAN exists and is active on the participating switches. Verify the operational state with show interfaces trunk; configured mode alone does not prove forwarding if the link or VLAN is inactive.
Incorrect Answers
A:A public address on a core router is unnecessary for forwarding tagged VLAN 33 frames between campus switches. The failure arises because the receiving port has been constrained to an access VLAN, while the peer is transmitting a frame containing an 802.1Q tag. An IP addressing change could affect routed reachability later but cannot turn this access connection into a functioning trunk.
B:A console lead carries out-of-band management traffic and is not an Ethernet data link for client VLANs. Connecting switches through console ports would prevent ordinary frame forwarding rather than correct the tagged-traffic mismatch. The interswitch uplink must use compatible Ethernet ports with matching trunk mode, encapsulation support and permitted VLAN settings.
C:DNS resolves hostnames and does not set the Layer 2 operating mode of a Catalyst switchport. The distribution router's OSPF ID likewise has no direct role in accepting an 802.1Q tag on an access interface. Even perfectly functioning name resolution would leave the tagged VLAN 33 frames arriving on a port configured for untagged access traffic.
Question 542
An IPv6 router has routes 2001:db8:ab::/48 via R1, 2001:db8:ac::/48 via R2, 2001:db8::/32 via R3, and ::/0 via R4. Where does it send a packet for 2001:db8:ad:10::5?
- Via R1 because any
2001:db8 /48 can match an address beginning with 2001:db8 - Via R3 because the /32 matches while the ab and ac /48 routes do not
- Via R2 because the destination ad hextet is alphabetically after ac
- Via R4 because IPv6 always prefers default routes to longer prefixes
Explanation
Correct Answer
B:The packet's destination third hextet is ad, so it matches neither the ab nor the ac /48 routes. It does match the broader 2001:db8::/32 prefix via R3, which is longer than the default /0. Therefore R3 is the best installed matching destination route under ordinary longest-prefix forwarding. Validate the next hop's actual reachability separately; prefix matching identifies the selected route, not guaranteed delivery.
Incorrect Answers
A:The /48 via R1 requires the third hextet to be ab, but the destination uses ad. Sharing the first two hextets 2001:db8 is insufficient for a /48 match. The routing lookup ignores inapplicable more-specific entries instead of choosing them merely because their first textual characters look similar.
C:The router does not choose next hops by alphabetic ordering of hexadecimal hextets. An IPv6 prefix is a binary bit match, and ac differs from destination hextet ad within the first 48 bits. R2's /48 does not cover the packet, even though the two strings differ by a small numeric amount.
D:The default /0 route is the least-specific fallback for destinations not matched by any longer installed prefix. Here 2001:db8::/32 is a valid matching route, so the default via R4 should not be chosen. IPv6 and IPv4 both follow longest-prefix matching for ordinary destination routing, subject to additional configured policy.
Question 543
A patch panel carries a short 1000BASE-T desktop link. Which physical requirement matters for standard copper Ethernet operation?
- Exactly one optical strand and an LC receive port are required
- The cable must be placed inside the switch routing table
- A satellite uplink must terminate at the workstation
- All required twisted pairs must be correctly terminated within the supported channel length
Explanation
Correct Answer
D:1000BASE-T uses all four balanced twisted pairs to achieve gigabit signaling, so pair continuity, correct termination, cable category and supported channel length matter. A poorly wired or damaged pair can cause negotiation failure, intermittent errors or a fallback to a lower speed. Test the full structured cable path, inspect patch connectors and check both link partners' negotiated speed and duplex rather than assuming an IP configuration issue.
Incorrect Answers
A:An LC connector and an optical strand are components of fiber Ethernet, not ordinary 1000BASE-T twisted-pair copper. The scenario explicitly describes a copper patch-panel path for a desktop, so fiber connector polarity is not the immediate requirement. The relevant check is whether all four copper pairs are properly terminated at the right category and length for the negotiated gigabit link.
B:The routing table contains IP destination prefixes and next-hop selections, not physical cable pairs that can be validated by adding a route. Even correct inter-subnet routing cannot compensate for a broken conductor or wrongly terminated copper pair that prevents a valid Ethernet physical link. Investigate cable mapping, pair continuity and negotiated speed at Layer 1 before adjusting routes.
C:Satellite transport might be an optional wide-area uplink for a remote site, but it has no role in a short local 1000BASE-T patch-panel run. The workstation communicates to the nearby access switch over copper Ethernet and needs the cabling to meet the relevant physical standards. A satellite termination cannot repair a pair split or an overlength horizontal channel.
Question 544
A company rolls out certificate-based administrator login and validates certificate chains. Which property helps resist credential impersonation?
- Using an unverified self-signed certificate from any unknown server
- Substituting the switch VLAN number as the certificate signature
- Disabling private-key protection because public keys are published
- Cryptographic proof of key possession bound to trusted certificate identity
Explanation
Correct Answer
D:Certificate-based authentication relies on a validated trust path and a cryptographic demonstration that the claimant possesses the private key corresponding to the certified public key. This binds an asserted administrator identity to a key that an attacker should not be able to reproduce. Check identity constraints, certificate validity and revocation, and protect the private key with suitable storage and access controls. A signed certificate by itself is not proof that the current claimant owns the secret key.
Incorrect Answers
A:Accepting arbitrary unverified self-signed certificates defeats the identity-validation purpose of certificate authentication. An attacker could substitute a new key and certificate and be accepted merely because a certificate exists. The client or administrator should verify an appropriate trust chain, intended identity and revocation status under organizational policy before trusting the authentication peer.
B:A VLAN number classifies Ethernet broadcast-domain membership and is not a cryptographic signature or proof of administrator identity. Network separation can be a useful supporting control, but a VLAN ID can neither validate the certificate's issuer nor demonstrate that the claimant owns its corresponding private key. The stated defense operates in an authenticated cryptographic exchange.
C:Publishing a public key is normal in public-key cryptography, but the associated private key must remain secret and protected. Disabling private-key protection makes impersonation more likely, because anyone who obtains the key may authenticate as that identity. Certificate-chain validation alone does not compensate for a stolen administrator key or poor credential storage.
Question 545
An organization detects manual configuration drift from an approved switch baseline. What should its automation system do?
- Compare observed configuration with source-controlled desired state and report or remediate differences
- Change every port to VLAN 1 whenever anything differs
- Treat every observed change as automatically approved for future use
- Delete all startup-config backups before comparison
Explanation
Correct Answer
A:Configuration-drift detection compares each switch's observed operational or running configuration against an approved, version-controlled desired state. Differences can be reported for investigation or corrected through a controlled automation workflow after an authorization check. This produces traceable evidence of intended versus actual settings and helps identify unauthorized or accidental changes. Avoid blindly overwriting emergency changes; assess exceptions and schedule remediation to reduce operational risk.
Incorrect Answers
B:Forcing every interface to VLAN 1 is not drift remediation; it imposes one potentially unsafe configuration regardless of the authorized per-port design. It can merge protected user segments and break voice, management or trunk traffic. A controller needs the source-of-truth configuration for each role and location, not an arbitrary default VLAN applied whenever a comparison fails.
C:Treating every newly observed configuration value as approved would erase the distinction between authorized change and accidental drift. An attacker or mistaken operator could change an ACL and have that change silently accepted as the new baseline. Desired state should originate in an approved repository or policy process and require review before changes are incorporated.
D:Deleting startup-config backups would remove useful recovery evidence and would not reveal what differs from the approved running configuration. A drift investigation needs both current observed settings and the authorized baseline. Version history, configuration archives and controlled rollback are valuable if a bad automation change propagates to many devices.
Question 546
A DHCP client on VLAN 77 sends DHCPDISCOVER but the router's relay target is an unreachable old server. Which fix restores lease service?
- Force a different OSPF router ID as the DHCP pool name
- Correct the relay helper to a reachable authorized DHCP server
- Change the WLAN encryption protocol for every wired desktop
- Disable ARP on the gateway so no client can resolve it
Explanation
Correct Answer
B:A DHCPDISCOVER from VLAN 77 ordinarily reaches a relay on the client gateway, which forwards it toward a configured DHCP server using ip helper-address. If the helper points to an unreachable old server, no valid OFFER reaches the client. Update the helper to an authorized reachable server that has the proper scope, then verify relay routing, DHCP service, firewall rules and returned lease options. The replacement must not direct clients to an arbitrary or untrusted server.
Incorrect Answers
A:An OSPF router ID identifies the routing process for adjacency and database operations; it is not the configured DHCP pool name or relay server address. Altering that identifier risks resetting OSPF neighbor sessions without restoring lease exchanges. The observed failure specifically names an obsolete relay target, so the engineer should follow the DHCP client broadcast and relay path rather than changing a routing identity.
C:WLAN encryption affects wireless association and protected radio traffic. The question concerns a wired VLAN client's DHCP message reaching a router configured with an obsolete server destination. Changing every WLAN policy would not create a reachable DHCP relay endpoint and could unnecessarily disconnect unrelated wireless clients. Troubleshoot the helper and server reachability instead of modifying an independent access layer.
D:ARP allows IPv4 neighbors to discover local link-layer addresses, including the default gateway, and is normally needed by DHCP clients after they have addresses. Disabling it on the gateway would create additional connectivity failures rather than repair a failed DHCP relay. The relay needs a working server path; suppressing local neighbor discovery cannot manufacture a server response.
Question 547
A router's static next-hop IP is not directly connected, but another valid route resolves its path. What mechanism is involved?
- Automatic replacement of the next hop with the management VLAN ID
- Recursive lookup of the static next-hop address
- DNS reverse lookup of the destination prefix before every packet
- Conversion of the IPv4 next hop to an STP bridge priority
Explanation
Correct Answer
B:Recursive next-hop resolution occurs when a static route points to an IP address not directly connected to the router. The router looks up that next-hop address in its own routing information to determine a reachable egress interface and immediate neighbor. This is valid only while the recursion resolves to a usable path without loops or invalid recursion. Examine the resolved adjacency and underlying route if traffic fails even though the static statement remains configured.
Incorrect Answers
A:A management VLAN ID designates Layer 2 membership and does not substitute for an IP next-hop address in a static route. A router can have a next-hop outside its directly connected networks and still use it if another installed route resolves the forwarding path. Rewriting the next hop as a VLAN number would remove the intended IP-routing semantics.
C:DNS reverse lookup maps an IP address to a hostname when a matching record exists; it is not part of ordinary per-packet routing recursion. Cisco forwarding devices select destinations using installed prefix matches and resolved next hops, not by querying PTR records before forwarding each packet. A DNS failure should not prevent route selection for a properly resolved static next hop.
D:Spanning tree bridge priority is a Layer 2 loop-prevention attribute. It cannot represent an IPv4 next hop or explain which routed interface will deliver packets toward an indirectly reachable neighbor. Both routing recursion and STP can influence the overall network, but their address structures and forwarding functions are different.
Question 548
A link is swapped from one switch port to another, but the inventory system still shows the old LLDP neighbor record. Which approach verifies the new physical attachment?
- Inspect fresh LLDP neighbor details and confirm the local and remote port identifiers
- Compare the VLAN number to an NTP stratum field
- Force the same MAC address on both switch uplinks
- Inspect only the last successful DNS lookup timestamp
Explanation
Correct Answer
A:LLDP advertisements include chassis and port identifiers, enabling a technician to correlate a discovered neighbor with the local receiving interface. After recabling, collect a fresh neighbor-detail view on both switches and compare the advertised remote port to the expected new attachment. Be aware that stale entries may remain until their hold-time expires, so clear or wait for aging where necessary and check interface link status. LLDP identifies adjacent devices but does not independently prove application-level reachability.
Incorrect Answers
B:VLAN IDs describe local switching segments, whereas NTP stratum describes a time source's distance from its reference clock. Neither field identifies which physical port received a specific LLDP advertisement. Comparing those unrelated numbers cannot confirm that a moved cable terminates at the intended switch interface.
C:Assigning identical MAC addresses to different uplinks risks ambiguous Ethernet learning and does not validate the actual physical neighbors. LLDP advertises its own chassis and port identifiers so cabling can be checked without spoofing a common source identity. A duplicate MAC might cause forwarding instability and obscure rather than resolve the inventory discrepancy.
D:DNS lookup timestamps show when a name was resolved, not which Ethernet connector or remote switch port is attached to the local interface. A previously cached hostname can remain accurate while a cable is moved. Physical topology verification requires current neighbor data and switch interface observations, not resolver cache history.
Question 549
An optical switch reports a large rise in FCS errors after a dusty patch-cord change. Which diagnostic best isolates the cause?
- Enable PAT on the egress Internet router
- Reset the management user's failed-login counter
- Change the OSPF hello timer on a routed VLAN
- Clean and inspect the optical connectors and measure optical receive levels
Explanation
Correct Answer
D:Dirty or poorly seated optical connectors can reduce receive power or distort optical signals, leading to physical-layer corruption that appears as increased FCS errors. Inspect and clean the newly changed connectors using proper fiber-safe procedures, verify fiber type and polarity, and measure received optical levels against the optic's supported range. If the errors disappear after cleaning or recabling, that evidence helps isolate the fault. FCS errors alone are not uniquely diagnostic, so correlate them with optical measurements and the recent patch change.
Incorrect Answers
A:Port address translation at the Internet edge modifies IP addresses and transport ports for routed traffic. It cannot clean a dusty optical connector or restore acceptable receive power between two local transceivers. Packet translation is performed above the failing optical physical layer, so changing NAT state would not isolate these FCS errors.
B:A management login lockout counter applies to administrator authentication, not corruption of received Ethernet frames. Resetting it might restore access for an operator but cannot correct an optical signal weakened by dust or an improperly seated patch lead. The temporal link between recabling and FCS errors points toward the new physical connection.
C:An OSPF hello interval controls routing-neighbor communication after the physical interface can carry frames. It does not change fiber attenuation, connector alignment or transceiver receive levels. Modifying timers on a routed VLAN would risk new adjacency faults without testing the likely cause of CRC/FCS errors.
Question 550
An IPsec architecture includes an encrypted ESP tunnel. What security property is provided when ESP encryption is enabled?
- Confidentiality of encapsulated payload data between authenticated tunnel endpoints
- Global advertisement of RFC1918 routes without filtering
- Permanent prevention of every endpoint malware infection
- Automatic correction of invalid source IPv4 subnet masks
Explanation
Correct Answer
A:IPsec ESP encryption provides confidentiality for the packet payload transported between the tunnel's security endpoints. Capturing traffic on the intervening untrusted network should not expose protected application data without the relevant cryptographic keys. Appropriate integrity/authentication options and anti-replay protections can also be part of ESP processing, but encryption alone does not guarantee secure applications or uncompromised endpoints. Validate the negotiated algorithms, key management and traffic selectors in the tunnel configuration.
Incorrect Answers
B:Encryption of a tunnel payload does not cause routers on the public Internet to advertise internal RFC1918 prefixes. Private routing remains governed by tunnel endpoints, route policies and the configured overlay or static paths. ESP protects selected traffic in transit, while route advertisement and filtering are separate network control-plane decisions.
C:An encrypted IPsec link does not prevent malware from infecting a workstation before the data enters the tunnel or after decryption. It protects a network segment against selected in-transit attacks but cannot replace endpoint protection, patching and identity controls. Tunnel confidentiality should not be mistaken for a guarantee about all software running at either endpoint.
D:ESP does not inspect and repair an invalid IPv4 subnet mask on a device, nor does it automatically rewrite a host's addressing plan. Addresses and routes must allow traffic to reach the tunnel endpoint, and policy selectors determine what to encapsulate. Cryptographic protection occurs after traffic has been selected and cannot resolve basic addressing errors.