Aaa practice questions

A network administrator wants to secure remote CLI access to a Cisco router, moving beyond simple username/password authentication. Which approach best achieves this goal?

Trap 1: Replace SSH with Telnet to simplify troubleshooting

Replacing SSH with Telnet would downgrade the remote-management session to plaintext, exposing usernames, passwords, and executed commands to any observer on the network path. Telnet lacks encryption and integrity protection, making the administrative session vulnerable to eavesdropping and session hijacking, whereas SSH provides robust encryption and strong authentication. This swap would weaken, not simplify, management security.

Trap 2: Configure an extended ACL to limit remote access to specific source…

This answer is wrong because it is not an authentication control; it merely restricts source IP addresses. If authentication remains weak, an attacker can simply originate from an allowed source (e.g., by spoofing) or compromise that host, effectively bypassing the ACL. Substituting an ACL for proper authentication leaves the device with a weaker security posture, undermining secure remote administrative access.

Trap 3: Disable password authentication and rely solely on device location…

Disabling password authentication and relying only on network location is fundamentally unsafe because location is not an identity factor. An attacker can spoof a trusted IP address or compromise a device inside the trusted segment, gaining access without proving authorization. Additionally, this proposal has no connection to switch trunking, which concerns VLAN propagation over inter-switch links and does not strengthen remote-administration authentication in any way.

A
Use stronger or additional authentication controls to improve remote administrative access security
Implementing stronger or additional authentication controls—such as multi-factor authentication, AAA with TACACS+/RADIUS, or per-user credentials—directly addresses the security of the management plane. A static password alone is vulnerable to password guessing, credential theft, or replay. Strong authentication ensures that even if one factor is compromised, an attacker cannot complete the login process, protecting the device from unauthorized remote configuration.
B
Replace SSH with Telnet to simplify troubleshooting
Why it fails: Replacing SSH with Telnet would downgrade the remote-management session to plaintext, exposing usernames, passwords, and executed commands to any observer on the network path. Telnet lacks encryption and integrity protection, making the administrative session vulnerable to eavesdropping and session hijacking, whereas SSH provides robust encryption and strong authentication. This swap would weaken, not simplify, management security.
C
Configure an extended ACL to limit remote access to specific source IP addresses
Why it fails: This answer is wrong because it is not an authentication control; it merely restricts source IP addresses. If authentication remains weak, an attacker can simply originate from an allowed source (e.g., by spoofing) or compromise that host, effectively bypassing the ACL. Substituting an ACL for proper authentication leaves the device with a weaker security posture, undermining secure remote administrative access.
D
Disable password authentication and rely solely on device location in the network
Why it fails: Disabling password authentication and relying only on network location is fundamentally unsafe because location is not an identity factor. An attacker can spoof a trusted IP address or compromise a device inside the trusted segment, gaining access without proving authorization. Additionally, this proposal has no connection to switch trunking, which concerns VLAN propagation over inter-switch links and does not strengthen remote-administration authentication in any way.

Question 2hardmultiple choice

An engineer is allowed to log in to a router but cannot enter configuration mode. Which AAA function most directly explains that outcome?

Trap 1: Authentication

Authentication is the process of verifying a user's identity, typically with a username and password, and it occurs before any command-level permissions are considered. Since the user was able to log in, authentication must have been successful, so it cannot be the reason for the configuration restriction. Authentication alone only answers 'who are you?' and does not dictate which commands or mode a user can access after login.

Trap 2: Accounting

Accounting is the AAA component that records user activity, such as login times, commands executed, and system events, for audit and billing purposes. It does not grant or revoke any permissions; rather, it observes and logs what a user does after access is granted. Since the user's inability to enter configuration mode is a permission decision, accounting cannot be the cause, making it an incorrect answer.

Trap 3: DNS

DNS (Domain Name System) is responsible for converting human-readable hostnames into IP addresses, and it has no role in enforcing command-line interface permissions or privilege levels on a Cisco router. If DNS resolution were failing, the user might experience delays or failures when using hostnames in commands, but they would still be able to enter configuration mode if their privilege level allowed it. Therefore, DNS is unrelated to this access control problem.

A
Authorization
Authorization is the AAA component that determines what an authenticated user is permitted to do, including which commands they may execute and whether they can enter privileged EXEC or global configuration modes. In this scenario, authentication already succeeded because the user logged in, but the router's authorization policy restricts this user to lower privilege levels, preventing configuration access. Thus, the correct answer is authorization.
B
Authentication
Why it fails: Authentication is the process of verifying a user's identity, typically with a username and password, and it occurs before any command-level permissions are considered. Since the user was able to log in, authentication must have been successful, so it cannot be the reason for the configuration restriction. Authentication alone only answers 'who are you?' and does not dictate which commands or mode a user can access after login.
C
Accounting
Why it fails: Accounting is the AAA component that records user activity, such as login times, commands executed, and system events, for audit and billing purposes. It does not grant or revoke any permissions; rather, it observes and logs what a user does after access is granted. Since the user's inability to enter configuration mode is a permission decision, accounting cannot be the cause, making it an incorrect answer.
D
DNS
Why it fails: DNS (Domain Name System) is responsible for converting human-readable hostnames into IP addresses, and it has no role in enforcing command-line interface permissions or privilege levels on a Cisco router. If DNS resolution were failing, the user might experience delays or failures when using hostnames in commands, but they would still be able to enter configuration mode if their privilege level allowed it. Therefore, DNS is unrelated to this access control problem.

Question 3hardmultiple choice

