Cisco 350-401: Implementing and Operating Cisco Enterprise Network Core Technologies (ENCOR)

Incorrect. "logging synchronous" is not a global configuration command in Cisco IOS; it is entered under line configuration mode such as "line console 0" or "line vty 0 4". Because the option explicitly says global configuration command, it is technically invalid. Even though the feature itself is relevant, the command context given in the option makes this answer wrong. Cisco certification questions often test exact command mode syntax, so this distinction matters.

Incorrect. The command "terminal length" changes the number of lines displayed before paging occurs with a --More-- prompt. It affects the presentation of command output such as show commands, but it does not control asynchronous debug or syslog messages arriving while the user is typing. Therefore it does not reduce command-line interruption in the way the question asks. It is useful for output navigation, not for protecting interactive input.

Incorrect. The logging delimiter feature may improve readability by visually separating messages, but it does not stop those messages from interrupting the command line. The administrator can still have keystrokes mixed with unsolicited output, which is the real operational problem here. It is a formatting aid rather than a mechanism for preserving typed commands. As a result, it does not directly minimize the possibility of typing commands incorrectly.

Transmit power is the RF output level at the transmitter (often in dBm or mW). While increasing transmit power can improve the received signal (RSSI) under some conditions, it is not directly used to compute SNR. SNR is calculated at the receiver using the received signal level and the measured noise floor, regardless of what transmit power was configured.

EIRP (Effective Isotropic Radiated Power) represents the transmitter’s effective radiated power after accounting for antenna gain and losses, and is important for coverage planning and regulatory compliance. However, EIRP is not required to compute SNR. SNR is derived from what the receiver measures (RSSI and noise floor), not from transmitter-side calculated values.

Antenna gain describes how an antenna focuses energy in certain directions relative to an isotropic radiator, affecting coverage and potentially the received signal level. While antenna gain influences link budget and can indirectly affect RSSI, it is not an input needed to compute SNR once RSSI and noise floor are known. SNR is strictly based on receiver measurements.

Automation backup is a recommended pre-upgrade precaution to protect configuration, inventory, and automation artifacts. However, it is not inherently a required step to perform the upgrade itself. Cisco DNA Center upgrades can proceed without an automation backup (though it is strongly advised), so it does not match the question’s “required for a complete upgrade” phrasing.

Golden image selection relates to Cisco DNA Center SWIM (Software Image Management) for network devices, where you choose a “golden” IOS-XE image for compliance and distribution. It is not part of upgrading the Cisco DNA Center appliance/cluster itself, so it is not required for a Cisco DNA Center upgrade.

Proxy configuration is only necessary if the Cisco DNA Center cluster requires a proxy to reach Cisco cloud resources or repositories to download upgrade packages. Many deployments use direct internet access or offline/manual package upload. Because it is environment-dependent, it is not a universally required step for a complete upgrade.

LED lights can emit electromagnetic noise in some cases, especially if they use poor-quality drivers or switching power supplies, but they are not typically identified as one of the most common Wi-Fi interference sources in Cisco certification questions. They are more of an edge-case environmental issue than a standard exam answer. When compared with radar and rogue APs, LED lights are the less defensible choice. For exam purposes, they are not usually considered a primary common interferer.

Fire alarm systems are not generally considered common sources of Wi-Fi interference. While any electronic system could theoretically emit noise if malfunctioning, fire alarms are not standard examples of devices that disrupt 2.4 GHz or 5 GHz WLANs. Cisco exams usually focus on more established interferers such as radar, microwave ovens, Bluetooth devices, or other access points. Therefore this option is not a correct choice.

A conventional oven is not a common Wi-Fi interference source. The classic appliance associated with Wi-Fi disruption is a microwave oven, which leaks energy around 2.45 GHz and can interfere with 2.4 GHz WLANs. A conventional oven does not operate using the same RF mechanism and is not typically cited in wireless troubleshooting references. This makes it an incorrect option in the context of common Wi-Fi interferers.

Incorrect. Upgrading the standby router first does not make the transition nondisruptive because HSRP version 1 and version 2 are not interoperable as a single stable group during the change. The routers will not maintain seamless adjacency across the version mismatch, so some reinitialization behavior is expected. Therefore, saying that no changes occur is technically wrong. The order of upgrade may help operational planning, but it does not eliminate the protocol impact.

