Network Fundamentals practice questions

172.32.0.0/12

Why it fails: This is not private; 172.16.0.0/12 is.

172.15.0.0/12

Why it fails: The 172.15.0.0/12 range falls outside the RFC 1918 private block, which reserves 172.16.0.0/12 (i.e., 172.16.0.0 through 172.31.255.255). 172.15.0.0/12 is part of the public internet address space. It tempts because the 172.x.x.x prefix resembles the well-known private 172.16.0.0/12 range, and a candidate might misremember the exact starting boundary as 172.15.0.0 instead of 172.16.0.0. This address would be correct if the question asked for a public range or a different private block.

11.0.0.0/8

Why it fails: 10.0.0.0/8 is private, not 11.0.0.0/8.

2, 7, 12

Why it fails: Channel 12 is not available in all regulatory domains, and 2 and 7 overlap.

1, 5, 9

Why it fails: These channels overlap.

1, 3, 5

Why it fails: Channels 1, 3, and 5 overlap.

The default gateway is missing.

Why it fails: Even with a gateway, they are on different subnets; but the gateway could route, but the question asks most likely reason. Actually, both could be true, but the subnet mismatch is the root cause.

The ARP cache is corrupted.

Why it fails: ARP is needed for same subnet; they are on different subnets.

The hosts are using different DNS servers.

Why it fails: DNS is not involved in local communication.

169.254.0.0/16

Why it fails: 169.254.0.0/16 is link-local (APIPA), not private.

11.0.0.0/8

Why it fails: Private range is 10.0.0.0/8, not 11.0.0.0.

172.32.0.0/12

Why it fails: Private range is 172.16.0.0/12, not 172.32.0.0.

Uses only 20 MHz channels

Why it fails: Wi-Fi 6 supports channel widths up to 160 MHz.

Maximum theoretical speed is lower than Wi-Fi 5

Why it fails: Wi-Fi 6 has higher speeds than Wi-Fi 5.

Operates only on the 5 GHz band

Why it fails: Wi-Fi 6 operates on both 2.4 and 5 GHz.

172.32.0.0/12

Why it fails: 172.32.0.0 is not within 172.16.0.0/12.

172.15.0.0/12

Why it fails: 172.15.0.0/12 sits below the RFC 1918 block, which begins at 172.16.0.0; the /12 mask applied to 172.15.0.0 actually spans 172.0.0.0–172.15.255.255, so it never reaches 172.16.0.0. It tempts because 172.16.0.0/12 is the genuine private range, and the adjacent-looking prefix masks the one-octet offset.

192.167.0.0/16

Why it fails: 192.167.0.0 is not within 192.168.0.0/16.

CNAME

Why it fails: CNAME aliases one DNS name to another canonical name; it carries no address family and cannot hold an IPv6 address. It is the right record when pointing a hostname at another hostname, such as www to a load-balancer name, rather than resolving a name directly to an address.

MX

Why it fails: MX records identify mail exchangers for a domain and carry no host address, so they cannot resolve a name to an IPv6 address. They are correct when directing SMTP delivery to a domain's mail servers, a mail-routing task unrelated to address-family resolution.

A

Why it fails: An A record stores a 32-bit IPv4 address, so it cannot hold the 128-bit IPv6 address the query requires. It remains the correct choice for mapping a hostname to an IPv4 address, which is why it is the common answer whenever address resolution is requested without an explicit IPv6 qualifier.

192.167.0.0/16

Why it fails: 192.167.0.0/16 sits outside the RFC 1918 blocks, which are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16; the third octet here is 167, not 168. It is tempting because it closely resembles the genuine 192.168.0.0/16 private range, and such addresses would be valid for public allocation.

11.0.0.0/8

Why it fails: 11.0.0.0/8 falls within the public address space allocated to American Registry for Internet Numbers; RFC 1918 defines only 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. It is tempting because 10.0.0.0/8 is private and visually similar, but the first octet differs.

172.32.0.0/12

Why it fails: RFC 1918 defines 172.16.0.0/12, covering 172.16.0.0 through 172.31.255.255; 172.32.0.0/12 sits outside that block and is publicly routable. It tempts because it shares the 172 prefix and /12 mask, so candidates assume the whole 172 range is private.

802.11g

