Practice Test #5

192.168.101.10 is not selected because its AS-path is longer than the path through 192.168.101.18. The path attribute shown is `64515 64515i`, which indicates AS 64515 has been prepended, giving it an AS-path length of 2. After the failed best path is removed, BGP compares the remaining eBGP candidates and prefers the shorter AS-path. Therefore, 192.168.101.18 is preferred over 192.168.101.10.

192.168.101.14 is not selected because it is an iBGP-learned route, indicated by the presence of a Local Preference value in the table. Although Local Preference is an important BGP attribute within an AS, Cisco best-path selection still prefers an eBGP path over an iBGP path when earlier comparisons among the remaining candidates do not make the iBGP route uniquely best in this context. The remaining eBGP routes are therefore preferred before this iBGP route. As a result, 192.168.101.14 does not become the active next hop.

192.168.101.6 is not selected because its AS-path is longer than the path through 192.168.101.18. The path shown is `64514 64514i`, which is an AS-path length of 2 because of prepending. While it also shows a MED of 80, MED is considered later and does not help it beat a shorter eBGP AS-path. Therefore, 192.168.101.18 remains the best remaining route.

Incorrect. A true one-to-one NAT translation in the exam sense usually implies a fixed, permanent mapping (static NAT), configured with "ip nat inside source static". This configuration is dynamic NAT using a pool; mappings are allocated as needed and can change over time. While each active inside host may temporarily get one global address, it is not a guaranteed permanent one-to-one mapping.

Incorrect. The 209.165.201.0/27 network in the pool represents inside global addresses (public addresses used to represent inside hosts). “Outside local” refers to how an outside host’s address is represented inside the network (often only relevant with overlapping addressing or special NAT cases). Nothing here defines outside local addresses or an outside address range.

Incorrect. 10.1.1.0/27 is not the inside global range; it is the inside local range (private addresses). The inside global range is the public address space used to represent inside hosts externally, which in this configuration is the NAT pool 209.165.201.1–209.165.201.30 (within 209.165.201.0/27).

Incorrect. The RIB does not maintain a mirror image of the FIB. The RIB can contain multiple routes to the same prefix from different sources (or multiple BGP paths), including routes that are not currently used for forwarding. The FIB is typically a subset containing the best/installed routes used for actual packet forwarding.

Incorrect. Standard IP routing/CEF forwarding uses destination prefix longest-prefix-match, not source prefix-based switching. While policy-based routing (PBR) can influence forwarding based on source or other fields, that is not the default RIB function. The RIB’s role is route selection and maintaining routing information, not source-prefix switching decisions.

Incorrect. The FIB is not where all IP routing information is stored; that is the role of the RIB. The FIB is an optimized forwarding structure used by the data plane and generally contains only the active/best routes needed to forward packets efficiently. Full routing information and candidate routes remain in the RIB.

Incorrect. JWTs do not have a “version” segment as part of their dot-separated structure. Versioning is handled by standards (RFC) and sometimes by claims or application logic, not by adding a token segment. The three segments are specifically header, payload, and signature for JWS. Introducing “version” is a distractor that sounds plausible but is not part of JWT format.

Incorrect. While header and payload are two of the three JWT segments and are easily decoded, a proper JWT used for trust is typically signed, requiring the third segment: signature. Without the signature, you cannot verify integrity or authenticity, and the token is effectively untrusted. Some systems may use unsecured JWTs, but that is not the standard or best practice.

Incorrect. Payload and signature alone are insufficient because the header is required to indicate how the signature was produced (algorithm, key ID/kid, type). The signature validation process depends on header parameters. Omitting the header breaks the defined JWT/JWS structure and prevents interoperable verification. This option is a common trap for those focusing only on claims and integrity.

Incorrect. If L2 broadcast traffic cannot reach the WLC, that mainly impacts local subnet broadcast-based discovery, not DHCP option 43 (which is delivered via DHCP). Also, a failure of L2 broadcast does not inherently explain why the AP would join a different WLC; it would more likely reduce discovery options and potentially cause join failure unless another method succeeds.