Exhibit: Clients can see the corporate SSID but fail authentication after entering valid usernames and passwords. Which issue is the best explanation?

Exhibit

WLAN security: WPA2-Enterprise
AP log: RADIUS server timeout
SSID is visible and clients associate, but login fails

Trap 1: The AP is using the wrong RF channel

An incorrect RF channel assignment would prevent the AP from operating on the expected frequency, typically making the SSID undetectable or severely degrading signal quality so that clients cannot associate at all. Since the clients can see the corporate SSID, they are receiving beacons and successfully probing, meaning the RF channel is functioning at the physical layer. An authentication failure after a visible SSID points to a higher-layer issue such as RADIUS or EAP, not channel misconfiguration.

Trap 2: The SSID must be hidden for enterprise authentication

Hiding the SSID only suppresses the SSID from beacon frames and some probe responses; it does not alter the 802.1X/EAP authentication flow or RADIUS requirements. Enterprise authentication functions identically with a broadcast SSID, and clients that already know the SSID can still find and attempt to authenticate to a hidden network. The failure described occurs after the SSID is visible, so hiding it would not resolve or explain the authentication failure.

Trap 3: The clients need a voice VLAN assignment first

Voice VLANs are a switch-level mechanism used to separate and prioritize VoIP traffic, often via LLDP-MED or CDP, and are not a prerequisite for wireless client authentication. In a WPA2-Enterprise network, the VLAN assignment is an outcome of successful RADIUS authentication, where the server returns attributes like Tunnel-Private-Group-ID, rather than a condition that must exist beforehand. Requiring a voice VLAN before authentication would create a circular dependency and misinterprets the role of VLANs in 802.1X.

A
The AP is using the wrong RF channel
Why it fails: An incorrect RF channel assignment would prevent the AP from operating on the expected frequency, typically making the SSID undetectable or severely degrading signal quality so that clients cannot associate at all. Since the clients can see the corporate SSID, they are receiving beacons and successfully probing, meaning the RF channel is functioning at the physical layer. An authentication failure after a visible SSID points to a higher-layer issue such as RADIUS or EAP, not channel misconfiguration.
B
The RADIUS path or shared secret is failing
In WPA2-Enterprise, the access point acts as an 802.1X authenticator and forwards EAP credentials to a RADIUS server. If the shared secret is misconfigured or the RADIUS server is unreachable, the authentication exchange fails after the client associates, precisely matching the symptom of seeing the SSID but being unable to connect. This is the only option that directly impacts the authentication stage rather than association or RF visibility.
C
The SSID must be hidden for enterprise authentication
Why it fails: Hiding the SSID only suppresses the SSID from beacon frames and some probe responses; it does not alter the 802.1X/EAP authentication flow or RADIUS requirements. Enterprise authentication functions identically with a broadcast SSID, and clients that already know the SSID can still find and attempt to authenticate to a hidden network. The failure described occurs after the SSID is visible, so hiding it would not resolve or explain the authentication failure.
D
The clients need a voice VLAN assignment first
Why it fails: Voice VLANs are a switch-level mechanism used to separate and prioritize VoIP traffic, often via LLDP-MED or CDP, and are not a prerequisite for wireless client authentication. In a WPA2-Enterprise network, the VLAN assignment is an outcome of successful RADIUS authentication, where the server returns attributes like Tunnel-Private-Group-ID, rather than a condition that must exist beforehand. Requiring a voice VLAN before authentication would create a circular dependency and misinterprets the role of VLANs in 802.1X.

Question 4mediummultiple choice

In AAA, what does the second A stand for?

Trap 1: Application

The term 'Application' is not part of the AAA framework; AAA strictly refers to Authentication, Authorization, and Accounting. While network services or software applications may invoke AAA protocols like RADIUS or TACACS+, the second 'A' in the acronym is never 'Application.' Choosing this would confuse the protocol framework with the software layer that relies on it, which is why it is incorrect.

Trap 2: Accounting

In AAA, Accounting is actually the third 'A,' not the second. Accounting tracks and measures user activity, resource consumption, and session statistics for auditing, billing, or capacity planning purposes. Since the correct sequence is Authentication → Authorization → Accounting, the second step is Authorization, making Accounting an incorrect choice for the second 'A'.

Trap 3: Auditing

Although 'Auditing' is operationally related to security monitoring, it is not a term in the AAA acronym. The AAA model uses 'Accounting' to cover the collection of log and usage data, whereas auditing is a broader review process that may analyze accounting records after the fact. Therefore, Auditing is not the second 'A,' as the framework specifically names Authentication, Authorization, and Accounting.

A
Application
Why it fails: The term 'Application' is not part of the AAA framework; AAA strictly refers to Authentication, Authorization, and Accounting. While network services or software applications may invoke AAA protocols like RADIUS or TACACS+, the second 'A' in the acronym is never 'Application.' Choosing this would confuse the protocol framework with the software layer that relies on it, which is why it is incorrect.
B
Accounting
Why it fails: In AAA, Accounting is actually the third 'A,' not the second. Accounting tracks and measures user activity, resource consumption, and session statistics for auditing, billing, or capacity planning purposes. Since the correct sequence is Authentication → Authorization → Accounting, the second step is Authorization, making Accounting an incorrect choice for the second 'A'.
C
Authorization
In the AAA security model, the second 'A' stands for Authorization, which is the process of determining what actions or resources an authenticated user is permitted to access. After a user proves their identity via authentication, authorization enforces policies such as permit/deny rules, often based on roles or attributes, and is a distinct step from authentication and accounting. For example, in Cisco ISE, authorization may assign a VLAN or ACL after authentication succeeds.
D
Auditing
Why it fails: Although 'Auditing' is operationally related to security monitoring, it is not a term in the AAA acronym. The AAA model uses 'Accounting' to cover the collection of log and usage data, whereas auditing is a broader review process that may analyze accounting records after the fact. Therefore, Auditing is not the second 'A,' as the framework specifically names Authentication, Authorization, and Accounting.

