Practice Test #2

Adding both a spine and a leaf can increase capacity, but it is not the fundamental scaling method when you specifically need more access ports. Spine-and-leaf scales access by adding leaf switches; spines are added when you need more fabric bandwidth/paths. Also, “redundant connections between them” is vague and doesn’t capture the required full-mesh leaf-to-all-spines connectivity rule.

Adding a spine switch can improve overall fabric capacity and increase the number of ECMP paths, but it does not directly add access ports. The “at least 40 GB uplinks” detail is not a defining requirement of spine-and-leaf scalability; link speed is an implementation choice. Scalability is about adding nodes (leaf/spine) with consistent interconnections, not a specific uplink rate.

A single connection to a “core spine switch” contradicts the spine-and-leaf design principle. Spine-and-leaf avoids a single core dependency by having each leaf connect to all spines, providing multiple equal-cost paths and eliminating bottlenecks. Connecting a leaf to only one spine reduces redundancy, limits ECMP, and can create oversubscription and single points of failure.

172.9.0.0/16 is NOT a private RFC 1918 network. The private 172 range is 172.16.0.0/12, which covers only 172.16.0.0 through 172.31.255.255. Since 172.9.x.x is outside that boundary, it is publicly routable in principle (assuming it is allocated/used publicly) and is not intended for internal-only addressing without Internet routing.

192.0.0.0/8 is not an RFC 1918 private range. The private range in the 192 space is specifically 192.168.0.0/16. The 192.0.0.0/8 block includes various special-use and publicly routable ranges (for example, 192.0.2.0/24 is TEST-NET-1 for documentation), but it is not the standard private addressing block used for internal networks.

209.165.201.0/24 is a public IPv4 network (not RFC 1918). In many Cisco CCNA labs and examples, 209.165.200.0/24 or similar ranges are used to represent an ISP/public Internet segment. Devices can certainly communicate within this subnet, but it is not an internal-only private range; it is intended to be globally routable rather than isolated from the Internet.

Bridge mode refers to an AP operating as a wireless bridge (for example, connecting two wired networks over a wireless link, or certain mesh/bridging scenarios). While some bridge/mesh deployments can be controller-based, “bridge” is not the defining mode for WLC management. The question is asking for the AP mode that is specifically intended to be managed by a WLC, which is lightweight.

Mobility Express is a solution where one AP runs an embedded wireless controller function and manages other APs. It can look like “controller-managed,” but it is not the classic model of APs being managed by a dedicated Cisco WLC appliance/VM. On CCNA-style questions, “managed by Cisco WLC” typically maps to lightweight mode, not Mobility Express.

Autonomous mode means the AP operates independently without a WLC. Configuration and control functions reside on the AP itself (often configured via CLI/GUI per device). Autonomous APs can provide WLAN services, but they are not managed by a Cisco Wireless LAN Controller, which is exactly what the question is asking about.

Incorrect. In HSRP, the routers do not “share the same interface IP address.” Each router keeps its own unique physical interface IP, and the group shares a separate virtual IP. Also, HSRP does not automatically load-balance default gateway traffic for a single VIP; it is active/standby per group. Load sharing requires multiple groups, not one shared interface IP.

Incorrect. HSRP does not synchronize router configurations. It only provides first-hop redundancy by coordinating which router owns the virtual IP/MAC and should forward packets. Configuration consistency (routing, ACLs, NAT, etc.) must be managed separately (templates, automation, change control). Assuming config sync is a common misunderstanding when learning FHRPs.

Incorrect. While each router does have a different physical IP address, HSRP does not have both routers simultaneously act as the default gateway for the same virtual IP, nor does it inherently load-balance traffic for that gateway. Only the Active router forwards for the VIP in a given HSRP group. Load balancing is more associated with GLBP or with multiple HSRP groups.

"enable secret" sets the password required to enter privileged EXEC mode and stores it using a one-way hash (Type 5/8/9 depending on IOS/platform). It is a best practice over "enable password" for securing enable access. However, it does not globally encrypt other passwords (like console/VTY line passwords) in the configuration, so it does not meet the question’s requirement.

