Security practice questions

A network engineer is configuring port security on a Cisco switch to prevent unauthorized devices from connecting. The requirement is to allow only the first two MAC addresses learned on an interface, and to disable the interface if a violation occurs. Which configuration achieves this?

Trap 1: switchport port-security maximum 2 switchport port-security…

The command 'switchport port-security violation err-disable' is invalid on Cisco IOS because the violation mode parameter only accepts the keywords 'shutdown', 'protect', or 'restrict'. The err-disable state is not a configurable mode; it is a condition that results from entering the 'shutdown' violation mode when an unauthorized MAC address appears. Therefore, this option would be rejected by the CLI and cannot be applied to the interface.

Trap 2: switchport port-security maximum 2 switchport port-security…

This option incorrectly uses the 'protect' violation mode, which does not disable the interface. When the configured maximum of 2 MAC addresses is exceeded, the port continues to operate normally for permitted addresses, and frames from unknown MAC addresses are silently dropped. Because the interface remains up and forwarding, it fails the explicit requirement that the port be disabled when a violation occurs.

Trap 3: switchport port-security maximum 2 switchport port-security…

The 'restrict' violation mode drops frames from unauthorized MAC addresses and increments a violation counter, but it does not place the port in an err-disabled state. Even after the maximum of 2 addresses is exceeded, the interface stays operational and continues forwarding traffic for the already-learned secure MAC addresses. This behavior does not meet the requirement to disable the interface, making the option incorrect.

A
switchport port-security maximum 2 switchport port-security violation err-disable
Why wrong: The command 'switchport port-security violation err-disable' is invalid on Cisco IOS because the violation mode parameter only accepts the keywords 'shutdown', 'protect', or 'restrict'. The err-disable state is not a configurable mode; it is a condition that results from entering the 'shutdown' violation mode when an unauthorized MAC address appears. Therefore, this option would be rejected by the CLI and cannot be applied to the interface.
B
switchport port-security maximum 2 switchport port-security violation shutdown
This is the correct configuration. It sets the maximum number of secure MAC addresses to 2 and also specifies the violation action as 'shutdown'. When a third MAC address attempts to use the port, the switch places the interface in an err-disabled state, which completely disables the port and blocks all traffic, satisfying the requirement to disable the interface upon a violation.
C
switchport port-security maximum 2 switchport port-security violation protect
Why wrong: This option incorrectly uses the 'protect' violation mode, which does not disable the interface. When the configured maximum of 2 MAC addresses is exceeded, the port continues to operate normally for permitted addresses, and frames from unknown MAC addresses are silently dropped. Because the interface remains up and forwarding, it fails the explicit requirement that the port be disabled when a violation occurs.
D
switchport port-security maximum 2 switchport port-security violation restrict
Why wrong: The 'restrict' violation mode drops frames from unauthorized MAC addresses and increments a violation counter, but it does not place the port in an err-disabled state. Even after the maximum of 2 addresses is exceeded, the interface stays operational and continues forwarding traffic for the already-learned secure MAC addresses. This behavior does not meet the requirement to disable the interface, making the option incorrect.

Study the full AAA explanation →

Question 2easymultiple choice

An organization wants to implement 802.1X authentication on its wired network using Cisco ISE as the authentication server. The switches are configured with the necessary RADIUS settings. Which additional configuration is required on the switch interfaces to enable 802.1X?

Trap 1: dot1x pae authenticator

The command sets the Port Access Entity (PAE) role to authenticator, which is necessary for the switch to act as the 802.1X authenticator, but it does not actually enable port-based authentication on the interface. Without 'authentication port-control auto', the port remains in its default state (force-authorized), so the command alone does not enforce 802.1X. It is a prerequisite, not the enabling command.

Trap 2: authentication port-control force-authorized

This command disables 802.1X on the port by forcing it to the authorized state without requiring any authentication. All traffic is allowed without checking credentials, which defeats the purpose of 802.1X. It is the default for ports that do not have authentication configured, making it the opposite of what is needed.

Trap 3: authentication port-control force-unauthorized

This command forces the port to an unauthorized state, blocking all traffic regardless of authentication. While it does restrict access, it does not allow for any authentication process to succeed, so it cannot be used to implement 802.1X. It would shut down the port completely, not provide the dynamic authentication behavior required.

A
dot1x pae authenticator
Why wrong: The command sets the Port Access Entity (PAE) role to authenticator, which is necessary for the switch to act as the 802.1X authenticator, but it does not actually enable port-based authentication on the interface. Without 'authentication port-control auto', the port remains in its default state (force-authorized), so the command alone does not enforce 802.1X. It is a prerequisite, not the enabling command.
B
authentication port-control auto
This command sets the port's authentication mode to auto, meaning the port will be unauthorized until the client successfully authenticates via 802.1X. It triggers the authentication process and is the required command to enable 802.1X on an interface. This is the correct answer because it directly controls the port's state based on authentication.
C
authentication port-control force-authorized
Why wrong: This command disables 802.1X on the port by forcing it to the authorized state without requiring any authentication. All traffic is allowed without checking credentials, which defeats the purpose of 802.1X. It is the default for ports that do not have authentication configured, making it the opposite of what is needed.
D
authentication port-control force-unauthorized
Why wrong: This command forces the port to an unauthorized state, blocking all traffic regardless of authentication. While it does restrict access, it does not allow for any authentication process to succeed, so it cannot be used to implement 802.1X. It would shut down the port completely, not provide the dynamic authentication behavior required.