Question 5mediumdrag order

Drag and drop the following steps into the correct order to configure AAA with a RADIUS server and enable 802.1X port authentication on an IOS-XE switch.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Enter global configuration mode, enable 802.1X globally, configure…

Enabling 802.1X globally before configuring RADIUS and AAA is incorrect because the switch cannot yet perform authentication; the global 'dot1x system-auth-control' command expects AAA to be in place, and without it, the command may error or leave the system in an incomplete state. Even if the command is accepted, no authentication method exists, so any attempts to authenticate a supplicant would fail immediately. The proper order is to configure the RADIUS server and AAA first, then enable 802.1X globally.

Trap 2: Enter global configuration mode, configure AAA authentication,…

Attempting to configure AAA authentication before defining the RADIUS server is incorrect because the AAA method list must reference a real RADIUS server group; without a server definition, the AAA configuration cannot bind to a viable authentication source. On Cisco IOS, the 'radius server' command creates the server entry, and then 'aaa authentication dot1x default group radius' uses it. Reversing this order means the AAA method list references a server group that does not yet exist, causing configuration errors or an incomplete configuration.

Trap 3: Enter global configuration mode, configure RADIUS server, enable…

Configuring the RADIUS server and then enabling 802.1X globally before configuring AAA is incorrect because global 802.1X enablement requires AAA to be already active; without AAA, the switch has no way to implement the authentication process. The 'dot1x system-auth-control' command may appear to succeed, but it will not function correctly because AAA authentication has not been defined to use the RADIUS server. AAA must be configured immediately after the RADIUS server and before the global 802.1X command.

A
Enter global configuration mode, configure RADIUS server, configure AAA authentication, enable 802.1X globally, apply 802.1X per interface
This sequence is correct because it builds each required service in dependency order. First, entering global configuration mode is necessary, then defining the RADIUS server creates the backend authentication source that 802.1X will use. Next, configuring AAA authentication establishes the method list that references that RADIUS server, which 802.1X depends on for authenticating supplicants. Only after AAA is fully operational can 802.1X be enabled globally with 'dot1x system-auth-control,' and finally applying 802.1X per interface activates the feature where needed.
B
Enter global configuration mode, enable 802.1X globally, configure RADIUS server, configure AAA authentication, apply 802.1X per interface
Why it fails: Enabling 802.1X globally before configuring RADIUS and AAA is incorrect because the switch cannot yet perform authentication; the global 'dot1x system-auth-control' command expects AAA to be in place, and without it, the command may error or leave the system in an incomplete state. Even if the command is accepted, no authentication method exists, so any attempts to authenticate a supplicant would fail immediately. The proper order is to configure the RADIUS server and AAA first, then enable 802.1X globally.
C
Enter global configuration mode, configure AAA authentication, configure RADIUS server, enable 802.1X globally, apply 802.1X per interface
Why it fails: Attempting to configure AAA authentication before defining the RADIUS server is incorrect because the AAA method list must reference a real RADIUS server group; without a server definition, the AAA configuration cannot bind to a viable authentication source. On Cisco IOS, the 'radius server' command creates the server entry, and then 'aaa authentication dot1x default group radius' uses it. Reversing this order means the AAA method list references a server group that does not yet exist, causing configuration errors or an incomplete configuration.
D
Enter global configuration mode, configure RADIUS server, enable 802.1X globally, configure AAA authentication, apply 802.1X per interface
Why it fails: Configuring the RADIUS server and then enabling 802.1X globally before configuring AAA is incorrect because global 802.1X enablement requires AAA to be already active; without AAA, the switch has no way to implement the authentication process. The 'dot1x system-auth-control' command may appear to succeed, but it will not function correctly because AAA authentication has not been defined to use the RADIUS server. AAA must be configured immediately after the RADIUS server and before the global 802.1X command.

Question 6mediumdrag order

Drag and drop the following steps into the correct order to configure AAA with a RADIUS server and enable 802.1X port authentication on a Cisco IOS-XE switch.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Enter global configuration mode, enable 802.1X globally, define the…

Enabling 802.1X globally with 'dot1x system-auth-control' before configuring AAA is premature because no authentication method list exists to validate supplicants; the switch would have no mechanism to authenticate users even though the feature is enabled. Furthermore, AAA authentication cannot be configured until the RADIUS server is defined, because 'aaa authentication dot1x default group radius' requires an existing RADIUS server group. Thus this sequence leaves a broken configuration and would not authenticate anyone.

Trap 2: Enter global configuration mode, configure AAA authentication,…

Configuring AAA authentication before defining the RADIUS server is impossible in practice: the command 'aaa authentication dot1x default group radius' references a server group that does not yet exist, so the IOS would either reject the command or create an empty method list. In a proper configuration, the RADIUS server must be defined first so the AAA method list can point to a valid host with a shared key. This order also matters because AAA authentication for 802.1X must be present before the global 'dot1x system-auth-control' is issued, but the server definition and AAA configuration are tightly coupled and cannot be reversed.