Incorrect. HSRP version 1 and version 2 do not use the same virtual MAC OUI and format. HSRP v1 uses the 0000.0c07.acxx pattern, while HSRP v2 uses 0000.0c9f.fxxx. Since the virtual MAC changes, hosts and switches must relearn the gateway MAC information. That means a version change does not occur transparently.

Incorrect as the best answer. It is true that HSRP v1 and v2 use different multicast addresses for hello packets, and mixed versions will not exchange hellos normally. However, the question asks what behavior can be expected when the version is changed, and the standard expected behavior is that each group reinitializes because the virtual MAC address changes. The multicast difference explains lack of interoperability during mismatch, but it is not the best match to the behavior being tested here. On Cisco exams, the virtual MAC change is the more direct and canonical reason tied to HSRP group reinitialization.

ICMP jitter is based on ICMP echo-style probing and can be performed without configuring an IP SLA responder because ICMP Echo Reply is a standard network function on most IP devices. While it can provide delay variation estimates, it does not require a specialized responder process on the far end in the way UDP jitter does for structured measurement and reporting.

TCP connect measures the time to establish a TCP session (SYN, SYN-ACK, ACK) to a destination port. Because it uses the normal TCP stack behavior of the remote host (a service listening on that port), it does not require an IP SLA responder. The remote endpoint simply needs to allow/accept the TCP connection attempt for meaningful results.

ICMP echo is a one-ended IP SLA operation that sends ICMP Echo Requests and measures the time until ICMP Echo Replies are received. Since ICMP echo/reply is a standard capability on routers, switches, and hosts (unless blocked), no IP SLA responder configuration is required on the remote end. This makes it simple but less feature-rich than responder-based tests.

Incorrect. TLS is not used for plain HTTP; HTTP is unencrypted and has no TLS handshake. TLS is used to secure HTTP by creating HTTPS (HTTP over TLS). RESTCONF can technically run over HTTP, but secure configuration operations in enterprise networks should use HTTPS, not HTTP.

Incorrect. RESTCONF on Cisco devices does not require NGINX or any external reverse proxy to provide TLS. While a proxy could be used in some architectures (API gateways, load balancers), Cisco platforms commonly terminate TLS directly on the device’s HTTPS/RESTCONF service.

Incorrect. Cisco enterprise devices that support RESTCONF typically support HTTPS/TLS as well. RESTCONF is designed to operate over HTTP/HTTPS, and Cisco implementations commonly recommend HTTPS for secure management. Therefore, stating TLS is not supported on Cisco devices is false.

Local mode is the classic lightweight AP mode where APs join a Cisco WLC using CAPWAP. It provides centralized control, RF management, and policy enforcement, but typically the controller is a dedicated WLC (often centralized). It can be used for branches, yet it doesn’t inherently imply local management at each small branch unless you deploy a WLC per site.

Autonomous APs are managed locally on each AP and do not require a controller. However, they do not use CAPWAP; CAPWAP is specific to lightweight/controller-based deployments. Autonomous is therefore incompatible with the requirement to use CAPWAP, even though it matches the “local management” idea at a high level.

SD-Access wireless integrates wireless into the SD-Access fabric, leveraging DNA Center and controller-based wireless (CAPWAP to WLC) with fabric concepts like VXLAN and SGT-based policy. It is aimed at campus/enterprise architectures rather than small-branch local management. It adds complexity and dependencies that don’t match the stated small-branch CAPWAP local-management requirement.

Privilege level 7 is not a default for VTY access. It could be assigned only if explicitly configured (for example, "line vty ... privilege level 7") or via AAA/username privilege settings. Nothing in the provided configuration assigns level 7 to VTY sessions.

Privilege level 13 is also not a default. Higher privilege levels (2–14) are typically used for custom role/command sets and must be explicitly assigned via line configuration or AAA authorization/username privilege. The exhibit shows no such configuration for VTY lines.

Privilege level 15 would apply if the VTY lines had "privilege level 15" configured, or if AAA exec authorization/username privilege granted it. In the exhibit, only console and AUX lines have privilege level 15 configured; VTY lines do not, so they default to level 1.

Incorrect. The value 7.61 corresponds to bios_ver_str, not kickstart_ver_str. The code does not reference the BIOS version field anywhere in the print statement. Therefore, this value would only be printed if the code accessed response['ins_api']['outputs']['output']['body']['bios_ver_str'] instead.

