Select Two (Multi-Select) Questions

Standard IPv4 ACLs use numbers in the range 100-199.

Why wrong: Standard IPv4 ACLs are numbered in the ranges 1–99 and 1300–1999, not 100–199. The number range 100–199 is explicitly reserved for extended numbered ACLs, which evaluate source and destination IP addresses, protocol, and port numbers. Misidentifying 100–199 as standard ACL numbers confuses the ACL type and its underlying matching logic.

Standard IPv4 ACLs filter only the source IP address and are best placed close to the source to be most effective.

Why wrong: Standard ACLs indeed filter only on the source IP address, but that limited matching capability requires them to be placed as close to the destination as possible, not the source. If placed near the source, a standard ACL entry that denies a particular source would block that source's traffic to all destinations, including legitimate ones. Positioning near the destination limits the ACL's impact to the intended target network, avoiding accidental collateral denial.

Numbered ACLs allow individual access control entries (ACEs) to be deleted without removing the entire ACL.

Why wrong: Numbered ACLs do not permit deletion of an individual access control entry; to remove one ACE, the entire ACL must be deleted and re-entered without that entry. Named ACLs, in contrast, assign sequence numbers to each ACE, allowing selective deletion, insertion, and resequencing without recreating the full list. This operational limitation of numbered ACLs applies to both standard and extended numbered variants and is a common source of configuration errors.

Single-mode fiber (SMF) typically uses a larger core diameter than multimode fiber (MMF).

Why wrong: Single-mode fiber (SMF) has a much smaller core diameter than multimode fiber (MMF). SMF typically uses a 9-micron core with a 125-micron cladding (9/125 µm), while MMF cores are either 50 or 62.5 microns (50/125 µm or 62.5/125 µm). Because the core is so narrow, SMF permits only a single propagation path (mode) for light, which is the opposite of the claim in the statement.

Multimode fiber (MMF) is generally preferred for longer-distance links, such as between buildings on a campus network.

Why wrong: Multimode fiber is not preferred for longer-distance campus links because its larger core allows multiple light paths, causing modal dispersion that broadens pulses and limits the usable distance. Single-mode fiber, with lower attenuation and essentially no modal dispersion, is the standard choice for building-to-building or WAN distances, often reaching 10 km or more with appropriate optics. MMF is instead used for shorter reaches such as within a data center or access-floor cabling.

A 1000BASE-LX SFP transceiver operating over single-mode fiber can support distances up to 10 km.

Why wrong: The 1000BASE-LX standard over single-mode fiber supports distances up to 5 km, not 10 km. Some transceivers may support longer distances with additional optics, but the standard specification is 5 km, making this statement inaccurate.

Standard ACLs should be placed as close to the source as possible.

Why wrong: Placing a standard ACL close to the source is incorrect because it will evaluate every packet from that source regardless of its final destination, potentially dropping traffic that should be allowed to other networks. Since standard ACLs cannot match the destination address, a permit or deny statement applies globally to all destinations for the specified source. Cisco recommends applying standard ACLs near the destination, while extended ACLs — which can match destination — should indeed be placed close to the source to reduce unnecessary transit traffic.

Standard ACLs can filter traffic based on destination IP address.

Why wrong: Standard ACLs do not look at the destination IP address at all — each ACE contains only a permit/deny decision based on the source address, with an optional wildcard mask. Because the router never inspects the destination field of the packet, a standard ACL cannot differentiate between traffic going to one host and traffic going to another. This is why extended ACLs are required when you need to match both source and destination addresses.

Standard ACLs can filter traffic based on TCP or UDP port numbers.

Why wrong: Standard ACLs cannot filter by TCP or UDP port numbers because they operate only at Layer 3 and match solely on the source IP address and wildcard mask. Port fields are Layer 4 information, which the standard ACL code never examines; only an extended ACL (numbered 100–199 or named) can specify protocol and port numbers in its entries. Thus, any attempt to use a standard ACL to block a specific web service or application port will fail.

Set the interface network type to point-to-point

Why wrong: Setting the OSPF network type to point-to-point on the interface changes timer values and eliminates DR/BDR election, but Hellos are still sent periodically and the interface remains fully active in the OSPF process. Since the requirement is to prevent Hello transmission while still advertising the connected network, this does not satisfy it. The point-to-point type is appropriate for serial links but does not suppress adjacency formation.

Apply distribute-list out on the interface