Trap 3: Enter global configuration mode, define the RADIUS server, enable…

Defining the RADIUS server first is correct, but enabling 802.1X globally before configuring AAA authentication still leaves the switch without a method list for dot1x; the 'dot1x system-auth-control' command activates 802.1X on all capable ports, but no 'aaa authentication dot1x' method list exists to specify RADIUS, so authentication requests would be unanswered. The AAA configuration must be inserted between the server definition and the global enable to provide the actual authentication mechanism. This is a classic ordering trap: the server definition alone does not enable any authentication flow.

A
Enter global configuration mode, define the RADIUS server, configure AAA authentication, enable 802.1X globally, apply per-interface 802.1X settings.
This is the correct sequence because the RADIUS server must exist before the AAA method list can reference it, AAA authentication must be in place before the global 802.1X switch is enabled, and per-interface enforcement comes last. In Cisco IOS, the commands 'radius server' defines the host and key, 'aaa authentication dot1x default group radius' builds the method list, 'dot1x system-auth-control' enables the feature globally, and then interface configuration with 'dot1x port-control auto' applies it. Skipping any earlier step would leave 802.1X referencing a missing server or no authentication method.
B
Enter global configuration mode, enable 802.1X globally, define the RADIUS server, configure AAA authentication, apply per-interface 802.1X settings.
Why it fails: Enabling 802.1X globally with 'dot1x system-auth-control' before configuring AAA is premature because no authentication method list exists to validate supplicants; the switch would have no mechanism to authenticate users even though the feature is enabled. Furthermore, AAA authentication cannot be configured until the RADIUS server is defined, because 'aaa authentication dot1x default group radius' requires an existing RADIUS server group. Thus this sequence leaves a broken configuration and would not authenticate anyone.
C
Enter global configuration mode, configure AAA authentication, define the RADIUS server, enable 802.1X globally, apply per-interface 802.1X settings.
Why it fails: Configuring AAA authentication before defining the RADIUS server is impossible in practice: the command 'aaa authentication dot1x default group radius' references a server group that does not yet exist, so the IOS would either reject the command or create an empty method list. In a proper configuration, the RADIUS server must be defined first so the AAA method list can point to a valid host with a shared key. This order also matters because AAA authentication for 802.1X must be present before the global 'dot1x system-auth-control' is issued, but the server definition and AAA configuration are tightly coupled and cannot be reversed.
D
Enter global configuration mode, define the RADIUS server, enable 802.1X globally, configure AAA authentication, apply per-interface 802.1X settings.
Why it fails: Defining the RADIUS server first is correct, but enabling 802.1X globally before configuring AAA authentication still leaves the switch without a method list for dot1x; the 'dot1x system-auth-control' command activates 802.1X on all capable ports, but no 'aaa authentication dot1x' method list exists to specify RADIUS, so authentication requests would be unanswered. The AAA configuration must be inserted between the server definition and the global enable to provide the actual authentication mechanism. This is a classic ordering trap: the server definition alone does not enable any authentication flow.

Question 7easymultiple choice

In AAA, which function determines what an authenticated user is allowed to do after login?

Trap 1: Authentication

Authentication is the AAA step that verifies the identity of a user by validating credentials such as usernames, passwords, digital certificates, or tokens. It answers the question 'who are you?', establishing that the user is legitimate, but it does not specify what that user is permitted to do. Determining permitted actions is a separate function reserved for authorization.

Trap 2: Accounting

Accounting is the AAA component that records and audits user activity, tracking sessions, data usage, commands executed, and resources consumed. It answers 'what did the user do?' for billing, forensics, or monitoring purposes, but it does not define the user's permitted capabilities. As a post-authentication logging function, it is unrelated to determining the scope of user rights.

Trap 3: Encryption

Encryption is a data confidentiality technique that uses cryptographic algorithms to convert readable data into a protected format, preventing unauthorized observation during transmission or storage. It is not a component of the AAA framework and does not control or define user permissions; it secures data, not access. Protocols like IPsec and TLS provide encryption but are separate layer of network security.

A
Authentication
Why it fails: Authentication is the AAA step that verifies the identity of a user by validating credentials such as usernames, passwords, digital certificates, or tokens. It answers the question 'who are you?', establishing that the user is legitimate, but it does not specify what that user is permitted to do. Determining permitted actions is a separate function reserved for authorization.
B
Authorization
Authorization is the AAA process that determines the specific permissions, access rights, and allowed actions for an authenticated user. It defines what resources, commands, or services the user can use, effectively answering the question 'what can this user do?'. In Cisco configurations, this is often implemented via named permission lists or attribute-value pairs on an AAA server.
C
Accounting
Why it fails: Accounting is the AAA component that records and audits user activity, tracking sessions, data usage, commands executed, and resources consumed. It answers 'what did the user do?' for billing, forensics, or monitoring purposes, but it does not define the user's permitted capabilities. As a post-authentication logging function, it is unrelated to determining the scope of user rights.
D
Encryption
Why it fails: Encryption is a data confidentiality technique that uses cryptographic algorithms to convert readable data into a protected format, preventing unauthorized observation during transmission or storage. It is not a component of the AAA framework and does not control or define user permissions; it secures data, not access. Protocols like IPsec and TLS provide encryption but are separate layer of network security.

Read the full DNS explanation →

Question 8mediummulti select

Which two statements accurately describe DNS in everyday network use?

Trap 1: DNS automatically assigns IP addresses to hosts.

