Practice Test #1

QoS settings are commonly configured per WLAN (e.g., Platinum/Gold/Silver/Bronze on AireOS, or QoS profiles/policy on Catalyst 9800), but they are not mandatory fields to create a new WLAN object in the WLC GUI. QoS is typically adjusted after the WLAN is created, based on application requirements like voice, video, or best-effort data.

You do not enter the IP address of one or more access points when creating a WLAN. APs discover and join the controller using CAPWAP and are managed separately from WLAN definitions. Once APs are joined, WLANs are advertised based on controller configuration (and possibly AP groups/policy tags), not by manually listing AP IPs during WLAN creation.

Management interface settings are part of controller system configuration (management IP, default gateway, DHCP server settings, etc.), not a required input when creating a new WLAN. A WLAN is typically mapped to a dynamic interface/VLAN (or policy profile) for client traffic, but the controller’s management interface settings are not entered as part of the WLAN creation step.

Incorrect. An access port results when trunk negotiation does not succeed (for example, dynamic auto to dynamic auto, or when one side is forced to access). In this scenario, SW2 is dynamic desirable and actively requests trunking, and SW1 (dynamic auto) will accept that request, so the port does not remain access.

Incorrect. DTP mismatches do not normally place a port into err-disabled. Error-disable is triggered by specific protection mechanisms (for example BPDU Guard, Port Security violations, UDLD, or link-flap detection). With auto/desirable, DTP negotiation succeeds and the interface transitions normally, so err-disable is not expected.

Incorrect. The physical link state (up/down) depends on Layer 1/2 connectivity (cabling, speed/duplex negotiation, admin shutdown, etc.), not on whether DTP negotiates trunking. With dynamic auto and dynamic desirable, the link can come up and then negotiate trunking; it should not be down due to these DTP settings.

Incorrect. Traditional campus management is usually slower to scale because it often relies on per-device CLI configuration and manual change processes. Scaling requires repeating tasks across many devices, increasing time and risk of inconsistent configurations. DNAC is designed specifically to improve scalability through centralized automation, templates, and policy-driven provisioning.

Incorrect. DNAC may reduce operational effort over time, but it is not generally positioned as a lower-cost implementation compared to “most” traditional options, especially considering licensing and appliance/virtual infrastructure. Exam questions typically treat DNAC’s primary benefits as automation, consistency, visibility, and faster deployment—not guaranteed lower cost.

Incorrect. Traditional methods can sometimes apply an urgent patch to a single device quickly, but at scale they are typically slower and more error-prone. DNAC includes centralized image and upgrade management (SWIM) that can streamline patching across many devices with controlled workflows. Therefore, traditional management is not typically faster for patches/updates overall.

An empty ACL (no ACEs) is not a typical operational state on IOS; you generally cannot apply a truly empty ACL in a way that permits all traffic. If an ACL had no permit entries, the implicit “deny any” concept would result in blocking, not allowing. “All packets allowed” points away from an empty ACL and toward an overly permissive match.

If packets fail to match any permit statement, they hit the implicit deny at the end of the ACL (deny ip any any). That would cause traffic to be dropped, not allowed. So this option describes the opposite symptom (unexpected blocking), not “all incoming packets appear to be allowed.”

A deny statement being too high would typically cause more traffic to be blocked than intended, because it would match earlier and stop processing before later permits. That leads to “too much denied,” not “everything allowed.” It’s a real ACL ordering problem, but it does not explain the observed behavior.

Incorrect. It reverses the roles: TCP does provide error detection (checksum), sequencing, acknowledgments, and retransmissions to improve reliability. UDP does not provide message acknowledgments or retransmit lost data at the transport layer. While UDP can detect corruption via checksum, it does not guarantee delivery or recovery—applications must handle that if required.

Incorrect. It swaps the fundamental definitions. TCP is connection-oriented and provides reliable, ordered delivery using sequencing and acknowledgments. UDP is connectionless and does not provide reliable delivery or sequencing by default. If reliability is needed with UDP, it must be implemented by the application (or by another protocol layered above UDP).

Incorrect. TCP does use windowing (sliding window) as part of flow control and efficient reliable delivery, but UDP does not establish a three-way handshake and does not provide reliable message transfer. The three-way handshake (SYN, SYN-ACK, ACK) is a TCP-only mechanism used to establish a connection and synchronize sequence numbers.

Incorrect. switch# is privileged EXEC mode, used for show/clear/debug and some exec-level commands, not for configuring LLDP TLV advertisement behavior. While you can view LLDP neighbors and status from EXEC mode, enabling a specific TLV to be advertised requires configuration mode (typically interface configuration mode).

Incorrect. switch(config-line)# is line configuration mode (console/VTY/AUX), used for settings like login, transport input, exec-timeout, and access-class. LLDP is a Layer 2 discovery protocol and its TLV advertisement settings are not configured under line settings, so this mode is not applicable.

Incorrect. Global configuration mode is used for enabling LLDP overall (lldp run) and setting some global LLDP parameters, but the port-description TLV advertisement is controlled per interface. The distractor is plausible because LLDP is enabled globally, but the specific TLV command in this question is an interface-level configuration.

10.10.10.0/28 is Router1’s directly connected LAN on Gi0/0, but it is not a matching destination prefix for Host A (10.10.13.214). It would only be used for destinations in 10.10.10.0–10.10.10.15. This option can seem tempting because it is connected, but connected status does not override longest prefix match.

10.10.13.0/25 matches only addresses 10.10.13.0 through 10.10.13.127. Host A is 10.10.13.214, which is outside that range. Even though /25 is a valid route in the table, it cannot be used because it does not include the destination IP.

10.10.13.144/28 matches addresses 10.10.13.144 through 10.10.13.159 (a /28 has a block size of 16). Host A at 10.10.13.214 is not in that range. This option is a common trap because it is more specific than /25, but it still must contain the destination to be considered.

Incorrect. UDP does not provide a built-in recovery mechanism. There are no acknowledgments, sequence numbers, or retransmissions in UDP. If an application needs reliability while still using UDP, it must implement its own recovery logic at the application layer (or use a different protocol such as TCP).

Incorrect. UDP has no CTL field and does not perform a three-way handshake. A three-way handshake (SYN, SYN-ACK, ACK) is a TCP function used to establish a connection and synchronize sequence numbers. UDP is connectionless and begins sending data immediately without session establishment.

Incorrect. UDP does not maintain connection state. It is stateless at the transport layer, meaning it does not track sessions, sequence numbers, or window sizes. “More stable connections” is not applicable to UDP because it does not create a connection in the TCP sense.

Asynchronous routing is not a typical CCNA WAN architecture option used to describe scalable and reliable enterprise WAN design. While traffic can sometimes take different forward/return paths in real networks, that behavior is not a design goal or a named architecture choice in this context. CCNA questions about scalability/reliability usually point to redundancy (dual-homing) and dynamic routing for failover.

Single-homed branches connect to the WAN through one circuit/provider/edge path. This is simple and cost-effective, but it reduces reliability because the branch has a single point of failure (link failure, provider outage, CPE failure). It also limits scalability for high availability because adding redundancy later often requires redesigning addressing, routing, and edge hardware.

Static routing can work well for small, stable networks, but it does not scale because every new network or topology change requires manual updates. For reliability, static routes do not inherently adapt to failures; you must add mechanisms like floating static routes and IP SLA/object tracking, which increases complexity and still lacks the flexibility of dynamic routing in larger WANs.