Why it fails: 802.11g is older, 2.4 GHz only.

802.11n

Why it fails: 802.11n is Wi-Fi 4, older standard.

802.11ac

Why it fails: 802.11ac is Wi-Fi 5, operates only in 5 GHz.

1, 3, 5, 7, 9, 11

Why it fails: Channels 1, 3, 5, 7, 9 and 11 overlap because each 2.4 GHz channel spans roughly 22 MHz, so adjacent odd numbers interfere. The tempting logic is that odd spacing avoids overlap, but only 1, 6 and 11 are truly non-overlapping.

1, 5, 9, 13

Why it fails: Channels 1, 5, 9 and 13 still overlap, since each 2.4 GHz channel occupies about 22 MHz and four-channel spacing leaves residual interference. The even spacing looks tidy, but the genuinely non-overlapping set is 1, 6 and 11.

2, 7, 12

Why it fails: Channels 2, 7 and 12 are spaced five channels apart, so their 22 MHz-wide signals overlap and interfere. Only 1, 6 and 11 are genuinely non-overlapping in the 2.4 GHz band. The five-channel spacing is tempting because it mirrors that pattern, but the offset breaks the required separation.

169.254.0.0/16

Why it fails: 169.254.0.0/16 is the link-local range used for APIPA self-assignment when DHCP fails, not an RFC 1918 private range. It is tempting because it is non-routable on the internet, but RFC 1918 specifies 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.

192.167.0.0/16

Why it fails: 192.167.0.0/16 sits outside the RFC 1918 private blocks, which are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16; the third octet must be 168, not 167. It is tempting because it closely resembles the genuine 192.168.0.0/16 range, so it would be the right answer only if the address began 192.168.

172.32.0.0/16

Why it fails: 172.32.0.0/16 sits outside the RFC 1918 private block, which spans 172.16.0.0 through 172.31.255.255; the second octet must fall in 16–31, so 32 is public. It tempts because it shares the 172 prefix and /16 mask with the genuine 172.16.0.0/12 range.

MX record

Why it fails: MX records identify mail exchangers for a domain and carry no IP address data, so they cannot resolve IPv6 addresses. They are tempting because MX records do reference hostnames, but those hostnames still need separate AAAA resolution. IPv6 address resolution requires AAAA records.

CNAME record

Why it fails: CNAME records alias one DNS name to another; they hold no address data, so they cannot resolve an IPv6 address. They are tempting because they do redirect queries, but that is name aliasing, not address resolution. AAAA records map hostnames to 128-bit IPv6 addresses.

A record

Why it fails: A records map hostnames to 32-bit IPv4 addresses, so they cannot resolve IPv6. They are tempting because A records are the standard hostname-to-address mechanism, and the equivalent role for IPv6 is filled by AAAA records, which store 128-bit addresses.

Connection-oriented

Why it fails: UDP is connectionless: it transmits datagrams with no handshake, acknowledgement or session state, so it cannot be connection-oriented. The temptation is to confuse it with TCP, whose three-way handshake and sequencing genuinely provide connection-oriented delivery where reliable, ordered transport is required.

Reliable delivery

Why it fails: UDP provides best-effort, connectionless datagram delivery with no acknowledgements, retransmission or sequencing, so reliability is absent. It is tempting because some applications add their own reliability above UDP, but the protocol itself offers none; TCP supplies reliable delivery instead.

Channel 11

Why it fails: Channel 11 is non-overlapping but the question asks for two, so combining with 1 or 6 is valid. However, the question expects two answers, and three are non-overlapping; choosing 1 and 6 is a common pair.

Channel 9

Why it fails: Channel 9 overlaps with channels 6 and 11.

Channel 3

Why it fails: Channel 3 overlaps with channels 1 and 6.

Application plane

Why it fails: Application plane is sometimes used, but the core SDN architecture consists of control and data planes.

Forwarding plane

Why it fails: Forwarding plane is synonymous with data plane, but the question asks for two distinct components; control and data are the standard pair.

Management plane

Why it fails: While part of networking, the management plane is not a distinct SDN architecture component in the same sense.

The subnet mask is 255.255.255.192.

Why it fails: A /25 prefix leaves 7 host bits, giving a mask of 255.255.255.128, not 255.255.255.192, which corresponds to /26. The 255.255.255.192 mask is tempting because it is the common subnetting value for splitting a /24 into four, but here it would halve the address space the stem specifies.