DNS resolves names to IP addresses; it never allocates them. Address assignment belongs to DHCP, which leases IPs to hosts. The confusion arises because both are core network services often deployed together, so DNS would be the right answer only if the question concerned hostname resolution.

Trap 2: DNS replaces the need for subnet masks.

Subnet masks are configured on interfaces and used by IP routing; DNS performs name-to-address resolution and has no bearing on them. The option tempts because DNS is a fundamental service present in nearly every network, but it would only be correct if the question asked about resolving hostnames.

Trap 3: DNS elects the STP root bridge.

DNS resolves names to IP addresses and does not participate in Spanning Tree Protocol; root bridge election uses bridge IDs exchanged in BPDUs. It is tempting because DNS is a foundational service, but it is the correct topic when questions cover name resolution, zones, or record types.

A
DNS helps resolve hostnames into IP-related information.
DNS translates human-readable hostnames into IP-related records, including A, AAAA and CNAME entries, so clients can locate services without memorising addresses. This satisfies the stem's requirement that the statement reflect everyday resolution behaviour, where forward lookups from name to address underpin nearly all routine network communication.
B
DNS makes services easier to use by allowing names instead of raw IP addresses.
By mapping names to addresses, DNS lets users and applications reference services by hostname rather than raw IP addresses. This abstraction satisfies the everyday usability requirement, since addresses can change without users needing to relearn them.
C
DNS automatically assigns IP addresses to hosts.
Why it fails: DNS resolves names to IP addresses; it never allocates them. Address assignment belongs to DHCP, which leases IPs to hosts. The confusion arises because both are core network services often deployed together, so DNS would be the right answer only if the question concerned hostname resolution.
D
DNS replaces the need for subnet masks.
Why it fails: Subnet masks are configured on interfaces and used by IP routing; DNS performs name-to-address resolution and has no bearing on them. The option tempts because DNS is a fundamental service present in nearly every network, but it would only be correct if the question asked about resolving hostnames.
E
DNS elects the STP root bridge.
Why it fails: DNS resolves names to IP addresses and does not participate in Spanning Tree Protocol; root bridge election uses bridge IDs exchanged in BPDUs. It is tempting because DNS is a foundational service, but it is the correct topic when questions cover name resolution, zones, or record types.

Question 9hardmultiple choice

A switchport is configured for 802.1X authentication. What is the usual role of the RADIUS server in that design?

Trap 1: It provides Layer 2 trunk negotiation for the supplicant.

Trunk links are negotiated between adjacent switches using Dynamic Trunking Protocol (DTP) or manually configured with switchport modes; RADIUS has no mechanism for this function. On an 802.1X port, the switch is a port access entity that only relays authentication traffic. While a RADIUS server can return authorization attributes such as VLAN assignment after authentication, it never establishes or negotiates Layer 2 trunking for the supplicant.

Trap 2: It replaces the need for DHCP on the access layer.

DHCP is the protocol that assigns IP configuration such as address, subnet mask, and gateway to a host, while RADIUS only processes authentication requests. Even after 802.1X authenticates a device and assigns a VLAN via RADIUS attributes, the device still needs DHCP (or static IP) to participate on the network. The two protocols operate at different layers and solve separate problems, so RADIUS cannot substitute for DHCP's address-allocation role.

Trap 3: It generates ARP replies on behalf of the default gateway.

RADIUS servers authenticate devices and users; they do not participate in Layer 2 address resolution. ARP is used by end hosts to map a next-hop IP to a MAC address, and the default gateway itself responds to ARP requests. The switchport's 802.1X authenticator sends RADIUS Access-Request packets, not ARP frames, so the server never answers for the gateway.

A
It provides Layer 2 trunk negotiation for the supplicant.
Why it fails: Trunk links are negotiated between adjacent switches using Dynamic Trunking Protocol (DTP) or manually configured with switchport modes; RADIUS has no mechanism for this function. On an 802.1X port, the switch is a port access entity that only relays authentication traffic. While a RADIUS server can return authorization attributes such as VLAN assignment after authentication, it never establishes or negotiates Layer 2 trunking for the supplicant.
B
It validates authentication credentials for the supplicant.
In an 802.1X deployment, the switch acts as the authenticator and forwards EAP frames from the supplicant to the RADIUS server. The server performs the actual authentication decision by checking the presented credentials (EAP-TLS, PEAP-MSCHAPv2, etc.) against an identity store, then returns Access-Accept, Access-Reject, or Access-Challenge. This centralized AAA role is what makes RADIUS the logical validation point for the supplicant's credentials.
C
It replaces the need for DHCP on the access layer.
Why it fails: DHCP is the protocol that assigns IP configuration such as address, subnet mask, and gateway to a host, while RADIUS only processes authentication requests. Even after 802.1X authenticates a device and assigns a VLAN via RADIUS attributes, the device still needs DHCP (or static IP) to participate on the network. The two protocols operate at different layers and solve separate problems, so RADIUS cannot substitute for DHCP's address-allocation role.
D
It generates ARP replies on behalf of the default gateway.
Why it fails: RADIUS servers authenticate devices and users; they do not participate in Layer 2 address resolution. ARP is used by end hosts to map a next-hop IP to a MAC address, and the default gateway itself responds to ARP requests. The switchport's 802.1X authenticator sends RADIUS Access-Request packets, not ARP frames, so the server never answers for the gateway.

Question 10mediummatching

Match each access-control term to its most accurate meaning.

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

Concepts

Matches

Verification of identity

Determination of allowed actions

Limiting access to only what is necessary

Credential store maintained on the device itself