Incorrect. The script explicitly includes import json at the top, so json.dumps(payload) is valid. A NameError for json would occur only if the module were not imported or if the name had been overwritten later in the script, neither of which is shown. Therefore, this option is not supported by the exhibit.

Incorrect. The key kickstart_ver_str is present exactly under ins_api -> outputs -> output -> body in the provided JSON. Because the dictionary path in the code matches the response structure precisely, Python does not raise a KeyError. This distractor relies on a common concern about NX-API structural variations, but the exhibit itself shows a valid direct match.

This option places the permit for the full range 22 through 443 before the deny for port 80, which breaks the intended logic. Because port 80 falls inside the permitted range, packets to port 80 match the first statement and are allowed immediately. The later deny is never evaluated for those packets due to first-match ACL behavior. As a result, port 80 is not excluded, so the ACL does not meet the requirement.

This option permits only TCP traffic with destination port 80, which is the exact opposite of the requirement to exclude port 80. It does not allow the broader destination port range of 22 through 443, so valid traffic to ports such as 22, 443, or 3389 within the intended range would not be handled correctly. Because of the implicit deny at the end of the ACL, all other traffic would be blocked. Therefore this option clearly fails to implement the requested access policy.

HTTP method (GET, POST, PUT, etc.) is part of the request start-line and indicates the action to perform on a resource. It does not specify the media type of any payload. While some methods commonly include a body (POST/PUT/PATCH), the method itself never declares whether the body is JSON, XML, or another format; that is done via the Content-Type header.

The body contains the actual payload (for example, JSON text, HTML, or binary data). It does not inherently include standardized metadata fields like Content-Type. Although an application could embed type information inside the payload, HTTP’s defined mechanism for declaring the payload’s media type is the Content-Type header, which is separate from the body and precedes it.

The URI identifies the resource (path and optional query) being accessed, such as /api/items?id=10. While URIs sometimes include file extensions that hint at content (like .html), that is not the authoritative HTTP mechanism for payload typing. The formal declaration of the body’s media type is done with the Content-Type header, not the URI.

One exporter would only be sufficient if there were a single collector destination or some external abstraction explicitly presented, such as a load balancer or anycast VIP acting as one logical collector target. The question states there are two dual-stack NetFlow collectors, which in standard Flexible NetFlow design means two export destinations. Dual-stack capability does not merge two separate collectors into one exporter definition. Therefore, 1 is too few.

Four exporters would incorrectly assume that exporter count must be doubled for IPv4 and IPv6 traffic in addition to the two collectors. Flexible NetFlow does not require separate exporters for IPv4 flows and IPv6 flows when the same collector destination is used. The distinction between IPv4 and IPv6 is handled in the flow records and monitors, while exporters remain destination-based. As a result, 4 overstates the requirement.

Eight exporters is far beyond what is needed and reflects an incorrect multiplication of collectors, protocol families, or other factors such as interfaces or directions. Exporters are not created per interface, per direction, or per address family unless the design explicitly requires different destinations or transport settings. In this case, there are only two collector endpoints to send data to. Therefore, 8 is not justified by the scenario.

192.168.101.10 is not selected because its AS-path is longer than the path through 192.168.101.18. The path attribute shown is `64515 64515i`, which indicates AS 64515 has been prepended, giving it an AS-path length of 2. After the failed best path is removed, BGP compares the remaining eBGP candidates and prefers the shorter AS-path. Therefore, 192.168.101.18 is preferred over 192.168.101.10.

192.168.101.14 is not selected because it is an iBGP-learned route, indicated by the presence of a Local Preference value in the table. Although Local Preference is an important BGP attribute within an AS, Cisco best-path selection still prefers an eBGP path over an iBGP path when earlier comparisons among the remaining candidates do not make the iBGP route uniquely best in this context. The remaining eBGP routes are therefore preferred before this iBGP route. As a result, 192.168.101.14 does not become the active next hop.

192.168.101.6 is not selected because its AS-path is longer than the path through 192.168.101.18. The path shown is `64514 64514i`, which is an AS-path length of 2 because of prepending. While it also shows a MED of 80, MED is considered later and does not help it beat a shorter eBGP AS-path. Therefore, 192.168.101.18 remains the best remaining route.

“Over the DS” is one of the two 802.11r FT methods (FT over-the-air vs FT over-the-distribution-system). It affects how FT authentication frames are exchanged during roaming, not whether a non-FT client can associate to an SSID advertising FT. Legacy clients that fail due to FT IEs/AKMs will typically still fail regardless of over-the-DS selection.

