Practice Test #3

Incorrect. Flooding traffic out all interfaces in the same VLAN describes Layer 2 switching behavior for unknown unicast/broadcast/multicast, not HSRP. HSRP operates at the default-gateway (first-hop) function using a virtual IP/MAC and router state machines. It does not provide redundancy by VLAN flooding and does not “load-balance Layer 2 traffic along the path.”

Incorrect. Forwarding multiple packets to the same destination over different routed links describes per-packet load balancing or multipath forwarding concepts, not first-hop redundancy. HSRP does not split traffic across multiple routed links for the same flow; it ensures a single default gateway remains available by failing over Active/Standby roles.

Incorrect. Assigning the same metric to multiple routes in the routing table describes equal-cost multipath (ECMP) routing. ECMP is a routing-plane feature used to load-share across multiple next hops to a destination. HSRP is not a routing protocol and does not manipulate route metrics; it provides a redundant default gateway on a LAN via a virtual IP/MAC.

Incorrect. Configuring unused ports as trunks is insecure because trunks can carry multiple VLANs and may allow unintended access if connected to another switch or a malicious device. Trunking also introduces risks around negotiation (DTP) and VLAN hopping scenarios if misconfigured. For unused ports, best practice is access mode + shutdown, not trunk mode.

Incorrect. CDP is a Layer 2 discovery protocol that advertises device information (platform, software version, management addresses). Enabling it on unused ports does not protect them; it can actually leak useful reconnaissance data to an attacker who plugs into the port. Security best practice is often to disable CDP on untrusted/user-facing ports.

Incorrect. EtherChannel is used to bundle multiple physical links into one logical link for redundancy and increased bandwidth, typically between switches or switch-to-server designs. It does not provide a security control for unused ports and would be irrelevant (and potentially disruptive) if applied to interfaces that should not be active.

Incorrect. In VTP transparent mode, the switch does not process VTP updates to modify its VLAN database, and it does not act like a VTP participant that learns VLANs from clients/servers. While it can forward VTP advertisements over trunk links, “transmits and processes VTP updates” implies it is actively participating in VTP synchronization, which transparent mode does not do.

Incorrect. VTP advertisements are carried over trunk links, not access ports. Access ports belong to a single VLAN and do not transport VTP control traffic between switches. Even if a switch is in server/client mode, VTP update exchange requires trunking (e.g., 802.1Q). Therefore, processing VTP updates from clients on access ports is not how VTP operates.

Incorrect. A transparent switch does not receive VTP updates and apply them to its VLAN database, and it does not advertise its locally configured VLANs via VTP to other switches. Local VLAN creation on a transparent switch remains local only. Although it may forward VTP advertisements that it hears, it is not forwarding “locally configured VLANs” as VTP updates.

Incorrect. The access layer’s primary role is providing Layer 2 access for end devices (PCs, phones, APs) and applying edge features like port security and VLAN assignment. Routing between different VLANs/subnets (different broadcast domains) is typically performed at the distribution layer (or at a collapsed core/distribution in smaller designs), not at the access layer in a classic three-tier model.

Incorrect. Wired connections for each host are provided by the access layer, where end devices physically connect. The core layer is not designed for endpoint attachment; it is the high-speed backbone that interconnects distribution blocks. Connecting hosts directly to the core would reduce scalability and complicate operations, violating the hierarchical design principle of keeping the core simple and resilient.

Incorrect. The core and distribution layers have different purposes. Distribution is the aggregation and policy boundary layer (routing, ACLs, QoS, summarization, FHRP), while the core is the fast, resilient transport layer intended to move traffic quickly between distribution blocks. Although both may run Layer 3, they are not considered to perform the same functions in three-tier design.

Explicitly assigning a link-local address does not cause a global unicast address to be generated. Link-local addresses (FE80::/10) are used only on the local segment for neighbor discovery and next-hop resolution. Even though link-local can be derived from the MAC via EUI-64, it is not a global unicast address and does not satisfy the question’s requirement.