Why wrong: A distribute-list out is used to filter routes from being advertised in routing updates, but OSPF does not use it to suppress Hellos; OSPF relies on the Hello protocol for neighbor discovery. This command operates on the routing table and redistributed routes, not on interface-level OSPF processes like Hello transmission. Thus, applying a distribute-list out on the interface has no bearing on whether the interface sends or receives Hellos.

NETCONF uses HTTP methods such as GET, POST, PUT, and DELETE to manipulate configuration data.

Why wrong: NETCONF does not run over HTTP; it uses XML-based Remote Procedure Calls (RPCs) carried over a secure, connection-oriented transport such as SSH (port 830) or TLS. Operations like <get-config>, <edit-config>, and <commit> are exchanged as XML messages, not as HTTP GET/POST/PUT/DELETE requests. HTTP method semantics are specific to RESTCONF, which is a distinct protocol.

NETCONF uses a separate commit operation to apply changes, while RESTCONF uses a similar commit mechanism.

Why wrong: NETCONF provides a candidate configuration datastore with a distinct <commit> operation (and optional <rollback>) to atomically apply a set of changes. RESTCONF, however, does not implement a separate commit phase; every HTTP request (e.g., POST, PUT, PATCH) directly modifies the intended running datastore immediately. Therefore, saying RESTCONF uses a similar commit mechanism is incorrect; RESTCONF cannot provide multi-change atomic transactions like NETCONF's candidate datastore.

The OSPF route is installed because cost 20 is lower than metric 0

Why wrong: This statement incorrectly compares OSPF's cost (20) to the static route's metric (0) and assumes a lower number wins. In Cisco IOS, a router first compares administrative distance when multiple routing sources provide a path to the same network; only if AD values are equal are metrics compared. Since the static route's AD of 5 is much lower than OSPF's default AD of 110, the static route is installed into the routing table despite OSPF having a lower metric value. The OSPF cost is irrelevant until the static route is removed, at which point OSPF becomes the active route by default, not because its cost is lower.

Both routes are installed as equal-cost paths automatically

Why wrong: Equal-cost multipath (ECMP) only applies when multiple routes to the same prefix have the same administrative distance and the same metric, and they are usually from the same routing protocol. Here the static route has an AD of 5 while OSPF has an AD of 110, so they are not equal from the router's perspective. Moreover, their metrics—0 for the static and 20 for OSPF—are not comparable across different protocols. Therefore, the router does not install both; it selects only the static route as the single best path.

ifconfig

Why wrong: ifconfig is a legacy Unix tool for configuring and displaying network interfaces; it may be absent on modern Linux distributions that rely on iproute2. It shows local address and link status, but it never sends packets to a remote destination. Deprecated and often not installed by default, its interface display role is now superseded by 'ip addr'.

tracert

Why wrong: tracert is a Windows command that traces the path to a destination by sending ICMP packets with incrementally increasing TTL values and reporting intermediate routers. Linux uses 'traceroute' instead, typically with UDP or ICMP; the name and default behavior differ. It diagnoses routing paths, not basic connectivity, and may still show replies even if the final host rejects/doesn't respond to pings.

nslookup

Why wrong: nslookup queries DNS servers to resolve domain names to IP addresses or to retrieve DNS records like A, AAAA, MX, or NS. It tests the DNS resolution service, not IP connectivity; a successful query only proves the DNS server is reachable, not the target host. It is the wrong tool for checking whether a host is up, since it does not send any packets to the target host's IP address.

Giants

Why wrong: Giants are frames exceeding the 1518-byte maximum size, typically reflecting an MTU misconfiguration, an enabling of jumbo frames across a path, or faulty hardware that fails to enforce the frame-size limit. A duplex mismatch does not produce oversized frames; the resulting collisions and backoff logic cause short transmissions or bit errors, not extended-length buffers. Consequently, a network administrator seeing giants should investigate layer-2 MTU policies or NIC failures rather than suspecting a duplex negotiation problem.

Input errors

Why wrong: Input errors is a cumulative counter that aggregates specific inbound error types such as runts, CRC errors, and frame errors. A duplex mismatch typically manifests as runts or CRC errors on the receiving interface, so merely seeing a positive input errors count does not isolate the cause. Network engineers must inspect the detailed subcounters to identify the exact frame-level error, making 'input errors' too generic for this specific failure mode.

Output errors

