Pass Cisco 200-301 Exam in First Attempt Guaranteed!

HSRP exists to avoid forcing clients to change their configured default gateway after an upstream router failure. The hosts reference the virtual gateway address rather than the individual physical address of whichever router is active. Manual client reconfiguration would defeat the protocol's purpose and is unnecessary under the stated healthy standby assumptions. Only troubleshooting a separately broken virtual group or network design would require host changes.

An HSRP role election does not erase router startup configurations or invoke a factory reset. Losing power on R1 causes it to stop participating; R2 reacts after the appropriate failure-detection interval. The surviving router retains its operating configuration and can take the active role for the shared gateway. Erasing configuration would destroy the redundancy design rather than provide normal failover behavior.

The surviving router should continue Layer 3 forwarding on behalf of the virtual gateway when HSRP promotes it to active. Disabling IP routing on R2 would break the host-to-remote-network path that the redundancy mechanism is meant to preserve. Split-brain prevention and active/standby coordination use HSRP state exchanges and priority rules, not a general shutdown of routing on the healthy standby device.

The on channel-group mode forces a static EtherChannel without exchanging LACP protocol messages. It can bundle interfaces when both ends are explicitly configured compatibly, but the question requires active negotiation under the IEEE Link Aggregation Control Protocol. Choosing on would remove the very handshake the operator wants to initiate and can produce a misconfigured or unidirectional bundle if the peer disagrees.

desirable is a Port Aggregation Protocol negotiation setting, historically associated with Cisco PAgP rather than IEEE LACP. It may be useful on a supported PAgP design, but will not initiate the requested IEEE LACP negotiation with an LACP-configured peer. Select active for LACP when this side must start the negotiation, and avoid mixing protocol modes across the two switch endpoints.

switchport mode controls Ethernet switching roles such as access, trunk or applicable dynamic trunking modes; active is not the normal switchport mode keyword for forming an LACP channel. EtherChannel negotiation is set under channel-group on the member interface. Even if an interface were already trunking, that alone would not place it into port-channel group 7 or cause LACP packets to be exchanged.

RIP-learned networks normally display an R routing code in Cisco IOS, not the leading L shown in the question. RIP might separately provide a route to another destination, but it would not create an L /32 host entry for the router's own assigned interface address. Inspect both the route code and the associated interface to distinguish local ownership from a dynamically advertised network prefix.

A MAC address table is a Layer 2 forwarding structure, generally containing VLAN identifiers, learned Ethernet MAC addresses, and ingress/egress switchports. The displayed entry has a dotted-decimal IPv4 address, a /32 prefix, and appears inside show ip route, so it belongs to Layer 3 routing information. Treating it as a MAC table record confuses two different forwarding information bases.

An equal-cost multipath group would indicate multiple eligible forwarding next hops for a shared destination, and operational output would identify those next-hop paths. The single L 192.0.2.17/32 entry is a local host-address route; it does not describe several load-balanced links. A connected C /24 may coexist with this L /32, but that distinction concerns address ownership and subnet reachability, not ECMP.

Ordinary Ethernet bridges are designed to handle destinations not yet present in their MAC forwarding tables. They generally flood an unknown unicast within the VLAN rather than dropping it immediately, because the target may be reachable on a different port. Special security configurations can suppress unknown unicast, but the scenario asks for normal switching behavior without such policy restrictions. Dropping every unfamiliar destination would prevent initial communication in many LANs.

The switch's source-learning process records where the sender's MAC was seen; that does not reveal where the unknown destination lives. Forwarding the received frame only back toward the source's learned port would usually return it to the sender and fail delivery. Known-unicast forwarding uses a MAC-table entry for the DESTINATION, whereas unknown destinations are flooded inside the allowed VLAN domain until learned.

VLANs define separate Layer 2 forwarding domains and prevent one VLAN's ordinary traffic from being flooded into others. An unknown destination in VLAN 20 should not trigger copies in VLANs 10, 30, or every trunk's unrelated tags. The switch floods only through eligible forwarding interfaces carrying the frame's own VLAN, according to trunk/access membership and spanning-tree state. Sending across all VLANs would break segmentation.

An open WLAN would remove authentication or encryption, creating an unnecessary wireless security regression while leaving the actual discoverability setting unchanged. Clients already connect successfully when the exact SSID is typed, so the authentication system and data path appear functional. The symptom is that normal scans do not show the network because broadcast is disabled. Keep the intended WPA protection and fix SSID advertising rather than turning the WLAN into an unsecured service.

A WLAN client VLAN governs the Layer 2 network where associated user traffic is carried, while the controller management VLAN carries administrative/control-plane traffic. Moving all clients to the management VLAN could create security and addressing problems, but it does not enable SSID broadcast. Because manually configured clients can already join the secured WLAN, the current data mapping is not the evidence of a discovery failure. Fix the general WLAN visibility setting.

A trunk native VLAN controls classification of untagged Ethernet frames on a wired trunk and has no direct role in whether the WLAN sends its SSID in normal radio discovery advertisements. Forcing every switch trunk to VLAN 1 might break intended segmentation and carries no relationship to the disabled Broadcast SSID checkbox. The relevant change is in the controller WLAN's general radio-advertising settings, not a blanket campus trunk change.

In JSON, a string value must be enclosed in double quotes, as in "up":"true". The supplied document instead uses the unquoted literal true, which has a distinct JSON data type. Strings are suitable for human-readable names such as "hostname":"sw-1", but converting a true/false state to text would cause type-sensitive clients or schema validators to behave differently from the indicated API response.