Study the full ACL explanation →

Question 3hardmultiple choice

A security engineer is configuring CoPP (Control Plane Policing) on a Cisco router to protect the control plane from DoS attacks. The policy must rate-limit SSH traffic to 1 Mbps with a burst of 2000 bytes, and drop all other traffic destined to the control plane that exceeds a default rate. Which class-map and policy-map configuration is correct?

Trap 1: class-map match-all SSH match protocol ssh policy-map COPP class…

This configuration correctly matches SSH using `match protocol ssh`, but it omits a `class-default` definition. Without `class-default`, all non-SSH control-plane traffic (e.g., ARP, OSPF, BGP, ICMP) is implicitly forwarded to the CPU with no policing, leaving the control plane unprotected. A complete CoPP policy must include a `class-default` to apply a baseline police rate to all unclassified traffic.

Trap 2: class-map match-all SSH match access-group name SSH_ACL policy-map…

Using an `access-group` for classification is valid in CoPP, but this configuration references a named ACL `SSH_ACL` that is not defined anywhere in the snippet, making the class-map effectively non-functional until the ACL is created. Additionally, matching by protocol (`match protocol ssh`) is simpler and does not rely on ACL semantics or ordering. Although `class-default` with a police rate is present, the incomplete ACL dependency and the less direct classification method make this option incorrect.

Trap 3: class-map match-all SSH match protocol ssh policy-map COPP class…

The police command parameters are swapped: `police 2000 1000000` sets the rate to 2000 bps and the burst to 1,000,000 bytes, the exact inverse of the intended configuration. This would rate-limit SSH to an unusably low speed while allowing an enormous burst, defeating the purpose of CoPP. Correct syntax should be `police 1000000 2000`, where the first value is the committed information rate in bits per second and the second is the burst size in bytes.

A
class-map match-all SSH match protocol ssh policy-map COPP class SSH police 1000000 2000 conform-action transmit exceed-action drop
Why wrong: This configuration correctly matches SSH using `match protocol ssh`, but it omits a `class-default` definition. Without `class-default`, all non-SSH control-plane traffic (e.g., ARP, OSPF, BGP, ICMP) is implicitly forwarded to the CPU with no policing, leaving the control plane unprotected. A complete CoPP policy must include a `class-default` to apply a baseline police rate to all unclassified traffic.
B
class-map match-all SSH match access-group name SSH_ACL policy-map COPP class SSH police 1000000 2000 conform-action transmit exceed-action drop class class-default police 8000 conform-action transmit exceed-action drop
Why wrong: Using an `access-group` for classification is valid in CoPP, but this configuration references a named ACL `SSH_ACL` that is not defined anywhere in the snippet, making the class-map effectively non-functional until the ACL is created. Additionally, matching by protocol (`match protocol ssh`) is simpler and does not rely on ACL semantics or ordering. Although `class-default` with a police rate is present, the incomplete ACL dependency and the less direct classification method make this option incorrect.
C
class-map match-all SSH match protocol ssh policy-map COPP class SSH police 1000000 2000 conform-action transmit exceed-action drop class class-default police 8000 conform-action transmit exceed-action drop
This is the correct CoPP configuration: `class-map match-all SSH` with `match protocol ssh` classifies SSH control-plane traffic, and the policy map `COPP` applies a police rate of 1,000,000 bps with a burst of 2000 bytes, dropping exceeding traffic. The `class-default` then polices all other control-plane traffic at 8000 bps, ensuring that no unclassified protocol can flood the CPU. The syntax and parameters are correctly ordered (rate in bps, burst in bytes), providing comprehensive control-plane protection.
D
class-map match-all SSH match protocol ssh policy-map COPP class SSH police 2000 1000000 conform-action transmit exceed-action drop
Why wrong: The police command parameters are swapped: `police 2000 1000000` sets the rate to 2000 bps and the burst to 1,000,000 bytes, the exact inverse of the intended configuration. This would rate-limit SSH to an unusably low speed while allowing an enormous burst, defeating the purpose of CoPP. Correct syntax should be `police 1000000 2000`, where the first value is the committed information rate in bits per second and the second is the burst size in bytes.

Question 4mediummultiple choice

A company has deployed a Cisco ASA firewall in transparent mode. The internal network uses VLAN 10 and the external network uses VLAN 20. The ASA is configured with two bridge groups: BVI 10 for inside and BVI 20 for outside. The security policy must allow HTTPS traffic from inside to outside. Which access-list entry is correct?