Why wrong: Output errors is a broad counter encompassing transmit-side anomalies such as collisions, late collisions, underruns, and buffer failures, so it can increase for many reasons unrelated to duplex mismatch. On a half-duplex link experiencing a mismatch, the interface will indeed log collisions (a subset of output errors), but the more specific late-collision counter is the decisive indicator. Therefore, while output errors may be elevated, they are not a specific diagnostic marker unless the late-collision count is examined separately, making the option too general for the scenario.

Flaps

Why wrong: Interface flaps refer to a link that repeatedly transitions between up and down states, often triggered by physical-layer problems like a loose cable, faulty optics, or excessive signal loss. A duplex mismatch does not cause the link to go down; instead, the link remains up while suffering from collision-induced corruption and timing issues. Therefore, flaps are attributable to physical integrity problems rather than to mismatched duplex settings between the two connected devices.

Both addresses are normal host addresses that can be assigned to users.

Why wrong: The network address and broadcast address are both reserved and cannot be assigned to end-user devices. The network address has all host bits set to 0, while the broadcast address has all host bits set to 1; only addresses strictly between these two endpoints are available as usable host addresses. Therefore, calling them normal host addresses misrepresents their reserved role in IPv4 subnetting.

The broadcast address always becomes the default gateway.

Why wrong: The default gateway is not the broadcast address; it is the IP address of a router interface that resides within the subnet and is a usable host address. A broadcast address is used to send packets to every host in the subnet and cannot serve as a unicast destination. A router might use one of the usable host addresses, but the broadcast address is never used as the default gateway.

These concepts exist only in IPv6 and not IPv4.

Why wrong: These concepts are specific to IPv4, not IPv6. IPv4 uses both network and broadcast addresses to define subnet boundaries, whereas IPv6 does not have a broadcast address at all; it relies on multicast for group communication. Thus the statement incorrectly reverses the existence of these address types between the two protocol versions.

The command 'show ip nat statistics' displays the current active translations including inside and outside addresses.

Why wrong: The 'show ip nat statistics' command provides aggregate counters such as total translations, hits, misses, and pool usage, but it does not display the actual NAT translation entries. To see the individual inside local, inside global, outside local, and outside global address mappings, you must use 'show ip nat translations'. Therefore, this command is incorrect for viewing active translations.

To verify that static NAT is working, you should check the output of 'show ip interface brief' and look for the translated IP.

Why wrong: The 'show ip interface brief' command only displays interface status, protocol, and IP address information, not NAT translation details. It would not reveal any static NAT mappings or translated addresses. To verify a static NAT configuration, you need to use 'show ip nat translations' to see the actual mapping, or 'show ip nat statistics' to confirm that the translation counter is incrementing.

Predictive analytics uses historical data to forecast future network conditions and automatically reconfigures network devices to prevent issues.

Why wrong: Predictive analytics performs trend analysis and forecasting using historical metrics, but it does not directly execute configuration changes. In a closed-loop automation stack, the prediction output feeds a policy engine or orchestrator that decides and enforces actions via Northbound Interfaces or device configuration protocols. The statement incorrectly merges the separate functions of predictive insight and automated remediation.

ML models in network operations are trained exclusively on labeled datasets to detect known attack signatures.

Why wrong: Machine learning in network operations is not restricted to supervised learning on labeled attack signatures. Unsupervised and semi-supervised techniques learn from unlabeled telemetry and packet flows, enabling baseline modeling and zero-day anomaly detection. While signature-based detection uses labeled data, modern ML-driven NDR and NetOps platforms employ clustering, autoencoders, and other label-free methods to identify novel threats and performance issues.

Rule-based systems are preferred over ML for anomaly detection because they can adapt to new, unknown patterns without manual updates.

Why wrong: Rule-based systems fundamentally require manual updates to their predefined rulesets to detect new, unknown patterns, directly contradicting the option's claim. This adaptive learning capability, identifying novel anomalies without explicit programming, is a core strength of machine learning. The option is tempting because rule-based systems are highly effective for detecting *known* anomalies or specific policy violations, offering deterministic and auditable reasons for alerts in well-understood, static network environments.

ARP is used to discover the remote router's OSPF router ID

Why wrong: ARP is completely unrelated to the OSPF router ID, which is a 32-bit value that identifies a router within the OSPF domain. The router ID is selected administratively or derived from the highest active interface address, and it is advertised in OSPF hello packets, database descriptors, and LSAs. Discovering a neighbor's OSPF router ID happens via OSPF protocol exchange, not through any Layer 2 address resolution. ARP's scope is confined to resolving an IP address to a MAC address for local delivery, so it has no role in routing protocol elections or identifiers.

