Practice Test #4

Incorrect. The primary route should have the lower administrative distance so it is preferred during normal operation. If you make the primary route’s AD higher than the backup, the router will prefer the backup route all the time (assuming equal prefix length), defeating the purpose of a floating static route.

Incorrect. default-information originate is used within routing protocols (like OSPF/EIGRP) to advertise a default route to neighbors. It does not control whether a locally configured static route is installed as primary or backup. Floating static route behavior is determined by administrative distance and route availability.

Incorrect. A lower administrative distance makes a route more preferred, not a backup. If the floating static route had a lower AD than the primary route (same prefix length), it would be installed and used even when the primary route is healthy, so it would not “float.”

DUAL (Diffusing Update Algorithm) is EIGRP’s internal algorithm for computing loop-free paths and feasible successors. It helps EIGRP converge quickly and select routes within EIGRP. However, it is not a router-wide attribute used to choose between routes learned from different routing protocols. Therefore it cannot be the deciding factor when comparing, for example, OSPF vs RIP routes.

A metric is used to choose the best path within the same routing protocol (e.g., OSPF cost, EIGRP composite metric, RIP hop count). Metrics are not directly comparable between different protocols because each protocol defines and calculates its metric differently. When routes come from different routing protocols, the router does not compare their metrics; it compares administrative distance first.

Hop count is specifically the metric used by RIP (and is limited to 15 hops). It is not a universal attribute used by all routing protocols, and it is not used to compare routes from different protocols. A router would only consider hop count when comparing multiple RIP routes to the same destination, after RIP has already been selected via administrative distance.

Incorrect. Telnet is an insecure, legacy remote-access protocol and is not a defining characteristic of controller-based networks. Controller-based designs emphasize centralized management and API-driven automation, typically using secure protocols (SSH, HTTPS/REST, NETCONF over SSH, etc.). “Reporting system issues” is more related to logging/telemetry (syslog, SNMP, streaming telemetry) than Telnet.

Incorrect as a characteristic. Administrators can often still use CLI on individual devices in many environments, but that is not what defines a controller-based network. The key distinction is centralized control and policy/intent delivered via the controller, usually through APIs and automation workflows. Relying on per-device CLI changes is more aligned with traditional device-by-device management.

Incorrect. Decentralizing the control plane so each device makes its own control decisions describes traditional distributed networking (e.g., each router runs OSPF/EIGRP and builds its own view). In controller-based networking, the control plane is logically centralized at the controller, while forwarding remains distributed on devices.

Incorrect. While DNA Center has multiple packages/licensing tiers and can be deployed in different sizes (appliance/cluster), “modular design allowing different versions” is not the key differentiator versus traditional NMS. The exam-relevant distinction is intent/policy abstraction and automation rather than a modular versioning model tailored per organization.

Incorrect. DNA Center supports discovery and onboarding in both greenfield and brownfield environments. It can discover existing devices, import them, and then bring them under management (inventory, assurance, provisioning). Limiting it to greenfield-only auto-discovery is false and not aligned with how enterprises adopt DNA Center incrementally.

Incorrect. DNA Center does support high availability and scale through clustering (multiple nodes) depending on the deployment model. While HA design details can vary by version and platform, the statement that it “omits support” for HA in cluster mode is the opposite of DNA Center’s enterprise design goals.

Overlay is not an API; it is a logical/virtual network built on top of another network (the underlay). Examples include VXLAN overlays in data centers or SD-WAN tunnels across the Internet/MPLS. While controllers often manage overlays, “overlay” describes a forwarding/encapsulation design layer, not the interface used to communicate with edge devices.

Northbound APIs are used by applications and automation systems to interact with the controller (for example, to request network services, query topology, or apply intent/policy). They expose controller capabilities “upward” to orchestration and business/IT apps. Northbound is not the controller-to-device interface, so it is incorrect for interacting directly with edge devices.

Underlay is also not an API; it is the physical or base IP network that provides transport for an overlay (routing, switching, links, and core connectivity). Controllers may monitor or configure the underlay, but the term itself refers to the foundational network layer, not the controller interface used to program edge devices.

Incorrect. DHCP does not assign IP addresses permanently by default; it leases them for a defined duration. Clients are expected to renew their leases (T1/T2 timers) to keep using the address. Permanent assignment is achieved via static configuration or DHCP reservations, not by “no renewal required.”

Incorrect as stated. DHCP can provide DNS server information via option 6, and multiple DNS servers can be supplied, but “up to four” is not a standard defining role of DHCP and is not universally true across implementations. The key role is providing configuration parameters, not a specific fixed limit.

Incorrect. The DHCP client does not maintain a pool of addresses to assign; that is the DHCP server’s function. Clients request configuration and accept a lease from a server. Confusing client and server roles is a common exam trap.

10.10.1.0 255.255.255.240 is 10.10.1.0/28. A /28 has a block size of 16 in the last octet, so this route covers 10.10.1.0 through 10.10.1.15. The destination 10.10.1.22 is outside that range, so this route is not a match and cannot be selected.

10.10.1.16 255.255.255.252 is 10.10.1.16/30. This subnet covers 10.10.1.16–10.10.1.19. The destination 10.10.1.22 is not in that interval, so the router will not use this route for 10.10.1.22 even though it is a valid static route.

10.10.1.20 255.255.255.254 is 10.10.1.20/31. A /31 includes exactly two addresses: 10.10.1.20 and 10.10.1.21. It is commonly used on point-to-point links. Because 10.10.1.22 is not one of the two addresses in this /31, the route does not match.

Incorrect. Private addressing does not inherently reduce the size of router forwarding tables. Forwarding table size depends on the number of routes learned and how well routes are summarized/aggregated, not whether the prefixes are public or private. An enterprise can still have many internal routes, and Internet routing tables remain large regardless of RFC 1918 usage.

Incorrect. Private IPv4 addresses are not globally routable, so they cannot be used to communicate across the public Internet to other private networks by default. To connect private networks over the Internet, you typically use VPNs (IPsec/SSL), tunneling/overlays, or NAT with carefully coordinated addressing—private addressing alone does not enable this.

Incorrect. Private addressing by itself does not allow servers/workstations to communicate across public network boundaries (like the Internet). Because RFC 1918 addresses are not routed publicly, you need NAT/PAT for outbound access and additional mechanisms (static NAT, reverse proxy, VPN) for inbound or site-to-site connectivity. The statement implies routability that private addressing does not provide.

NAT is commonly deployed together with private IPv4 addressing, but it is not one of the best underlying reasons to use private space. NAT is a translation mechanism used because private addresses are not publicly routable, not the original purpose of RFC 1918 addressing. In other words, private addressing often leads to a need for NAT at the edge, but 'to implement NAT' reverses the cause-and-effect relationship. CCNA exams typically treat NAT as a consequence or companion technology rather than the primary reason for choosing private space.

Application connectivity is not a specific reason to choose private IPv4 space. Applications can communicate over either public or private IP addressing as long as routing, name resolution, and security policies are configured correctly. Private addressing does not inherently make applications connect better or more efficiently. Therefore this option is too generic and not tied to the purpose of RFC 1918 space.

Using private IPv4 addresses does not inherently manage or reduce routing overhead. Routing overhead depends on topology, route summarization, protocol design, hierarchy, and administrative choices rather than whether addresses are public or private. A poorly designed private network can have just as much routing complexity as a public-addressed one. This makes the option technically misleading and not a best reason for private address use.