Trap 1: Authorization: The process of verifying the identity of a user or…

Authorization is the post-authentication process that determines exactly which network resources, services, or commands an authenticated user may use, often based on assigned privilege levels or policies. It is not concerned with verifying identity; rather, it assumes the user has already been authenticated and then answers the question 'what is this user allowed to do?' Therefore, it is distinct from authentication, which is the verification step.

Trap 2: Accounting: The process of granting or denying access to network…

Accounting cannot be the process of granting or denying access because that action is the definition of authorization. In practice, accounting refers to the collection and logging of user activity data, including login and logout times, commands executed, and bandwidth consumed. This information is used for auditing, billing, compliance, and troubleshooting, and it in no way controls resource access decisions.

Trap 3: Identification: The process of logging and monitoring user…

Identification is the user's initial assertion of identity, such as typing a username or presenting a pre-shared token, before any verification occurs. Logging and monitoring user activities is called accounting, which comes after authentication and authorization and tracks what the user actually did. Representing accounting as identical to identification conflates the pre-verification claim with the post-session audit trail.

A
Authentication: The process of verifying the identity of a user or device.
Authentication is the initial security step that validates a user's or device's stated identity through provided credentials such as passwords, cryptographic keys, or biometric factors. Unlike identification, which merely asserts who the user is, authentication verifies the claim to establish trust before access decisions can be made. This is the first A in the AAA framework (Authentication, Authorization, Accounting) and is required before authorization or accounting can occur.
B
Authorization: The process of verifying the identity of a user or device.
Why it fails: Authorization is the post-authentication process that determines exactly which network resources, services, or commands an authenticated user may use, often based on assigned privilege levels or policies. It is not concerned with verifying identity; rather, it assumes the user has already been authenticated and then answers the question 'what is this user allowed to do?' Therefore, it is distinct from authentication, which is the verification step.
C
Accounting: The process of granting or denying access to network resources.
Why it fails: Accounting cannot be the process of granting or denying access because that action is the definition of authorization. In practice, accounting refers to the collection and logging of user activity data, including login and logout times, commands executed, and bandwidth consumed. This information is used for auditing, billing, compliance, and troubleshooting, and it in no way controls resource access decisions.
D
Identification: The process of logging and monitoring user activities.
Why it fails: Identification is the user's initial assertion of identity, such as typing a username or presenting a pre-shared token, before any verification occurs. Logging and monitoring user activities is called accounting, which comes after authentication and authorization and tracks what the user actually did. Representing accounting as identical to identification conflates the pre-verification claim with the post-session audit trail.

Question 11hardmultiple choice

An administrator wants to permit SSH management access but block Telnet access to a device. Which statement best reflects that design goal?

Trap 1: Telnet is preferred because it provides stronger confidentiality…

Telnet transmits credentials and session data in cleartext, so it cannot provide confidentiality at all; SSH encrypts the session, which is why the design goal blocks Telnet. The option inverts the actual protocol behaviour. Telnet would only be chosen where encryption is irrelevant, such as an isolated lab segment carrying no sensitive management traffic.

Trap 2: SSH can be used only on Layer 2 switches and not routers

SSH and Telnet are transport protocols available on both routers and switches; the platform type does not determine support. It is tempting because Layer 2 switches commonly run SSH for in-band management, yet the design goal concerns protocol selection, not device role, so this statement misstates the capability.

Trap 3: Blocking Telnet automatically disables all AAA functions

Telnet and AAA are independent features; disabling the Telnet server leaves authentication, authorisation and accounting intact for SSH and console access. It is tempting because both concern management-plane access control, but the design goal is simply to permit SSH while denying Telnet, which AAA configuration does not affect.

A
SSH is preferred because it provides encrypted remote administration, unlike Telnet
SSH encrypts the entire management session, including credentials and commands, whereas Telnet transmits them in cleartext. Permitting SSH while blocking Telnet therefore meets the design goal of secure remote administration without exposing credentials to interception on the management path.
B
Telnet is preferred because it provides stronger confidentiality than SSH
Why it fails: Telnet transmits credentials and session data in cleartext, so it cannot provide confidentiality at all; SSH encrypts the session, which is why the design goal blocks Telnet. The option inverts the actual protocol behaviour. Telnet would only be chosen where encryption is irrelevant, such as an isolated lab segment carrying no sensitive management traffic.
C
SSH can be used only on Layer 2 switches and not routers
Why it fails: SSH and Telnet are transport protocols available on both routers and switches; the platform type does not determine support. It is tempting because Layer 2 switches commonly run SSH for in-band management, yet the design goal concerns protocol selection, not device role, so this statement misstates the capability.
D
Blocking Telnet automatically disables all AAA functions
Why it fails: Telnet and AAA are independent features; disabling the Telnet server leaves authentication, authorisation and accounting intact for SSH and console access. It is tempting because both concern management-plane access control, but the design goal is simply to permit SSH while denying Telnet, which AAA configuration does not affect.

Question 12mediummulti select

Which THREE statements correctly describe the configuration of AAA with RADIUS or TACACS+ on Cisco IOS-XE?

Trap 1: RADIUS encrypts the entire packet payload, including all attributes.

RADIUS does not encrypt the entire packet; it only encrypts the password attribute (using a shared secret and MD5-based algorithm) in an Access-Request packet. Other attributes such as username, NAS-IP-Address, and authorization attributes (in Access-Accept) are transmitted in plaintext. So the claim is incorrect; RADIUS lacks the full-payload encryption that TACACS+ provides.