ARP replaces DNS for hostname resolution

Why wrong: ARP does not replace DNS because the two protocols solve different problems in the TCP/IP stack. DNS translates human-readable hostnames like www.example.com into IPv4 or IPv6 addresses through a hierarchical system of nameservers, typically using UDP or TCP port 53. Once the host already knows the destination IP address, ARP then resolves that IP address to a MAC address for use in the data link layer frame. Thus, DNS operates at the application layer and performs name-to-IP resolution, while ARP operates at the network/data link boundary and performs IP-to-MAC resolution, making them complementary rather than interchangeable.

Administrative distance

Why wrong: Administrative distance is a router parameter used to select the best path when multiple routing protocols offer routes to the same destination; it is not a Layer 2 or access-switch security mechanism. It operates in the control plane of routers, comparing trustworthiness of routing protocol sources, and does not inspect frames, authenticate devices, or prevent unauthorized access on a switch port. Therefore, it has no bearing on hardening access switch security.

Route summarization

Why wrong: Route summarization, also called route aggregation, reduces the size of routing tables by advertising a single, less-specific prefix that represents multiple more-specific routes. It is a scalability and convergence optimization for routing protocols like OSPF and EIGRP, not a security feature. On an access switch, route summarization cannot block frames, deter MAC spoofing, or protect spanning-tree domain, so it is unrelated to access-switch security hardening.

switchport protected

Why wrong: The 'switchport protected' command enables the Private VLAN Edge (PVE) feature, also known as protected ports, on a Layer 2 interface. Its sole purpose is to prevent communication between protected ports on the same switch—traffic from a protected port cannot be forwarded to another protected port, though it can still reach uplink or non-protected ports. This command has no bearing on MAC address learning limits or port-security violations; it changes the forwarding domain, not the number of MAC addresses the port will learn, making it irrelevant to the requirement of restricting the switch to one learned MAC address.

switchport nonegotiate

Why wrong: The 'switchport nonegotiate' command is used on a switchport to disable Dynamic Trunking Protocol (DTP), thereby preventing the interface from negotiating trunk or access mode with its neighbor. This is commonly configured on trunk ports to stop DTP frames from being sent, but it does nothing related to port security, MAC address learning, or violation handling. Since the question is about limiting the MAC address count on an access port, this command is completely unrelated and would not achieve the desired outcome of shutting down the port after learning one MAC address.

The token changes the API from REST to SNMP

Why wrong: REST and SNMP are fundamentally different management protocols—REST uses HTTP over TCP with JSON or XML payloads, while SNMP uses UDP or TCP with a MIB-based structure and community strings or v3 security. An authentication token is merely a credential attached to the HTTP request; it has no ability to alter the underlying protocol or the API's behavior. The API remains RESTful; the token simply authenticates the caller, so it cannot change REST to SNMP.

The token must be stored in the router startup-config

Why wrong: Router startup-config is used to store persistent device settings like interface IP addresses, routing protocols, and administrative credentials for device access, not ephemeral API session tokens. Placing a controller API token there would be inappropriate, as it is not part of the router's operating configuration and would pose a security risk if left in plaintext in a config file. Applications and scripts manage tokens in memory or secure storage, never in the router's NVRAM-based configuration.

DHCP is used primarily to translate private addresses into public addresses.

Why wrong: DHCP is not designed for address translation between private and public address spaces; that function belongs to Network Address Translation (NAT), typically implemented on routers or firewalls. DHCP's role is limited to dynamically assigning IP configuration—such as IP address, subnet mask, default gateway, and DNS servers—to hosts within a local network. While DHCP may work alongside NAT in many enterprise environments, conflating the two misidentifies their distinct purposes, as DHCP does not modify or translate IP headers.

DHCP replaces the need for subnet masks and default gateways.

Why wrong: DHCP does not eliminate the need for subnet masks and default gateways; rather, it automates the delivery of these essential parameters to clients. A subnet mask is still required to determine the network and host portions of an IP address, and a default gateway is essential for routing traffic outside the local subnet. Without these values, a client would be unable to determine which destinations are local or how to reach remote networks—DHCP simply distributes them automatically, saving administrators from manual configuration and reducing errors.

DNS and DHCP are both Layer 1 technologies.