802.11k provides radio resource measurements and neighbor reports to help clients discover nearby APs and roam more efficiently. It does not change the authentication/keying method and does not address clients that cannot connect because they do not support or mis-handle 802.11r FT. It’s complementary to 11r but not a compatibility mechanism.

802.11v adds network-assisted roaming features such as BSS Transition Management (steering) and other management enhancements. Like 802.11k, it can improve roaming decisions but does not modify the security handshake in a way that enables legacy clients to connect when 802.11r causes association/authentication issues. It’s not the selective FT-by-OUI feature.

2WAY/DROTHER is a broadcast multiaccess behavior where routers may stop at 2-Way with non-DR/BDR neighbors. However, this requires that neighbors at least successfully exchange matching hellos and reach 2-Way. Here, the hello/dead timers are mismatched (2s vs default 10s), so the routers will not form a stable neighbor relationship to reach 2-Way.

FULL adjacency would occur on a point-to-point link or between DR/BDR and others on a broadcast segment, but only after successful neighbor parameter negotiation. Because the hello/dead timers do not match, the routers will not become neighbors and cannot reach FULL. Different interface costs do not prevent FULL; timer mismatch does.

DR/BDR roles apply to broadcast and NBMA network types, and the state would be FULL/DR and FULL/BDR (not FULL/BDR on both). More importantly, DR/BDR election and FULL state require a working neighbor relationship first. With mismatched hello/dead timers, the routers will not establish adjacency, so DR/BDR states are not reached.

Incorrect. A true one-to-one NAT translation in the exam sense usually implies a fixed, permanent mapping (static NAT), configured with "ip nat inside source static". This configuration is dynamic NAT using a pool; mappings are allocated as needed and can change over time. While each active inside host may temporarily get one global address, it is not a guaranteed permanent one-to-one mapping.

Incorrect. The 209.165.201.0/27 network in the pool represents inside global addresses (public addresses used to represent inside hosts). “Outside local” refers to how an outside host’s address is represented inside the network (often only relevant with overlapping addressing or special NAT cases). Nothing here defines outside local addresses or an outside address range.

Incorrect. 10.1.1.0/27 is not the inside global range; it is the inside local range (private addresses). The inside global range is the public address space used to represent inside hosts externally, which in this configuration is the NAT pool 209.165.201.1–209.165.201.30 (within 209.165.201.0/27).

Point-to-multipoint and nonbroadcast are not a compatible pair because they use different OSPF operational models. Point-to-multipoint treats each neighbor as an individual point-to-point relationship and does not elect a DR or BDR. Nonbroadcast is a multiaccess type that does use DR/BDR election and usually requires manually configured neighbors. Because their adjacency expectations differ, this pairing is not the standard compatible combination.

Point-to-multipoint and broadcast are not considered compatible because point-to-multipoint does not use DR/BDR election, while broadcast does. Broadcast assumes a shared multiaccess segment with designated router behavior, but point-to-multipoint models the network as separate logical point-to-point links. These different assumptions can prevent proper adjacency formation. Therefore this is not the correct compatible pair.

Broadcast and point-to-point are not the correct compatible pair in OSPF network type matching. Broadcast networks expect DR/BDR election on a multiaccess segment, while point-to-point explicitly disables DR/BDR and assumes exactly one neighbor on the link. This mismatch in Hello semantics and adjacency behavior makes them unsuitable as the best answer. Cisco exam questions on network type compatibility typically expect matching multiaccess types together, which points to broadcast and nonbroadcast instead.

IPsec can encrypt and authenticate IP traffic, and in theory could protect NTP if you built tunnels between peers. However, this is not a typical or primary Cisco IOS NTP hardening mechanism and is rarely used solely for NTP. ENCOR-style questions usually focus on native NTP authentication plus traffic restriction rather than overlay security like IPsec.

IP prefix lists are used to match and filter IP routes (for example, in BGP/OSPF route filtering and redistribution policy). They do not filter or secure application traffic like NTP (UDP/123). While the term “prefix” relates to IP networks, it is not an NTP security control on Cisco devices.

TACACS+ is an AAA protocol used for authenticating and authorizing administrative access to network devices (login, exec, command authorization, accounting). It does not authenticate NTP servers or protect NTP time synchronization. It may be confused with “authentication” in general, but it is unrelated to NTP packet validation.