Trap 1: access-list INSIDE extended permit tcp 192.168.1.0 255.255.255.0…

This command fails because transparent (Layer 2) firewall mode does not support interface-specific access-groups. The ASA bridges traffic, not routes it, so an ACL applied with 'access-group ... in interface inside' is not evaluated for bridged traffic. Instead, only the global access-list, configured as 'access-list GLOBAL' and applied with 'access-group GLOBAL in global', is used to filter all traffic traversing the bridge, regardless of ingress or egress interface.

Trap 2: access-list GLOBAL extended permit ip 192.168.1.0 255.255.255.0 any

This global access-list is too broad because it permits all IP protocols (TCP, UDP, ICMP, IPsec, etc.) from the 192.168.1.0/24 subnet to any destination, not just HTTPS. The stated requirement is to allow only outbound HTTPS (TCP 443) traffic, so this rule would over-permit by allowing every IP service from the inside network. In transparent mode, the global ACL applies to all bridged traffic, making this rule even more dangerous as it would open the entire internal network to any destination.

Trap 3: access-list GLOBAL extended permit tcp any any eq 443

This global access-list incorrectly specifies 'any' as the source, which would permit HTTPS traffic from any IP address, including untrusted outside networks and other internal segments. Although it restricts the service to TCP 443, it fails to limit the source to the inside subnet 192.168.1.0/24 as required. Since transparent-mode global ACLs apply to all bridged traffic regardless of interface, this rule would allow external hosts to reach any destination on port 443, violating the explicit source restriction in the security policy.

A
access-list INSIDE extended permit tcp 192.168.1.0 255.255.255.0 any eq 443 access-group INSIDE in interface inside
Why wrong: This command fails because transparent (Layer 2) firewall mode does not support interface-specific access-groups. The ASA bridges traffic, not routes it, so an ACL applied with 'access-group ... in interface inside' is not evaluated for bridged traffic. Instead, only the global access-list, configured as 'access-list GLOBAL' and applied with 'access-group GLOBAL in global', is used to filter all traffic traversing the bridge, regardless of ingress or egress interface.
B
access-list GLOBAL extended permit ip 192.168.1.0 255.255.255.0 any
Why wrong: This global access-list is too broad because it permits all IP protocols (TCP, UDP, ICMP, IPsec, etc.) from the 192.168.1.0/24 subnet to any destination, not just HTTPS. The stated requirement is to allow only outbound HTTPS (TCP 443) traffic, so this rule would over-permit by allowing every IP service from the inside network. In transparent mode, the global ACL applies to all bridged traffic, making this rule even more dangerous as it would open the entire internal network to any destination.
C
access-list GLOBAL extended permit tcp any any eq 443
Why wrong: This global access-list incorrectly specifies 'any' as the source, which would permit HTTPS traffic from any IP address, including untrusted outside networks and other internal segments. Although it restricts the service to TCP 443, it fails to limit the source to the inside subnet 192.168.1.0/24 as required. Since transparent-mode global ACLs apply to all bridged traffic regardless of interface, this rule would allow external hosts to reach any destination on port 443, violating the explicit source restriction in the security policy.
D
access-list GLOBAL extended permit tcp 192.168.1.0 255.255.255.0 any eq 443
This is the correct configuration for transparent mode. The global access-list is the only ACL applied to a transparent ASA, and it evaluates all traffic crossing the Layer 2 bridge. The rule precisely matches the requirement: source is the inside subnet 192.168.1.0/24, destination is any, and service is TCP 443 (HTTPS), thus permitting only outbound HTTPS from the inside network while implicitly denying everything else. This adheres to least-privilege access control and is applied globally so that traffic from any interface, including the inside, is filtered consistently.

Question 5hardmultiple choice

A network administrator is troubleshooting a DHCP snooping issue on a Cisco switch. The switch is configured with DHCP snooping globally and on VLAN 10. The trusted interface is GigabitEthernet0/1 connected to the DHCP server. However, clients on VLAN 10 are not receiving IP addresses from the DHCP server. What is the most likely cause?

Trap 1: The switch has IP Source Guard enabled, blocking valid DHCP traffic.

IP Source Guard enforces source IP addresses against the DHCP snooping binding table, but binding entries are created only after a client successfully completes DHCP. A DHCPDISCOVER or DHCPREQUEST is sent from 0.0.0.0 before any binding exists, and IP Source Guard does not filter the DHCP handshake itself. Therefore, enabling IP Source Guard would not cause DHCP snooping to block valid DHCP traffic on the server-facing interface.

Trap 2: The DHCP server is on a different subnet and the switch lacks an IP…

A DHCP server on a different subnet would require an IPv4 helper address on the Layer 3 interface to relay broadcast DHCPDISCOVER messages, but this is a separate routing issue rather than a DHCP snooping trust problem. In the described scenario, the server is reachable in the same VLAN, so no ip helper-address is needed; DHCP snooping is operating in the Layer 2 domain. Missing helper addresses cause offer/ack timeouts at the client, but they do not cause DHCP snooping to drop server messages at the switch.

