Network Access Device Administration practice questions

To assign the device to a specific group

Why it fails: NDGs are used for grouping, not the shared secret.

To encrypt the entire packet header

Why it fails: The header is not encrypted; the body is.

To enable SSL/TLS encryption for the session

Why it fails: TACACS+ does not use TLS by default; the secret provides MD5/HMAC integrity.

In the Command Set definition

Why it fails: Command sets define command permissions, not device scoping.

In the TACACS+ Profile settings

Why it fails: Profiles define authorization attributes, not device matching.

In the Global System Settings

Why it fails: Global settings do not support granular policy-based device matching.

The switch is not configured for 'aaa authorization commands'

Why it fails: The switch is querying ISE, so authorization is configured.

The shell profile lacks privilege level configuration

Why it fails: Privilege levels allow login but not command execution if commands are restricted.

The user is not in the correct Identity Store

Why it fails: Authentication succeeded, so the identity store already resolved the user; a wrong store would have failed login, not command execution. The tempting fit is that identity stores map users to groups, and a misplaced user would lack authorisation — correct when TACACS+ returns an authorisation failure at login itself.

RADIUS allows command-level authorization

Why it fails: RADIUS is typically used for authentication and authorization of sessions, not granular command sets.

TACACS+ is an open standard protocol

Why it fails: TACACS+ is a Cisco-proprietary protocol (RFC 1492 is older, Cisco expanded it).

TACACS+ uses UDP port 49

Why it fails: TACACS+ uses TCP port 49.

Set the 'Default Command' attribute to 'permit'

Why it fails: A Command Set only defines which commands are permitted; the Default Command attribute governs what happens to commands not listed, so setting it to 'permit' grants everything else, defeating read-only. It is tempting because it appears to control authorisation, but it is the fallback action, not the read-only mechanism.

Disable command authorization on the switch

Why it fails: Disabling command authorization removes the check that matches entered commands against the Command Set, so junior admins could run anything. Tempting because it appears to simplify access, yet authorisation must stay enabled for the Command Set to restrict them to show commands.

Assign a Shell Profile with privilege level 15

Why it fails: Privilege level 15 grants full administrative rights, directly contradicting read-only access. Tempting because a Shell Profile is genuinely required to bind the Command Set to the junior admins, but that profile must carry a low privilege level, not 15.

Permit 'show' only

Why it fails: This allows all show commands including those with sensitive info.

Deny 'show' commands

Why it fails: This blocks all show commands.

Permit 'show' and deny all arguments

Why it fails: This is not a valid syntax.

Only one

Why it fails: This would create a single point of failure.

None, TACACS+ doesn't support redundancy

Why it fails: It supports multiple server definitions.

Exactly two

Why it fails: You can configure more than two.

Shell Profile Name

Why it fails: Shell profiles are results, not conditions.

Command Set Name

Why it fails: Command sets are results, not conditions.

Device Firmware Version

Why it fails: Firmware version is not a direct policy condition.

Set the timeout for the command

Why it fails: Timeouts are handled in the shell or device.

Define the default privilege level

Why it fails: That is in the Shell Profile.

The user password is incorrect

Why it fails: This would cause an authentication failure, not authorization.

The ISE server is busy

Why it fails: This would cause a timeout, not an authorization failure.

Enable 'Command Authorization' globally on the switch without defining a command set.

Why it fails: Without a command set in ISE, the switch will not know which commands are permitted or denied.

Use an Authorization Profile to define the command set.

Why it fails: Command sets are separate objects from authorization profiles in TACACS+ policies.

Select 'Deny' and add 'show' in the excluded commands list.

Why it fails: This would deny all commands except those listed, which is the opposite of the requirement.

null

Why it fails: null

The shared secret is incorrect.

Why it fails: Incorrect shared secret would prevent initial login.

The Network Access Device is not configured with 'aaa authorization commands'.

Why it fails: Without this, the switch wouldn't even send authorization requests for commands.

null

Why it fails: null

The Shell Profile has a privilege level of 0.

Why it fails: Privilege level 0 allows only very basic commands, but wouldn't block all commands unless specifically restricted.

Auto-command

Why it fails: Auto-command runs a fixed command automatically at session start; it does not govern idle timeouts. It is tempting because it shapes session behaviour, but it would be correct when forcing a specific CLI command on login, whereas the exec-timeout attribute controls inactivity duration.

Session Time

Why it fails: Session Time is not a standard attribute for inactivity in Shell Profiles.

Privilege Level

Why it fails: Privilege Level governs which commands an authenticated session may execute, not session duration; it cannot enforce an idle timeout. It is tempting because privilege levels are the standard TACACS+ authorisation attribute for restricting administrative scope, and would be correct when the requirement is limiting what a user can run rather than how long they stay connected.

Command Sets are applied at the Authentication Policy level.

Why it fails: Command Sets bind to authorisation profiles, which the authorisation policy then references; they are never attached directly at the authentication policy level, where only identity sources and conditions are evaluated. It is tempting because authentication precedes authorisation, so the policy layer appears a logical home for command restrictions.

Command Sets are mandatory for all RADIUS authentication sessions.

Why it fails: Command Sets apply only to TACACS+ command authorisation, not RADIUS authentication, which carries no per-command attributes. It tempts administrators who assume every authorisation policy needs a command set, but RADIUS sessions require only authorisation profiles and policy sets.

Command Sets automatically include all 'show' commands by default.

Why it fails: Command Sets contain only the commands an administrator explicitly adds, so an empty set permits nothing until entries are defined; no implicit 'show' allowance exists. The appeal is that read-only commands feel harmless, yet ISE enforces the configured list literally, which is why default permit-all sets are sometimes created manually.

