A county network team configures IOS AAA on the same civic border router for both 802.1X-style network access ideas and VTY device administration. For ENARSI infrastructure-security troubleshooting, which AAA context is the primary focus when operators cannot enter privileged EXEC on the router?
Select an answer to reveal the explanation.
Short Explanation
Think two different badge readers: one for users joining the LAN, one for admins logging into the router itself. When the privileged shell won't open, you're troubleshooting the device-admin AAA path, not the campus network-access story.
Full Explanation
When privileged EXEC fails on a civic border router that also hosts campus-style access ideas, ENARSI infrastructure-security troubleshooting centers on device-administration AAA—the login, enable, and command authorization/accounting path that guards the router control plane—not on end-station network-access AAA. The correct focus works because VTY/console privileged access is authenticated and authorized by method lists bound to lines and enable, often via TACACS+/RADIUS device-admin profiles. A failed enable or exec authorization is a device-admin failure mode even if 802.1X or similar ideas exist elsewhere in the same civic design narrative. Claiming only 802.1X RADIUS for campus switch ports is the primary focus fails because ENARSI does cover router administrative AAA; port-based network access does not grant or deny privileged EXEC on the router shell. Limiting the problem to FlexVPN IPsec remote-access AAA profiles fails conceptually because VPN user AAA is a different context from interactive device administration, and device-admin AAA is not deferred to ENSDWI-only study. Treating only SNMPv3 user groups as the answer fails because SNMP agent access control is not the AAA method-list path that opens or blocks the interactive privileged shell. Exam caveat: both network-access and device-admin AAA may share RADIUS/TACACS servers, so shared server health can confuse which context is broken—always map the failing CLI stage (login vs enable vs command auth) to the device-admin lists. Operational check: reproduce the failed privileged entry, note whether authentication or authorization fails, then verify aaa new-model, the line/enable method lists, TACACS+/RADIUS reachability for the management path, and server authorization for the admin identity before chasing campus 802.1X.