Trap 3: The DHCP server is sending offers too quickly, exceeding the…

The DHCP snooping rate limiter, configured with 'ip dhcp snooping limit rate', applies only to packets from untrusted clients, not to server-to-client responses like DHCPOFFER and DHCPACK. It is designed to prevent DHCP starvation attacks where a malicious host floods the switch with fake DISCOVER messages, exhausting the address pool. A server sending offers quickly would not trip this limiter, and if it did, the impact would be rate-based throttling, not the complete absence of DHCP replies caused by untrusted server ports.

A
The switch has IP Source Guard enabled, blocking valid DHCP traffic.
Why wrong: IP Source Guard enforces source IP addresses against the DHCP snooping binding table, but binding entries are created only after a client successfully completes DHCP. A DHCPDISCOVER or DHCPREQUEST is sent from 0.0.0.0 before any binding exists, and IP Source Guard does not filter the DHCP handshake itself. Therefore, enabling IP Source Guard would not cause DHCP snooping to block valid DHCP traffic on the server-facing interface.
B
The interface GigabitEthernet0/1 is not configured as a trusted port for DHCP snooping.
DHCP snooping classifies switch ports as trusted or untrusted. An untrusted port, such as the port where clients are connected, will discard DHCPOFFER, DHCPACK, and DHCPNAK messages because those packets must only arrive from a trusted DHCP server port. If GigabitEthernet0/1 faces the DHCP server but is left untrusted, every server response is silently dropped and clients never obtain an address. The fix is to enter interface configuration mode and issue the 'ip dhcp snooping trust' command on that port.
C
The DHCP server is on a different subnet and the switch lacks an IP helper address.
Why wrong: A DHCP server on a different subnet would require an IPv4 helper address on the Layer 3 interface to relay broadcast DHCPDISCOVER messages, but this is a separate routing issue rather than a DHCP snooping trust problem. In the described scenario, the server is reachable in the same VLAN, so no ip helper-address is needed; DHCP snooping is operating in the Layer 2 domain. Missing helper addresses cause offer/ack timeouts at the client, but they do not cause DHCP snooping to drop server messages at the switch.
D
The DHCP server is sending offers too quickly, exceeding the rate-limit on the switch.
Why wrong: The DHCP snooping rate limiter, configured with 'ip dhcp snooping limit rate', applies only to packets from untrusted clients, not to server-to-client responses like DHCPOFFER and DHCPACK. It is designed to prevent DHCP starvation attacks where a malicious host floods the switch with fake DISCOVER messages, exhausting the address pool. A server sending offers quickly would not trip this limiter, and if it did, the impact would be rate-based throttling, not the complete absence of DHCP replies caused by untrusted server ports.

Read the full DHCP explanation →

Question 6easymultiple choice

Refer to the exhibit. A network administrator notices that some DHCP packets are being dropped due to 'MAC Address Mismatch'. What is the most likely cause of this drop?

Exhibit

Refer to the exhibit.

Switch# show ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:1A:2B:3C:4D:5E  192.168.1.10     86400       dhcp-snooping   10    GigabitEthernet0/1
00:1A:2B:3C:4D:5F  192.168.1.11     86400       dhcp-snooping   10    GigabitEthernet0/2

Switch# show ip dhcp snooping statistics
Packets Processed by DHCP Snooping   = 100
Packets Dropped Because               = 5
  MAC Address Mismatch                 = 3
  Invalid Server Replies               = 2

Trap 1: The DHCP server is sending packets with an incorrect server…

This is incorrect because DHCP snooping does not validate the contents of DHCP option 54 (server identifier). A mismatched server identifier would cause the DHCP client to reject the offer or acknowledge, but it would not increment the snooping drop counter. The drop reason shown by the administrator is specifically related to MAC address validation, not to option-level validation, so this option does not explain the observed failure.

Trap 2: The DHCP client is sending a request with an incorrect transaction…

This is not a DHCP snooping drop reason because the transaction ID (xid) is a client-generated random value used to match requests with responses at the application layer. DHCP snooping operates at layer 2 and filters packets based on port trust state, message type, and MAC address consistency—not on xid validation. A transaction ID mismatch would cause the DHCP client to discard a reply from the server, but it would not cause the switch to drop the client's request.

Trap 3: The DHCP offer packet is arriving on an untrusted port.

A DHCP offer arriving on an untrusted port would be handled differently and appear under a different drop reason, such as 'Invalid Server Replies' or 'DHCP server replies on untrusted port'. Untrusted ports are client-facing, and legitimate DHCP offers should only be received from trusted ports where the DHCP server is connected. Since the log shows a MAC address mismatch rather than an untrusted-server drop, this option does not match the observed symptom.