Enable Device Admin service on the network device definition.

Why it fails: Enabling Device Admin service is necessary for the device to be authorized for TACACS+ commands, but it is not sufficient to restrict commands to only 'show'. It is a prerequisite for TACACS+ communication, but the actual command restriction is enforced by the Command Set. This option alone does not meet the requirement.

Configure a Shell Profile with the 'priv-lvl' attribute set to 15.

Why it fails: A Shell Profile with privilege level 15 grants full administrative access, which contradicts the goal of restricting users to only 'show' commands. While a Shell Profile may be needed for other attributes, setting privilege level 15 would allow configuration commands. The scenario requires limiting commands, not elevating privileges.

Create a TACACS+ Command Set that denies all commands and then permits 'show' commands.

Why it fails: The order of rules in a Command Set matters. Typically, a permit rule for 'show' should come before a deny-all rule. If a deny-all is placed first, it would block all commands, including 'show'. While the concept of denying all and permitting 'show' is correct, the order is critical. The option as stated implies a deny-all first, which is incorrect.

aaa authentication login default local group tacacs+

Why it fails: This command attempts local authentication first and then TACACS+ if local fails. It reverses the desired order; the administrator wants TACACS+ to be primary and local as fallback. Using local first would bypass centralized authentication for valid local users, defeating the purpose of TACACS+ integration with ISE.

tacacs-server host 10.1.1.1 fallback local

Why it fails: The 'tacacs-server host' command defines a TACACS+ server address, but there is no 'fallback local' keyword in Cisco IOS. Fallback behavior is configured through AAA method lists, not on the server host command. This option is invalid syntax and would not achieve the required fallback to local authentication.

aaa authentication login default group tacacs+ none

Why it fails: The 'none' keyword means that if TACACS+ authentication fails or is unreachable, no authentication is required, allowing access without credentials. This is a severe security risk and does not provide fallback to the local database. It would allow unauthorized access if the TACACS+ server is down, which is not the intended behavior.

aaa authentication login default group tacacs+ local

Why it fails: This command configures AAA authentication to use a TACACS+ server group, but it does not define the TACACS+ server itself or set the shared secret. Without the server definition and key, authentication will fail. This command is part of the overall AAA configuration but does not fulfill the requirement of setting the shared secret.

radius server ISE-SERVER address ipv4 10.1.1.1 key C1sco123

Why it fails: This command configures a RADIUS server, not TACACS+. The scenario requires TACACS+ for device administration. Using RADIUS would not provide the command authorization and accounting features that TACACS+ offers. Additionally, the shared secret key would be configured under the RADIUS server context, which is incorrect for TACACS+.

tacacs-server host 10.1.1.1 key C1sco123

Why it fails: This command is used in older Cisco IOS versions to configure a TACACS+ server globally, but it does not create a named server group. While it may work in some contexts, the newer recommended approach is to define a named TACACS+ server and then reference it in an AAA group. This command alone does not provide the flexibility of named servers.

Operations > TACACS Livelogs

Why it fails: TACACS Livelogs displays live authentication and authorisation activity for troubleshooting, and contains no configuration objects. It is tempting because device administration appears in TACACS-related screens, and Livelogs would be the right place to diagnose failed device-admin logins, but Network Device Groups are defined under Administration > Network Resources.

Administration > Identity Management

Why it fails: Identity Management holds internal and external identity stores, users and identity groups, not network devices. It is tempting because the word 'group' appears in both, and this path would be correct for creating a user identity group, but Network Device Groups are defined under Administration > Network Resources > Network Device Groups.

Policy > Policy Elements > Results

Why it fails: Policy Elements > Results holds authorisation profiles, downloadable ACLs and other result objects applied after a policy match. It is tempting because device groups are referenced inside policy conditions, and this path would be correct for creating an authorisation profile, but Network Device Groups themselves live under Administration > Network Resources.

Set 'Attribute' to 'priv-lvl=15' in custom attributes

Why it fails: Shell profiles assign privilege levels through the 'priv-lvl' attribute, but the value must be a bare number such as 15, not the string 'priv-lvl=15'; the attribute name is already the key. It is tempting because custom attributes do carry key-value pairs, and this format would be correct in a RADIUS reply.

Set the 'Auto-Command' to 'enable 15'

Why it fails: Auto-Command executes a single command after login but does not itself assign the user's privilege level; authorisation comes from the shell profile's privilege setting. Auto-Command suits forcing a specific action such as showing a banner, whereas privilege level 15 requires the profile's default privilege attribute.

Enable 'Maximum Privilege' in the command set

Why it fails: Maximum Privilege caps the highest level a command set may grant; it does not place the user at level 15 on login. It is intended to bound escalation for restricted administrators, whereas immediate level 15 requires the shell profile's default privilege attribute set to 15.

System Summary Dashboard

Why it fails: The System Summary Dashboard shows node health, CPU, memory and service status, not per-request TACACS+ policy match details. It tempts because it is the first place administrators look when ISE misbehaves, and it would be correct for confirming overall deployment health rather than tracing an individual authentication attempt.

Endpoint Context Visibility

Why it fails: Endpoint Context Visibility displays profiled attributes and posture for endpoints, not TACACS+ request or policy evaluation details. It tempts because it is the natural place to verify device identity data, and it would be correct when investigating incorrect endpoint profiling rather than diagnosing why a TACACS+ authentication was rejected.

RADIUS Livelogs

Why it fails: Livelogs streams RADIUS authentication and authorisation transactions; TACACS+ requests are recorded in the TACACS+ live logs instead, so the policy match result never appears here. It tempts because Livelogs is the standard real-time troubleshooting view, and it would be the right choice when diagnosing a RADIUS authentication failure.