Trap 2: TACACS+ uses UDP as its transport protocol, while RADIUS uses TCP.

This reverses the actual transport protocols. TACACS+ uses TCP port 49 to provide a reliable, connection-oriented session, which is better for the granular control and multiple service exchanges TACACS+ supports. RADIUS, by contrast, typically uses UDP ports 1812/1813 (or 1645/1646 legacy) because it was designed for lightweight, stateless authentication and accounting transactions. The statement also incorrectly implies RADIUS uses TCP; RADIUS can be configured over TCP in some implementations (e.g., RadSec), but the standard is UDP. So the option is wrong.

Trap 3: When configuring 802.1X on IOS-XE, the switch acts as the…

In 802.1X, the switch operates as an authenticator, relaying Extensible Authentication Protocol (EAP) frames between the supplicant (client) and the authentication server (typically a RADIUS server). It does not validate credentials itself; the switch forwards the client's authentication request to a RADIUS server and then enforces the server's decision by controlling port access. While the switch can be configured to point to a local method list as a fallback in some scenarios, by default it is not the authentication server. So the statement is false.

A
RADIUS encrypts the entire packet payload, including all attributes.
Why it fails: RADIUS does not encrypt the entire packet; it only encrypts the password attribute (using a shared secret and MD5-based algorithm) in an Access-Request packet. Other attributes such as username, NAS-IP-Address, and authorization attributes (in Access-Accept) are transmitted in plaintext. So the claim is incorrect; RADIUS lacks the full-payload encryption that TACACS+ provides.
B
TACACS+ encrypts the entire body of the packet but leaves the standard TCP header unencrypted.
TACACS+ encrypts the entire payload (body) of the packet—including the authentication, authorization, and accounting attributes and fields—while the TCP header remains in clear text for transport. This provides complete confidentiality of the AAA data, including usernames, passwords, and authorization decisions. The encryption uses a shared secret key to compute an MD5-based hash to obfuscate the body, whereas RADIUS only encrypts the password attribute.
C
TACACS+ uses UDP as its transport protocol, while RADIUS uses TCP.
Why it fails: This reverses the actual transport protocols. TACACS+ uses TCP port 49 to provide a reliable, connection-oriented session, which is better for the granular control and multiple service exchanges TACACS+ supports. RADIUS, by contrast, typically uses UDP ports 1812/1813 (or 1645/1646 legacy) because it was designed for lightweight, stateless authentication and accounting transactions. The statement also incorrectly implies RADIUS uses TCP; RADIUS can be configured over TCP in some implementations (e.g., RadSec), but the standard is UDP. So the option is wrong.
D
TACACS+ separates authentication, authorization, and accounting into three distinct functions, allowing independent server configuration for each.
TACACS+ architecture cleanly delineates AAA services: authentication verifies identity, authorization determines permitted services or commands, and accounting records resource usage. This separation permits administrators to use different servers for each function or enable/disable them independently, offering more flexibility and granular security control. RADIUS does not provide this separation because authentication and authorization are combined.
E
RADIUS combines authentication and authorization into a single process, meaning an access-accept packet includes both authentication success and authorization attributes.
In RADIUS, authentication and authorization are executed together in one exchange; a single Access-Accept packet simultaneously confirms the user's identity and delivers authorization parameters (e.g., VLAN, ACL, IP address). This design reduces processing steps but makes it difficult to separate the two processes for independent server handling. By contrast, TACACS+ separates these functions.
F
When configuring 802.1X on IOS-XE, the switch acts as the authentication server and validates client credentials locally.
Why it fails: In 802.1X, the switch operates as an authenticator, relaying Extensible Authentication Protocol (EAP) frames between the supplicant (client) and the authentication server (typically a RADIUS server). It does not validate credentials itself; the switch forwards the client's authentication request to a RADIUS server and then enforces the server's decision by controlling port access. While the switch can be configured to point to a local method list as a fallback in some scenarios, by default it is not the authentication server. So the statement is false.

Read the full wireless explanation →

Question 13hardmultiple choice

A wireless client can associate to the correct corporate SSID and authenticate successfully, but receives an address from the guest network instead of the employee network. Which troubleshooting area is strongest?

Trap 1: The client must be using the wrong subnet mask manually.

A manually configured wrong subnet mask on the wireless client would prevent the host from communicating properly, but it would not cause the client to be 'assigned' to the wrong network—the client would still be in the correct VLAN and would not obtain a DHCP lease from a different subnet. This scenario describes a systematic placement into an unexpected subnet, which occurs on the network side due to faulty VLAN mapping, not a host-side static IP error. Also, the problem occurs for any client using the SSID, so it is not a per-device manual misconfiguration.

Trap 2: The AP must be missing PPP encapsulation.

PPP (Point-to-Point Protocol) encapsulation is a Layer 2 protocol used on serial WAN links, not on wireless AP-to-switch/controller connections. Even if an AP were missing PPP framing, the wireless client's ability to associate and authenticate would be unaffected because WLAN traffic is carried over 802.11 and 802.1Q VLAN trunks. The symptom of landing in the wrong subnet after successful association points to a VLAN assignment error, not an encapsulation mismatch.

Trap 3: The issue is that STP root election failed.

Spanning Tree Protocol (STP) prevents loops in a wired Ethernet topology and determines which switch ports forward traffic; it does not control how a wireless client is assigned to a VLAN or IP subnet. An STP root failure could cause broadcast storms or blocked ports, but the client would still be placed into the correct VLAN after 802.1X authentication if the WLAN mapping is intact. Here the issue is specifically a wrong logical segment assignment, which is independent of STP's role.