A
The DHCP server is sending packets with an incorrect server identifier option.
Why wrong: This is incorrect because DHCP snooping does not validate the contents of DHCP option 54 (server identifier). A mismatched server identifier would cause the DHCP client to reject the offer or acknowledge, but it would not increment the snooping drop counter. The drop reason shown by the administrator is specifically related to MAC address validation, not to option-level validation, so this option does not explain the observed failure.
B
The DHCP client is using a different MAC address in the DHCP packet than the source MAC in the Ethernet frame.
This is the correct cause. DHCP snooping compares the source MAC address in the Ethernet frame header with the 'chaddr' field inside the DHCP packet itself. When the DHCP client inserts a different MAC address in the chaddr field than the actual source MAC of the frame, the switch flags this as a potential spoofing attempt and drops the packet, incrementing the 'MAC address mismatch' counter. This check prevents a client from impersonating another device's MAC address in DHCP requests.
C
The DHCP client is sending a request with an incorrect transaction ID.
Why wrong: This is not a DHCP snooping drop reason because the transaction ID (xid) is a client-generated random value used to match requests with responses at the application layer. DHCP snooping operates at layer 2 and filters packets based on port trust state, message type, and MAC address consistency—not on xid validation. A transaction ID mismatch would cause the DHCP client to discard a reply from the server, but it would not cause the switch to drop the client's request.
D
The DHCP offer packet is arriving on an untrusted port.
Why wrong: A DHCP offer arriving on an untrusted port would be handled differently and appear under a different drop reason, such as 'Invalid Server Replies' or 'DHCP server replies on untrusted port'. Untrusted ports are client-facing, and legitimate DHCP offers should only be received from trusted ports where the DHCP server is connected. Since the log shows a MAC address mismatch rather than an untrusted-server drop, this option does not match the observed symptom.

Question 7hardmultiple choice

Refer to the exhibit. A switch has IP Source Guard (IPSG) and port-security enabled on interface GigabitEthernet0/1. A host with IP 10.1.1.1 and MAC 00:1A:2B:3C:4D:5E is connected and tries to access a web server at 192.168.1.100. What will happen?

Exhibit

Refer to the exhibit.

interface GigabitEthernet0/1
 ip access-group ACL-IN in
 ip verify source port-security
!
ip access-list extended ACL-IN
 permit tcp 10.0.0.0 0.255.255.255 any eq 80
 permit tcp 10.0.0.0 0.255.255.255 any eq 443
 deny ip any any

Trap 1: The traffic is blocked because the host is not using DHCP, so IPSG…

Incorrect. IPSG does not drop all non-DHCP traffic if a static binding is configured, but in this case no such binding exists.

Trap 2: The traffic is permitted only if the destination is also in the…

Incorrect. IPSG does not check the destination IP; it checks the source IP against bindings. Destination subnet is irrelevant.

Trap 3: The traffic is permitted because the host's IP is within the…

Incorrect. Port-security does not create an IPSG binding; without a valid IP-MAC binding, IPSG will drop the traffic even if the MAC is allowed.

A
The traffic is blocked because the host is not using DHCP, so IPSG drops all non-DHCP traffic.
Why wrong: Incorrect. IPSG does not drop all non-DHCP traffic if a static binding is configured, but in this case no such binding exists.
B
The traffic is permitted only if the destination is also in the 10.0.0.0/8 range.
Why wrong: Incorrect. IPSG does not check the destination IP; it checks the source IP against bindings. Destination subnet is irrelevant.
C
The traffic is blocked because IP Source Guard requires a static binding for the host.
Correct. Without DHCP or a static IP-source binding, IPSG blocks the traffic.
D
The traffic is permitted because the host's IP is within the allowed subnet and the MAC is valid according to port-security.
Why wrong: Incorrect. Port-security does not create an IPSG binding; without a valid IP-MAC binding, IPSG will drop the traffic even if the MAC is allowed.

Study the full AAA explanation →

Question 8mediummultiple choice

A medium-sized enterprise is migrating to a Cisco DNA Center-managed network. The security policy requires that all administrative access to network devices be authenticated via TACACS+ and that authorization for commands be enforced per user role. The network team has configured ISE as the AAA server and integrated it with DNA Center. After configuration, engineers report that they can log in to devices via SSH but are not prompted for a password when entering 'enable' mode; instead, they are granted full privileges immediately. Additionally, while in configuration mode, some engineers can issue 'debug' commands that they should not have access to. The configuration on the devices includes 'aaa new-model', 'aaa authentication login default group tacacs+ local', 'aaa authorization exec default group tacacs+ local', and 'aaa authorization commands 15 default group tacacs+ local'. What is the most likely cause of the privilege escalation and missing authorization?

Trap 1: The TACACS+ server is not reachable, so the device is using local…

This option misidentifies the root cause. Even if TACACS+ is reachable or not, the device's local database with all users at privilege 15 would not allow users to enter enable mode without authentication if the AAA enable authentication method were properly configured. The real issue is that the 'aaa authentication enable default' command is absent, so the device uses no authentication for enable mode, making TACACS+ reachability irrelevant to the observed behavior.