Incorrect. CAPWAP discovery does not require multicast to reach a WLC in typical deployments; multicast is not the primary mechanism for controller discovery across Layer 3. If multicast were blocked, it would not usually cause the AP to join an unexpected controller; it would more likely have no effect or only affect specific discovery modes that are not commonly relied upon.

Incorrect. A software version mismatch can prevent an AP from joining a controller (or trigger an AP image download/upgrade if supported), but it does not explain joining a different WLC than specified by option 43. Version differences influence compatibility and upgrade behavior, not the selection precedence among discovered controllers.

SHA-512 and SHA-384 are SHA-2 family hash functions used for integrity (e.g., HMAC, digital signatures) and are designed to be fast. Fast hashes are poor choices for password storage because attackers can brute-force them extremely quickly with GPUs/ASICs. They do not provide adaptive cost factors or memory hardness, so they do not effectively minimize brute-force impact if credentials are leaked.

MD5 is obsolete and broken for collision resistance and is extremely fast, making it unsuitable for password hashing. Pairing it with SHA-384 does not solve the core issue: both are general-purpose hashes, not adaptive password KDFs. This option may look appealing because it lists “algorithms,” but it does not address brute-force resistance for stored credentials and includes an explicitly insecure legacy hash (MD5).

SHA-1 is deprecated for many security uses due to known collision attacks, and SHA-256/SHA-512 are fast general-purpose hashes. Even though SHA-256 and SHA-512 are strong for integrity, they are not designed to slow password guessing. Without an adaptive work factor and proper salting/KDF construction, using SHA directly for passwords leaves REST API credentials vulnerable to rapid offline brute-force if the password database is compromised.

Stratum 0 represents the authoritative reference clock itself (GPS receiver, atomic clock, radio clock). These devices typically do not act as NTP servers on the network; they provide time to a Stratum 1 NTP server via a hardware interface. Therefore, a “server connected directly to an authoritative time source” is not Stratum 0; it is Stratum 1.

Stratum 14 is a very high stratum level, meaning the device is many hops away from the reference clock (e.g., Stratum 1 -> 2 -> ...). While it may still be synchronized, it is far from the authoritative source and generally less preferred than lower stratum sources. It is not directly connected to an authoritative time source.

Stratum 15 is the highest stratum value typically considered usable for synchronization in NTP (with Stratum 16 meaning unsynchronized). A Stratum 15 server is very far removed from the reference clock and is not directly connected to an authoritative time source. This option can mislead test-takers who think higher numbers imply higher authority.

Incorrect because the configured order is not TACACS+ first. The method list is “local group tacacs+,” so local is attempted before TACACS+. Option A matches what would happen with “aaa authentication login default group tacacs+ local,” not with the given configuration. Also, there is no mention of RADIUS, so only local and TACACS+ are relevant.

Incorrect because RADIUS is not part of the configured method list. The command includes only “local” and “group tacacs+.” Even if RADIUS servers exist on the device, IOS will not use them unless “group radius” (or a named RADIUS server group) is explicitly included in the authentication method list.

Incorrect because it introduces RADIUS and also implies a three-step sequence not present in the configuration. The given method list has only two methods. While it correctly starts with local, it incorrectly adds RADIUS as a third step and misrepresents the actual configured behavior.

Incorrect. Receiving prefixes and placing them into the Adj-RIB-In (RIB-IN) requires the BGP session to be in the Established state, where UPDATE messages are exchanged. In Active, the session is not up, so no BGP UPDATEs are being received and no prefixes can be stored in RIB-IN.

Incorrect. Having active prefixes in the forwarding table (FIB) implies routes have been learned, selected as best paths, installed into the routing table (RIB), and then programmed into the FIB. That only happens after a successful BGP adjacency (Established) and after best-path selection, not while the neighbor is stuck in Active.

Incorrect. Cisco IOS BGP does not use a typical “passive mode” neighbor setting in the same way as protocols like EIGRP or OSPF. While BGP always listens for incoming TCP connections and may initiate them, the Active state specifically indicates repeated attempts to establish the TCP/BGP session, not that the router is configured to be passive.