A
Incorrect WLAN-to-role or VLAN mapping after successful authentication.
After a wireless client successfully authenticates via methods such as 802.1X, the WLAN controller or lightweight AP maps the client to a VLAN based on the SSID's WLAN profile or RADIUS attributes like Tunnel-Private-Group-ID. If the WLAN is incorrectly bound to a guest VLAN, or the RADIUS server returns a mismatched VLAN ID, the client associates cleanly but receives an IP from the wrong subnet. This exact description matches an incorrect WLAN-to-role or VLAN mapping, which is a common configuration error in enterprise Wi-Fi.
B
The client must be using the wrong subnet mask manually.
Why it fails: A manually configured wrong subnet mask on the wireless client would prevent the host from communicating properly, but it would not cause the client to be 'assigned' to the wrong network—the client would still be in the correct VLAN and would not obtain a DHCP lease from a different subnet. This scenario describes a systematic placement into an unexpected subnet, which occurs on the network side due to faulty VLAN mapping, not a host-side static IP error. Also, the problem occurs for any client using the SSID, so it is not a per-device manual misconfiguration.
C
The AP must be missing PPP encapsulation.
Why it fails: PPP (Point-to-Point Protocol) encapsulation is a Layer 2 protocol used on serial WAN links, not on wireless AP-to-switch/controller connections. Even if an AP were missing PPP framing, the wireless client's ability to associate and authenticate would be unaffected because WLAN traffic is carried over 802.11 and 802.1Q VLAN trunks. The symptom of landing in the wrong subnet after successful association points to a VLAN assignment error, not an encapsulation mismatch.
D
The issue is that STP root election failed.
Why it fails: Spanning Tree Protocol (STP) prevents loops in a wired Ethernet topology and determines which switch ports forward traffic; it does not control how a wireless client is assigned to a VLAN or IP subnet. An STP root failure could cause broadcast storms or blocked ports, but the client would still be placed into the correct VLAN after 802.1X authentication if the WLAN mapping is intact. Here the issue is specifically a wrong logical segment assignment, which is independent of STP's role.

Read the full wireless explanation →

Question 14mediummultiple choice

Exhibit: Users report that they can see the corporate SSID but fail authentication immediately after entering credentials. Guest wireless works on the same access point. Which issue is most likely?

Exhibit

WLAN Corp uses WPA2-Enterprise
WLAN Guest uses WPA2-PSK
AP joined to WLC successfully
Recent event: AAA server unreachable

Trap 1: The AP is using the wrong channel width

Channel width controls how much spectrum an AP uses for data transmission; a mismatched width would cause poor throughput or coverage. However, it does not affect the authentication process, and clients can still associate with the SSID regardless of the channel width as long as the signal is present. The inability to authenticate on a visible SSID is an 802.1X/AAA failure, not an RF-level parameter issue.

Trap 2: The corporate SSID has a mismatched RADIUS shared secret

A mismatched RADIUS shared secret would also break enterprise authentication, but it would not make the server unreachable; the AP would still see the server at the network layer, and authentication attempts would produce an Access-Reject or silently dropped packets instead of a timeout. Since the guest SSID is operational on the same AP, the AP has connectivity, and the more fundamental failure is the AAA server's availability. This answer is wrong because the problem is an outage, not a configuration inconsistency in the shared-secret credentials.

Trap 3: The SSID must be configured as hidden

If an SSID is configured as hidden, the AP stops including the SSID in its beacons, so it disappears from normal client scan results. But the corporate SSID is already visible to users, which means it is broadcasting normally; hiding it would only prevent discovery. This option is wrong because it addresses visibility, not the authentication process, and changing the SSID broadcast status would not solve an 802.1X/AAA unreachability issue.

A
The AP is using the wrong channel width
Why it fails: Channel width controls how much spectrum an AP uses for data transmission; a mismatched width would cause poor throughput or coverage. However, it does not affect the authentication process, and clients can still associate with the SSID regardless of the channel width as long as the signal is present. The inability to authenticate on a visible SSID is an 802.1X/AAA failure, not an RF-level parameter issue.
B
The RADIUS or AAA server is unreachable for the enterprise WLAN
WPA2-Enterprise requires the AP to forward EAP frames from the client to a RADIUS/AAA server for authentication. If that server is unreachable, clients can still discover the SSID and associate at Layer 2, but the 802.1X exchange times out because no Access-Request ever receives a response. The guest WLAN is unaffected because it does not depend on AAA, isolating the fault to the enterprise WLAN's backend.
C
The corporate SSID has a mismatched RADIUS shared secret
Why it fails: A mismatched RADIUS shared secret would also break enterprise authentication, but it would not make the server unreachable; the AP would still see the server at the network layer, and authentication attempts would produce an Access-Reject or silently dropped packets instead of a timeout. Since the guest SSID is operational on the same AP, the AP has connectivity, and the more fundamental failure is the AAA server's availability. This answer is wrong because the problem is an outage, not a configuration inconsistency in the shared-secret credentials.
D
The SSID must be configured as hidden
Why it fails: If an SSID is configured as hidden, the AP stops including the SSID in its beacons, so it disappears from normal client scan results. But the corporate SSID is already visible to users, which means it is broadcasting normally; hiding it would only prevent discovery. This option is wrong because it addresses visibility, not the authentication process, and changing the SSID broadcast status would not solve an 802.1X/AAA unreachability issue.