Trap 2: Command authorization is only configured for privilege level 15,…

This option overlooks that command authorization for privilege level 15 is intended to restrict commands executed after the user has already reached level 15. Even if users initially log in at level 1, they would normally be challenged for enable authentication to elevate their privilege; if they successfully elevate, level 15 authorization applies to their subsequent commands. Adding 'aaa authorization commands 1 default' would not fix the underlying security gap because the user never needed to pass any authentication to get to level 15.

Trap 3: The 'privilege level' command is set to 15 on the VTY lines,…

Setting 'privilege level 15' on VTY lines only makes the initial login session start with full privileges, but it does not, and cannot, bypass the separate AAA enable authentication mechanism. When AAA authentication is configured, the device still requires the user to authenticate before allowing enable mode, regardless of the initial privilege level. Since the missing command is 'aaa authentication enable default', this option incorrectly attributes the behavior to VTY privilege configuration and fails to address the actual authentication omission.

A
The TACACS+ server is not reachable, so the device is using local authentication, but the local database has all users at privilege level 15.
Why wrong: This option misidentifies the root cause. Even if TACACS+ is reachable or not, the device's local database with all users at privilege 15 would not allow users to enter enable mode without authentication if the AAA enable authentication method were properly configured. The real issue is that the 'aaa authentication enable default' command is absent, so the device uses no authentication for enable mode, making TACACS+ reachability irrelevant to the observed behavior.
B
The 'aaa authentication enable default' command is missing, so the device is not requiring authentication to enter enable mode, and command authorization is not being enforced because the user is already at privilege 15.
The absence of 'aaa authentication enable default' leaves the default behavior of no authentication for enable mode, allowing any user to switch to privileged EXEC without a password. Once in enable mode, the user is at privilege level 15, and if command authorization is configured for level 15, the device may not trigger an authorization check because the user already holds full privilege, or the check may occur but without prior authentication it is ineffective. This configuration flaw directly explains why no credentials are prompted and why authorization seems bypassed.
C
Command authorization is only configured for privilege level 15, but users are logging in at level 1; they need 'aaa authorization commands 1 default' as well.
Why wrong: This option overlooks that command authorization for privilege level 15 is intended to restrict commands executed after the user has already reached level 15. Even if users initially log in at level 1, they would normally be challenged for enable authentication to elevate their privilege; if they successfully elevate, level 15 authorization applies to their subsequent commands. Adding 'aaa authorization commands 1 default' would not fix the underlying security gap because the user never needed to pass any authentication to get to level 15.
D
The 'privilege level' command is set to 15 on the VTY lines, bypassing AAA authorization.
Why wrong: Setting 'privilege level 15' on VTY lines only makes the initial login session start with full privileges, but it does not, and cannot, bypass the separate AAA enable authentication mechanism. When AAA authentication is configured, the device still requires the user to authenticate before allowing enable mode, regardless of the initial privilege level. Since the missing command is 'aaa authentication enable default', this option incorrectly attributes the behavior to VTY privilege configuration and fails to address the actual authentication omission.

Open the full BGP breakdown →

Question 9mediummultiple choice

A network engineer applies the above CoPP policy on a router. The router has BGP peers, SSH management, and SNMP monitoring. After applying this policy, which traffic will be affected?

Network Topology

Trap 1: Data plane traffic will be dropped.

Data plane traffic is traffic forwarded through the router from one interface to another, never destined to the router itself. CoPP operates on the control plane, which is the path to the routing processor (RP), and does not police transit forwarding in hardware (e.g., CEF/ASIC lookups). Therefore, user data packets that simply pass through the router are not inspected or rate-limited by this CoPP policy. Its entire effect is confined to traffic addressed to the router's own IP addresses or protocol management traffic.

Trap 2: Only SSH sessions will be rate-limited.

The CoPP policy uses a class-map that identifies multiple control-plane protocols; SSH is merely one of them. In addition to SSH, the policy typically classifies BGP, SNMP, OSPF, EIGRP, ICMP to the router, and similar management protocols. Setting a police per class or a single aggregate policer across all classes means SSH is not the only traffic rate-limited. Thus, it is incorrect to say 'only SSH' will be rate-limited; every matched protocol is subject to the same applied policing.

Trap 3: SNMP and SSH will be unaffected because they are explicitly…

In CoPP configuration, the MQC action 'permit' (or 'transmit') within a police statement does not mean exempt from rate limiting. The policer's conform-action transmit simply sends packets that are within the committed burst; any excess exceeds the policer and triggers the exceed-action (typically drop). SNMP and SSH traffic classified as control-plane and matched are therefore subject to the policer's committed rate and burst. If the traffic rate surpasses that threshold, even 'explicitly permitted' packets are dropped, so the traffic can be affected and rates may be throttled.