Why wrong: DNS and DHCP operate at the application layer (Layer 7) of the OSI model, not at Layer 1. Layer 1 is the physical layer, which involves the transmission and reception of raw bit streams over physical media like cables, fiber, or radio waves. In contrast, DNS and DHCP use higher-layer protocols—DNS primarily uses UDP port 53 or TCP port 53, while DHCP uses UDP ports 67 and 68—and depend on Layer 3 (IP) and Layer 4 (UDP/TCP) services for their operation, making them clearly not Layer 1 technologies.

ARP is used to map IPv6 addresses to MAC addresses.

Why wrong: ARP is exclusively used for IPv4 address resolution over Ethernet. IPv6 hosts and routers rely on Neighbor Discovery Protocol (NDP) implemented as ICMPv6 messages, exchanging Neighbor Solicitation and Neighbor Advertisement packets to map IPv6 addresses to MAC addresses. NDP operation uses solicited-node multicast addresses rather than Layer 2 broadcast, so ARP is not applied to IPv6.

ARP is forwarded by routers across subnets by default.

Why wrong: ARP messages are not routable between subnets because they are encapsulated directly within Ethernet frames without an IP header or routing layer. Each subnet constitutes a separate broadcast domain, so an ARP request from one VLAN or subnet stays within that local segment. To send traffic across subnets, end hosts forward IP packets to the default gateway's MAC, and the router performs ARP on each destination subnet independently.

802.11ac uses OFDMA, while 802.11ax uses only OFDM.

Why wrong: That statement reverses the actual evolution. 802.11ac relies on conventional OFDM, allocating the entire channel to a single user at a time. 802.11ax introduces OFDMA, which partitions each channel into smaller subcarrier groups (resource units) so multiple clients can transmit concurrently, improving spectral efficiency and reducing overhead, especially in dense environments.

Both 802.11ac and 802.11ax operate exclusively in the 5 GHz band.

Why wrong: This is incorrect because 802.11ax was designed to support both the 2.4 GHz and 5 GHz bands, while 802.11ac was defined for the 5 GHz band exclusively. The dual-band support in 802.11ax allows upgrades of legacy 2.4 GHz networks and improves efficiency in dense deployments, whereas 802.11ac's single-band limitation avoided the congested 2.4 GHz spectrum but reduced flexibility.

802.11ac introduces target wake time (TWT) for improved power saving, but 802.11ax does not support it.

Why wrong: This statement gets the technology generation backwards. Target Wake Time (TWT) is a key power-saving feature introduced in 802.11ax, enabling stations to schedule negotiated wake times and sleep between exchanges, which reduces contention and battery drain. 802.11ac did not include TWT; instead it relied on earlier power-save mechanisms like PS-Poll or U-APSD, making the claim false.

They must have identical router IDs.

Why wrong: Each OSPF router must have a unique Router ID (RID), typically the highest loopback or active interface IP address, because the RID is the primary key for OSPF neighbor and database descriptions. If two routers share the same RID, they will reject each other as duplicates, causing the neighbor relationship to flap or never establish. Identical RIDs are therefore invalid and harmful, not a requirement.

They must use the same process ID number on both routers.

Why wrong: The OSPF process ID is a purely local parameter used to distinguish multiple OSPF processes running on the same router; it is not transmitted in any OSPF packet. Since hello, database descriptor, and link-state packets contain no process ID field, two routers can have completely different process IDs and still form a full adjacency. This makes the process ID irrelevant to neighbor requirements, unlike the area ID or subnet masking.

It is a replacement for OSPF adjacency formation

Why wrong: OSPF is a dynamic routing protocol that exchanges hello packets to form and maintain adjacencies, and builds link-state databases to compute routes. YANG is not a routing protocol and has no mechanism to send hello messages or calculate routing paths. At best, YANG models can be used to configure OSPF parameters, but they can never replace the protocol's adjacency formation process.

It is the same thing as JSON syntax

Why wrong: JSON is a lightweight data-interchange syntax that encodes key-value pairs, arrays, and nested objects, whereas YANG is a schema language that defines the semantic meaning, types, and constraints of data. Although YANG data can be serialized using JSON syntax, the YANG model itself is not JSON, and a JSON file without a YANG model lacks formal validation rules. They operate at different layers: YANG defines the rules, JSON represents instances.

It automatically discovers neighbors on a LAN

Why wrong: YANG does not send or receive any packets, so it cannot discover neighbors on a LAN. Neighbor discovery is performed by protocols like LLDP, CDP, or IPv6 ND, which exchange messages at Layer 2 or Layer 3. YANG is purely a modeling language that describes data structures; it has no runtime behavior in the data plane.