3.0 Infrastructure Security
AAA & Device Access Security Practice Questions
TACACS+/RADIUS method lists, local fallback, and secure VTY/SSH access.
One solved question, so you can see how these are marked
What are the three functions AAA provides on an IOS device?
Authentication, Authorization, Accounting
AAA stands for Authentication (who you are), Authorization (what you are allowed to do), and Accounting (a record of what was done), each of which can be configured with independent method lists.
Every question in the set below is marked like this. The answers stay hidden until you pick one.
All 19 AAA & Device Access Security questions in this set
Answers and explanations appear when you work through the set above.
What is an AAA method list?
- A single command that enables AAA globally with no further configuration
- A named, ordered sequence of authentication or authorization methods that IOS tries in order, falling to the next method only if the previous one fails to respond (not merely rejects the user)
- The list of usernames stored in the local database
- An access list that filters which IP addresses can attempt to log in
A method list is configured as aaa authentication login VTY-AUTH group TACACS-SERVERS local. All TACACS+ servers in the group are reachable, and the user enters a wrong password. What happens?
- IOS falls back to the local database and lets the user try local credentials
- The login attempt is rejected outright; local is never tried because TACACS+ responded (with a reject), it did not fail to respond
- IOS retries the same TACACS+ group a second time before giving up
- The session is authenticated anyway because a fallback method exists
Why is TACACS+ generally preferred over RADIUS for device administration (command authorization) on network infrastructure?
- TACACS+ uses UDP, which is faster for interactive CLI sessions
- TACACS+ encrypts the entire packet body and separates authentication, authorization, and accounting cleanly, which supports full command-level authorization; RADIUS encrypts only the password field and combines authentication/authorization in a single exchange
- RADIUS cannot perform authentication at all, only accounting
- TACACS+ is an open IETF standard while RADIUS is Cisco-proprietary
Which transport protocol and port does TACACS+ use by default?
- UDP port 49
- TCP port 49
- TCP port 1812
- UDP port 1645
An engineer configures aaa new-model, defines a TACACS+ server group, and creates the method list aaa authentication login ADMIN-AUTH group ADMIN-TACACS local, but never applies it anywhere. What authenticates VTY line logins in the meantime?
- No authentication occurs and every login is accepted
- The default login behavior: with no default list defined, IOS checks the local username database, and the unapplied ADMIN-AUTH list has no effect
- The ADMIN-AUTH list is automatically applied to all lines the moment it is created
- TACACS+ is used automatically since aaa new-model was enabled
Which command applies a named AAA authentication login method list to the VTY lines?
- aaa authentication login default group tacacs+ local, entered under line configuration mode
- login authentication <list-name>, entered under line vty configuration mode
- aaa group server tacacs+ <list-name>
- ip vrf forwarding <list-name>
An engineer replaces the VTY lines' method list with one that only references a TACACS+ server group and has no local fallback, then loses IP reachability to the TACACS+ servers immediately after committing the change over a VTY session. What is the risk?
- No risk; IOS automatically reverts unreachable AAA method lists after a timeout
- A lockout risk: with no local fallback and the TACACS+ servers unreachable, no user can authenticate to the VTY lines, including the engineer who just made the change, unless console access with a separate/local method is still available
- The change only affects newly created user accounts
- TACACS+ requests will silently succeed regardless of server reachability
What is the standard safe practice for testing a new AAA method list change on VTY lines to avoid a lockout?
- Apply the change directly to all VTY lines and console at once for consistency
- Keep an active, already-authenticated session open (or use console access with a known-good fallback method) while testing the new method list on a fresh session, and confirm local fallback works before removing any prior access
- Disable AAA entirely before testing, then re-enable it once satisfied
- Always test using a RADIUS-only method list first since RADIUS cannot lock anyone out
Which command enables local username/password fallback authentication as part of an AAA method list?
- aaa authentication login LIST group tacacs+ enable
- aaa authentication login LIST group tacacs+ local
- aaa authentication login LIST group tacacs+ line
- aaa authentication login LIST group tacacs+ none
What must be true of a local username entry for it to actually work as a fallback method under an aaa authentication login LIST group tacacs+ local method list?
- The username must exist in the local database with a configured secret/password, matching the credentials attempted
- The username only needs to exist, the password field is ignored when AAA is enabled
- Local fallback works automatically even with no username commands configured
- The username must be provisioned on the TACACS+ server first
Under an aaa authentication login LIST group RADIUS-SERVERS local method list, all servers in RADIUS-SERVERS are down. Login is attempted and succeeds using a local account. What does this confirm about the design?
- That the RADIUS servers must actually be reachable, contradicting the down status
- That the fallback to local authentication is functioning correctly when the external method list is unavailable, which is the intended lockout-prevention behavior
- That AAA is misconfigured because RADIUS should always take priority
- That local accounts bypass AAA entirely and are unrelated to the method list
If an engineer configures aaa authentication login default group tacacs+ local without ever creating a named method list or applying anything under line configuration, what happens to VTY and console logins?
- Nothing changes since the default list must be explicitly applied to every line
- The default method list automatically applies to every line (console, VTY, AUX) that has not been assigned a different named method list, so those lines immediately start using TACACS+ then local
- Only the console line is affected; VTY lines are unaffected by the default list
- The default list only takes effect after a reload
Which AAA function scope determines whether a logged-in user is permitted to run a given exec-mode configuration command, separate from having already authenticated successfully?
- Accounting
- Authorization
- Authentication
- Identity mapping
Which AAA function scope is responsible for logging what commands a user executed and when a session started/stopped, for audit purposes?
- Authentication
- Authorization
- Accounting
- Provisioning
A network uses aaa authentication login default group tacacs+ local and aaa authorization exec default group tacacs+ local. A user authenticates successfully via TACACS+, but exec authorization does not succeed. What determines whether an interactive exec session is granted?
- Authentication success alone always grants an exec session regardless of authorization
- The exec authorization method list result; if the TACACS+ server denies or does not affirmatively authorize the exec session and local does not grant it either, the user can be authenticated but still refused an interactive session
- The accounting configuration determines this
- IOS defaults to granting exec access whenever aaa new-model is enabled
Two TACACS+ servers are configured under a server group with different shared secrets configured per-server using tacacs server host-level key statements, but the engineer instead configured a single global tacacs-server key value intended for both. What symptom is most likely on the server whose actual key differs from the global one?
- That server will be skipped automatically and the group will only use the matching server
- Authentication requests to that server will fail (often manifesting as repeated rejects or the method list appearing to skip straight to fallback) because the shared secret used to secure/verify the TACACS+ exchange does not match what the server expects
- The mismatched key only affects accounting records, not authentication
- IOS encrypts TACACS+ traffic without needing a shared key, so this has no effect
Login authentication is failing for all users, and the router's logs show messages consistent with the router never receiving any reply from the configured TACACS+ servers, not explicit rejects. Following an underlay-first troubleshooting order, what should be checked before assuming a AAA configuration error?
- The order of method lists in the aaa authentication login command
- Basic IP reachability from the router to the TACACS+ server addresses, and whether TCP/49 is permitted end to end (routing, ACLs, firewall)
- Whether the username database has the right privilege levels assigned
- Whether the enable secret is configured
An engineer wants console-line authentication to always use the local database regardless of what happens with TACACS+ elsewhere on the box, while VTY lines use TACACS+ with local fallback. What is the correct approach?
- This cannot be done; all lines must share the same method list
- Define two separate named method lists, for example aaa authentication login CONSOLE-AUTH local and aaa authentication login VTY-AUTH group tacacs+ local, then apply CONSOLE-AUTH to the console line and VTY-AUTH to the VTY lines respectively
- Configure aaa authentication login default local and rely on it applying only to the console
- Use aaa authorization instead of aaa authentication to separate console and VTY behavior
For consistent operational behavior across a network, why is it considered a best practice to use the same source interface for TACACS+/RADIUS traffic on every router, such as with ip tacacs source-interface Loopback0?
- It is required for TACACS+ to function at all, unlike RADIUS
- It ensures the AAA server sees a stable, predictable source address per device regardless of which physical/egress interface is used, which matters for ACLs on the AAA server side and for consistent device identification in logs
- It changes which authentication method is attempted first
- It automatically enables command accounting