The network address is 172.16.5.128.

Why it fails: With 172.16.5.0/25, the network address is 172.16.5.0 and 172.16.5.128 is the first address of the second /25 subnet. That value is tempting because it is a legitimate network address for the adjacent subnet, but applying it here misplaces the boundary the /25 prefix defines.

SYN, then ACK, then FIN

Why it fails: SYN is used to initiate a connection, not to terminate it. The three-way handshake (SYN, SYN-ACK, ACK) establishes a connection. Using SYN here would attempt to open a new connection rather than gracefully close the existing one, which is not the correct behavior for teardown.

ACK, then FIN, then ACK

Why it fails: This sequence is incomplete and out of order. While ACK and FIN are involved in teardown, a graceful close requires both sides to send FIN and receive ACK. Sending ACK first without a FIN does not initiate termination. The correct sequence involves FIN from each side followed by ACKs.

RST, then ACK

Why it fails: RST is used for an abrupt, ungraceful termination of a connection. It does not ensure that all outstanding data is delivered and acknowledged. The scenario requires a graceful close, so using RST would be incorrect because it can cause data loss and does not follow the normal four-way teardown process.

Send a POST request to /dataservice/device with the username and password in the body to retrieve the device list.

Why it fails: The /dataservice/device endpoint is used to retrieve device information via GET, not to authenticate. Sending credentials in the body of a POST to this endpoint would not create a session and would likely return an error or ignore the credentials. Authentication must occur first at /j_security_check.

Generate an API key from the vManage GUI and include it in the X-API-Key header for all requests.

Why it fails: Cisco SD-WAN vManage does not use API keys for its native REST API authentication. It uses session cookies. API keys are common in other platforms, but here they are not supported. Attempting to use an X-API-Key header would not authenticate the request and would result in a 401 error.

Use HTTP Basic Authentication with the username and password encoded in Base64 in the Authorization header for every request.

Why it fails: Cisco SD-WAN's vManage API does not support HTTP Basic Authentication for its REST endpoints. It relies on session cookies obtained via /j_security_check. Using Basic Auth would result in a 401 Unauthorized error because the controller expects a valid JSESSIONID cookie, not an Authorization header.

TCP port 123

Why it fails: TCP port 123 is used by NTP, but NTP is a specialized time synchronization protocol, not a general-purpose request/response mechanism. The scenario asks for a simple request and response without connection state; using TCP would add handshake overhead and reliability guarantees that are unnecessary here. A developer would not typically implement raw NTP over TCP for a custom one-off time query.

UDP port 123

Why it fails: UDP port 123 is indeed used by NTP, but the question describes a custom script sending a single small request and receiving a single small response, not implementing the NTP protocol itself. Choosing this port implies using NTP, which requires specific packet formatting and is not a generic transport choice. The scenario focuses on the transport characteristics, not on a specific application protocol.

UDP port 69

Why it fails: UDP port 69 is associated with TFTP, which is used for file transfers, not for time queries. While TFTP is connectionless and lightweight, it is designed for reading and writing files, not for retrieving the current time. Using this port would be incorrect because the application protocol does not match the requirement.

A routed link with OSPF enabled

Why it fails: A routed link with OSPF would place the two switches in different subnets and require Layer 3 routing between them. This directly contradicts the requirement to avoid routing. While OSPF can provide redundancy and path selection, it does not create a single local area network; instead, it separates broadcast domains and introduces routing overhead that the engineer explicitly wants to avoid.

A trunk link carrying multiple VLANs

Why it fails: A trunk link is used to carry traffic for multiple VLANs between switches, which is useful when segmentation is required. However, the scenario asks for devices on both switches to communicate as if on the same LAN, implying a single broadcast domain. A trunk would require VLAN configuration and does not by itself create a single flat Layer 2 domain. Thus, it is not the best choice here.

An access link configured as a trunk

Why it fails: An access link is intended to carry traffic for a single VLAN and typically connects an endpoint device, not another switch. Configuring it as a trunk is contradictory because a trunk carries multiple VLANs. Using an access link between switches would not allow multiple VLANs to traverse the link, so it does not meet the goal of transparent Layer 2 connectivity across both switches.