A
BGP sessions may flap due to dropped keepalives.
BGP keepalives are sent periodically (typically every 60 seconds) and matched by the CoPP BGP class because they are control-plane TCP traffic to/from port 179. If the policer's committed rate is exceeded—even briefly—the excess keepalives are dropped. After a few missed keepalives, the BGP hold timer (default 180 seconds) expires, causing the peer session to flap. The same policer can also drop BGP route updates, which may cause instability beyond just keepalives.
B
Data plane traffic will be dropped.
Why wrong: Data plane traffic is traffic forwarded through the router from one interface to another, never destined to the router itself. CoPP operates on the control plane, which is the path to the routing processor (RP), and does not police transit forwarding in hardware (e.g., CEF/ASIC lookups). Therefore, user data packets that simply pass through the router are not inspected or rate-limited by this CoPP policy. Its entire effect is confined to traffic addressed to the router's own IP addresses or protocol management traffic.
C
Only SSH sessions will be rate-limited.
Why wrong: The CoPP policy uses a class-map that identifies multiple control-plane protocols; SSH is merely one of them. In addition to SSH, the policy typically classifies BGP, SNMP, OSPF, EIGRP, ICMP to the router, and similar management protocols. Setting a police per class or a single aggregate policer across all classes means SSH is not the only traffic rate-limited. Thus, it is incorrect to say 'only SSH' will be rate-limited; every matched protocol is subject to the same applied policing.
D
SNMP and SSH will be unaffected because they are explicitly permitted.
Why wrong: In CoPP configuration, the MQC action 'permit' (or 'transmit') within a police statement does not mean exempt from rate limiting. The policer's conform-action transmit simply sends packets that are within the committed burst; any excess exceeds the policer and triggers the exceed-action (typically drop). SNMP and SSH traffic classified as control-plane and matched are therefore subject to the policer's committed rate and burst. If the traffic rate surpasses that threshold, even 'explicitly permitted' packets are dropped, so the traffic can be affected and rates may be throttled.

Question 10mediummulti select

Which TWO of the following are valid methods to mitigate VLAN hopping attacks?

Trap 1: Configure switchport mode dynamic auto on all ports.

Dynamic auto can negotiate trunk.

Trap 2: Set the native VLAN to VLAN 1 on all trunk ports.

VLAN 1 is default and does not mitigate.

Trap 3: Use 802.1Q trunking instead of ISL.

Both are susceptible; switching encapsulation is not a mitigation.

A
Configure switchport mode dynamic auto on all ports.
Why wrong: Dynamic auto can negotiate trunk.
B
Disable Dynamic Trunking Protocol (DTP) on all access ports.
Prevents trunk negotiation.
C
Set the native VLAN to VLAN 1 on all trunk ports.
Why wrong: VLAN 1 is default and does not mitigate.
D
Set the native VLAN to an unused VLAN ID on all trunk ports.
Mitigates double-tagging VLAN hopping.
E
Use 802.1Q trunking instead of ISL.
Why wrong: Both are susceptible; switching encapsulation is not a mitigation.

Question 11hardmulti select

Which THREE of the following are characteristics of Cisco TrustSec (CTS) security architecture?

Trap 1: It uses IPsec to encrypt traffic between network devices.

CTS uses MACsec, not IPsec.

Trap 2: It uses VLANs to segment traffic based on security roles.

Segmentation is via SGTs, not VLANs.

A
It uses IPsec to encrypt traffic between network devices.
Why wrong: CTS uses MACsec, not IPsec.
B
It uses VLANs to segment traffic based on security roles.
Why wrong: Segmentation is via SGTs, not VLANs.
C
It uses Security Group Tags (SGTs) to classify traffic.
SGTs are used for classification.
D
It provides data confidentiality using IEEE 802.1AE (MACsec) encryption.
MACsec provides link-layer encryption.
E
It uses Security Group Access Control Lists (SGACLs) to enforce policies.
SGACLs are enforced based on SGTs.

Question 12easymulti select

Which TWO features are part of Cisco TrustSec for providing role-based access control?

Trap 1: Change of Authorization (CoA)

CoA is used for mid-session policy changes, not a core TrustSec feature.

Trap 2: 802.1X authentication

802.1X is an authentication protocol, not a TrustSec feature.

Trap 3: MACsec encryption

MACsec provides encryption, not access control.

A
Security Group Access Control Lists (SGACLs)
SGACLs enforce policies based on SGTs.
B
Change of Authorization (CoA)
Why wrong: CoA is used for mid-session policy changes, not a core TrustSec feature.
C
802.1X authentication
Why wrong: 802.1X is an authentication protocol, not a TrustSec feature.
D
Security Group Tags (SGTs)
SGTs are used to classify traffic based on user/device identity.
E
MACsec encryption
Why wrong: MACsec provides encryption, not access control.

Question 13hardmultiple choice