A JSON array is written with square brackets, such as "interfaces":["Gi0/1","Gi0/2"], and contains an ordered sequence of values. The up member is followed by the scalar literal true, not brackets or a sequence. Although a network API may represent multiple interfaces or clients with arrays elsewhere, this member is a single yes/no state and should be parsed as a boolean.

JSON uses the separate literal null when a field deliberately has no value. That is not equivalent to true: the latter is a known positive boolean state, while null generally indicates absence or unknown data depending on the API contract. In the supplied reply, the up member explicitly conveys a true state, so interpreting it as null would discard useful monitoring information.

Classification identifies which packets belong to a traffic class, such as trusted-marked voice, using protocol fields, DSCP values or configured matching rules. It is a prerequisite for choosing a priority class, but classification alone does not transmit packets in an order when the output link is congested. The scenario asks which function decides servicing order after traffic has already been recognized, so the answer lies in queue selection and scheduler behavior.

Marking writes or changes QoS metadata, such as a DSCP or Layer 2 CoS field, so downstream nodes can identify classes consistently. The question says voice frames have already been recognized from trusted marking. Marking therefore supplies classification information but does not directly decide whether a waiting voice packet leaves before a queued data packet. That decision occurs in the interface's output queuing and scheduling policy.

Traffic shaping buffers or paces traffic to fit a configured rate, smoothing bursts and limiting offered load over time. It can influence congestion behavior, but the described requirement is specifically a low-latency priority queue that chooses which class is served next on the egress interface. Shaping alone does not establish strict or weighted voice priority relative to other queued classes at transmission time.

OSPF path cost is a metric for selecting a preferred route within the protocol, and a smaller accumulated cost is more desirable, other things equal. Selecting cost 42 merely because it is numerically larger reverses the OSPF preference logic. In a design with policy or topology changes the higher-cost path might become relevant after failure of the lower-cost one, but under the stated normal comparison cost 18 wins.

Equal-cost multipath requires eligible routes to the same prefix with equal relevant routing metrics; matching administrative distances alone is not enough. Here both routes have OSPF distance 110 but their total costs differ significantly at 18 and 42. The lower-cost path is the normal selected route rather than distributing traffic equally across both. The AD value determines protocol-source trust, not OSPF ECMP eligibility by itself.

OSPF is explicitly built to learn the same destination from multiple neighbors and calculate which route is preferred from topology and cost. This redundancy enables convergence after a link or router failure rather than invalidating the prefix. The case states that both neighbors offer valid routes to 198.51.100.0/24. Discarding both merely because they describe the same subnet would contradict basic link-state path selection.

An uplink's physical bandwidth may affect spanning-tree path cost calculations when choosing root ports and forwarding paths, but it does not break a TIE in the root bridge's Bridge ID when switch priorities are equal. Bridge IDs are compared by priority and then MAC address. The higher-bandwidth link could affect a later root-port decision after a root is known, but it is not the root-bridge identity tie-breaker.

The number of VLANs configured on a switch does not form part of the spanning-tree Bridge ID comparison for a specific VLAN instance. A device with many VLANs may still lose the root election to another device with an equal priority but lower bridge MAC. Administrative root placement should use intentional priority values where possible, rather than assuming the most broadly configured switch will be elected.

Spanning-tree Bridge ID comparisons do not include the timestamp of the most recent reboot. A switch returning to service can participate in the election using its current bridge priority and MAC address, even if it booted later than peers. Boot history might affect when control-plane convergence happens, but not the deterministic priority/MAC ordering used for deciding the root under equal effective priorities.

The default gateway is used when a host sends an IP packet to an off-subnet destination; it is not an obligatory waypoint for every same-VLAN Ethernet frame. In this scenario the workstation and printer share a local Layer 2 domain, and the switch already knows the destination MAC. Sending the frame to a router would add unnecessary Layer 3 forwarding and would not describe the requested known-unicast switching action.

An IPv4 TTL field limits how many routed hops an IP packet can traverse; routers decrement it during forwarding. The Ethernet switch needs to choose an egress port for a frame with a known destination MAC, a function determined by its MAC forwarding table rather than TTL. The switch could even forward non-IP Ethernet frames within the VLAN using MAC learning, illustrating why IP TTL is unrelated.

Flooding every frame across all VLANs would defeat VLAN separation and waste bandwidth. A conventional learning switch only floods specific categories, such as unknown unicast or broadcasts, within the frame's own VLAN, subject to port state and policy. The stem says the destination MAC is known, so the switch can send to the learned egress instead of flooding; other VLANs are independent broadcast domains.

An attacker interested in stealing configuration secrets is a threat actor with a possible harmful objective. Their interest or capability does not alone establish that a vulnerable service has been triggered or that an exploit has occurred. The question asks for an actual action that uses a weakness to produce unintended behavior. A threat actor may initiate an exploit, but the two terms describe different elements of a security incident.

An old, unchanged administrative password can be a vulnerability because it may be weak, reused, leaked, or poorly managed. The weakness increases the attack surface but is not itself the act of exploiting it. An exploit would involve a technique that leverages such a weakness, such as unauthorized credential use. The scenario's distinguishing requirement is behavior that directly triggers unintended execution on the router.

A patch that removes a router flaw is a mitigation or remediation action intended to reduce the likelihood that an attacker can exploit the vulnerability. Applying a patch is generally beneficial and is not an attack technique. The question asks which example is an exploit, so an action that closes the weakness cannot meet it. Review patch deployment separately from attack execution and detection.