"enable password" sets the privileged EXEC password but stores it in cleartext by default in the configuration. If "service password-encryption" is enabled, it may be obfuscated (Type 7), but by itself it does not prevent plain-text storage. It is also not recommended because "enable secret" provides stronger protection for privileged access.

"username cisco password encrypt" is not the standard IOS syntax for encrypting a local username password. Typically you use "username <name> secret <password>" (preferred, hashed) or "username <name> password <password>" (plaintext unless service password-encryption is enabled). Because the command shown is not correct/standard and does not provide the global behavior asked, it is not the right answer.

Incorrect. DAI does not keep an access port administratively down until it connects to another switch. Administrative down is controlled by the "shutdown" command. DAI is a control-plane/data-plane inspection feature that can drop ARP packets, but it does not require the port to be an uplink nor does it change the admin state based on what is connected.

Incorrect. Dynamic ARP Inspection is not disabled just because an ARP ACL is missing. DAI can validate ARP packets using the DHCP snooping binding table (most common) and/or ARP ACLs. If neither a binding nor an ACL entry exists for a sender, ARP packets may be dropped, but the feature itself remains enabled for the VLAN.

Incorrect. The port does not remain down waiting for a trust/untrust configuration. Untrusted is the default state, so no additional configuration is required for the port to come up. DAI may drop ARP packets that fail validation, but it does not keep the interface link down or require explicit trust/untrust commands to enable the port.

SGML (Standard Generalized Markup Language) is an older markup standard and the conceptual ancestor of HTML and XML. While it influenced modern markup languages, it is not used as a typical REST API payload format. REST APIs overwhelmingly use JSON and/or XML with well-known HTTP media types, not SGML.

YAML is a human-friendly data serialization format commonly used for configuration and automation (for example, Ansible playbooks). Although some niche APIs may support YAML, it is not considered a standard or commonly supported REST API encoding method for CCNA exam purposes compared to JSON and XML.

EBCDIC is a character encoding used primarily on IBM mainframe systems. It describes how characters are represented as bytes, not how structured data is modeled like JSON or XML. REST APIs may use character encodings (most commonly UTF-8), but EBCDIC is not an API payload encoding method in the sense tested here.

A certificate expiring can generate syslog messages, but it is not the typical, canonical event associated with severity level 5 in Cisco IOS exam contexts. Certificate-related logs often appear as warnings (level 4) or errors (level 3) depending on the feature (PKI, HTTPS, VPN) and timing. CCNA questions usually map notice/notifications to interface or protocol state changes.

TCP connection teardown messages can be logged, but they are not the most common CCNA association with a notice-level (5) syslog event. TCP session establishment/teardown logging is more typical in firewall contexts (e.g., ASA) or with specific debugging/feature logs, and the severity can vary. The exam’s best match for level 5 is interface status change.

ICMP does not build or tear down connections because it is a connectionless protocol used for control/diagnostic messages (e.g., echo request/reply). Therefore, “an ICMP connection has been built” is conceptually incorrect. Even if ICMP-related events are logged, they would not be described as a connection being built, making this option invalid.

Incorrect. TACACS+ is the protocol commonly associated with command accounting (logging commands executed on a network device) and can provide very granular accounting records. RADIUS accounting typically tracks session start/stop and interim updates for network access sessions, not per-command CLI logging. The option reverses the typical strengths of the protocols.

Incorrect. This is reversed. TACACS+ encrypts most of the payload (everything except the header), providing better confidentiality for AAA exchanges. RADIUS encrypts only the user password in the Access-Request; other attributes are not fully encrypted, though integrity protections exist via authenticators and shared secrets.

Incorrect/misleading. RADIUS is not limited to dial authentication; it is widely used for many access types (802.1X for Wi-Fi/wired, VPN remote access, NAC). TACACS+ can be used for authentication too, but it is most appropriate for network device administration. The statement implies RADIUS is narrow-use, which is not true.