Disabling the EUI-64 process would prevent forming an interface identifier from the MAC address, which is the opposite of what the question asks. If EUI-64 is disabled (or if privacy extensions/random IIDs are used instead), the interface will not derive the IID from the MAC. Therefore this action cannot be required to create a MAC-derived global unicast address.

Configuring a stateful DHCPv6 server provides IPv6 addresses by server assignment, not by the interface deriving the address from its own MAC. DHCPv6 can hand out any address from a pool and does not require EUI-64-based IIDs. While DHCPv6 is a valid addressing method, it is not the required action to get a MAC-derived global unicast address.

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) is primarily an IPv6 transition mechanism that tunnels IPv6 over IPv4 within a site. It is not a general-purpose site-to-site VPN technology for carrying multicast between remote sites, and it does not provide encryption by itself. In CCNA context, ISATAP is about IPv6 connectivity, not multicast VPN design.

IPsec over ISATAP is not a standard or common CCNA-relevant design for “multicast between remote sites.” ISATAP is used to provide IPv6-over-IPv4 connectivity (usually intra-site), and adding IPsec would address encryption but still doesn’t make it the typical solution for multicast transport between sites. The exam expects GRE as the multicast-capable tunnel mechanism.

GRE can carry multicast traffic because it creates a tunnel interface and encapsulates packets (including multicast) inside a unicast GRE header. This makes it useful for running multicast and routing protocols across an IP network. However, GRE provides no encryption, authentication, or integrity, so it does not meet the requirement to “support encryption.”

192.168.16.143 is within the private 192.168.0.0/16 range, but that is not an error condition on Cisco routers. Private addresses are commonly used on internal interfaces and are fully supported. The message is triggered by an invalid host assignment for the given subnet mask, not by the address being private.

Cisco routers support /28 masks (255.255.255.240) on IPv4 interfaces. The error text can mislead candidates into thinking the mask itself is unsupported, but IOS is actually rejecting the specific IP address because it falls on a reserved address (broadcast) for that /28 subnet.

A network address in a /28 would be the first address of the 16-address block (for example, 192.168.16.128, 192.168.16.144, etc.). 192.168.16.143 is not the network address for any /28; it is the last address of the 192.168.16.128/28 block, which makes it the broadcast address instead.

Channels 5, 6, and 7 are adjacent and heavily overlapping in 2.4 GHz. Although they are different channel numbers, their 20/22 MHz bandwidths overlap significantly, creating adjacent-channel interference. This increases contention and retransmissions, which can look like “collisions” and reduces overall WLAN performance. This is a common trap option because it seems like using multiple channels should reduce collisions.

Channels 1, 2, and 3 also overlap heavily. Because 2.4-GHz channels are only 5 MHz apart but occupy ~20–22 MHz, these channels share much of the same spectrum. Deploying APs on 1/2/3 in the same area typically worsens interference and leads to more retries and lower throughput. Different channel numbers do not guarantee separation in 2.4 GHz.

Channels 1, 5, and 10 are not a non-overlapping set. Channel 5 overlaps with both 1 and 6, and channel 10 overlaps with 11 (and partially with 6/9 depending on bandwidth). While the numbers appear evenly spaced, the actual RF channel width makes them interfere with each other. This option is appealing if you assume channel numbers map directly to non-overlap.

Incorrect. While layering encourages separation of concerns, it is not true that changes in one layer do not impact other layers. Real networks have cross-layer dependencies (e.g., Layer 2 MTU affects Layer 3 fragmentation and Layer 4 performance; Layer 1 errors affect higher-layer throughput). The OSI model reduces complexity, but it does not guarantee complete independence between layers.

Incorrect. The OSI model does not ensure reliable delivery; it is a reference framework. Reliability depends on specific protocols and mechanisms, such as TCP at Layer 4 (sequencing, acknowledgments, retransmissions) or certain Layer 2 features. The OSI model helps describe where reliability mechanisms might exist, but it does not provide them by itself.