Your company has deployed a Cisco Catalyst 9300 switch stack as the distribution layer for a campus network. The network uses VLANs 10 (data), 20 (voice), and 30 (management). The switch stack is configured with DHCP snooping, Dynamic ARP Inspection (DAI), and IP Source Guard (IPSG) on access ports. Recently, users in VLAN 10 report intermittent connectivity issues. You notice that some users receive duplicate IP addresses from the DHCP server. The DHCP server is connected to a trunk port on the switch stack. After reviewing logs, you see that DHCPACK messages are being dropped on the trunk port. The DHCP snooping binding table shows entries for legitimate clients, but also some entries with MAC addresses from a different vendor. Which action should you take to resolve the issue?

Trap 1: Manually shut down the access ports that have unknown MAC addresses…

This does not address the DHCP server response being dropped.

Trap 2: Disable Dynamic ARP Inspection on VLAN 10.

DAI validates ARP packets, not DHCP messages.

Trap 3: Disable IP Source Guard on all access ports in VLAN 10.

IPSG filters IP traffic based on binding table, not DHCP messages.

A
Manually shut down the access ports that have unknown MAC addresses in the binding table.
Why wrong: This does not address the DHCP server response being dropped.
B
Disable Dynamic ARP Inspection on VLAN 10.
Why wrong: DAI validates ARP packets, not DHCP messages.
C
Configure the trunk port connecting to the DHCP server as a trusted port for DHCP snooping.
DHCP snooping drops DHCP server responses on untrusted ports.
D
Disable IP Source Guard on all access ports in VLAN 10.
Why wrong: IPSG filters IP traffic based on binding table, not DHCP messages.

Question 14mediumdrag order

Drag and drop the steps to configure port security on a Cisco switch in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Step 1: Set maximum MAC addresses, Step 2: Enable port security,…

Setting the maximum before enabling port security is invalid because the port-security feature must be active to apply limits.

Trap 2: Step 1: Configure violation mode, Step 2: Enable port security,…

Configuring the violation mode before enabling port security is not allowed; the mode only takes effect after port security is enabled.

Trap 3: Step 1: Enable port security, Step 2: Define secure MAC addresses,…

Defining specific MAC addresses before setting the maximum count can cause conflicts if the number of defined addresses exceeds the default maximum.

A
Step 1: Enable port security (switchport port-security), Step 2: Set maximum MAC addresses (switchport port-security maximum), Step 3: Define secure MAC addresses (switchport port-security mac-address sticky or static), Step 4: Configure violation mode (switchport port-security violation shutdown/restrict/protect)
This order ensures port security is enabled first, then limits are set, followed by defining specific addresses if needed, and finally setting the action on violation.
B
Step 1: Set maximum MAC addresses, Step 2: Enable port security, Step 3: Define secure MAC addresses, Step 4: Configure violation mode
Why wrong: Setting the maximum before enabling port security is invalid because the port-security feature must be active to apply limits.
C
Step 1: Configure violation mode, Step 2: Enable port security, Step 3: Set maximum MAC addresses, Step 4: Define secure MAC addresses
Why wrong: Configuring the violation mode before enabling port security is not allowed; the mode only takes effect after port security is enabled.
D
Step 1: Enable port security, Step 2: Define secure MAC addresses, Step 3: Set maximum MAC addresses, Step 4: Configure violation mode
Why wrong: Defining specific MAC addresses before setting the maximum count can cause conflicts if the number of defined addresses exceeds the default maximum.

Open the full STP breakdown →

Question 15mediummatching

Match each Spanning Tree Protocol (STP) variant to its key characteristic.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Original standard, slow convergence

Fast convergence, backward compatible

Multiple spanning trees per VLAN group

Cisco proprietary, per-VLAN STP

Cisco proprietary, per-VLAN RSTP

Trap 1: STP (802.1D): Per-VLAN spanning tree

Incorrect — STP is a single spanning tree for all VLANs; per-VLAN is PVST+.

Trap 2: RSTP (802.1w): Multiple spanning tree instances

Incorrect — RSTP runs a single instance; multiple instances are provided by MSTP.

A
STP (802.1D): Original standard with slow convergence (30-50 seconds)
STP is the original Spanning Tree Protocol defined in IEEE 802.1D with slow convergence.
B
RSTP (802.1w): Rapid convergence, backward compatible with STP
RSTP improves convergence time to a few seconds and is backward compatible with STP.
C
MSTP (802.1s): Maps multiple VLANs to a single spanning tree instance
MSTP allows grouping VLANs into instances to reduce the number of spanning trees.
D
PVST+: Per-VLAN Spanning Tree, each VLAN has its own STP instance
PVST+ is Cisco's proprietary implementation that runs a separate STP instance per VLAN.
E
STP (802.1D): Per-VLAN spanning tree
Why wrong: Incorrect — STP is a single spanning tree for all VLANs; per-VLAN is PVST+.
F
RSTP (802.1w): Multiple spanning tree instances
Why wrong: Incorrect — RSTP runs a single instance; multiple instances are provided by MSTP.