Which Command Should the Administrator Use Practice Questions

Enable Guest VLAN assignment.

Why it fails: Guest VLAN assignment places unauthenticated guests into a segregated VLAN; it does not grant access to an internal printer. It is tempting because it is the standard first step for guest onboarding, and it would be correct when isolating guests before they authenticate through the portal.

Modify the Redirect ACL on the switch.

Why it fails: The redirect ACL governs which traffic ISE diverts to the guest portal for web authentication; it does not permit printer access. It is tempting because redirect ACLs control guest traffic flow, and it would be correct when defining which destinations trigger portal redirection.

Configure a port-based ACL on the switch interface.

Why it fails: A port-based ACL filters all traffic on the switch interface, including the guest's own permitted flows, rather than applying per-user authorisation. It is tempting because ACLs do restrict access, and it would be correct for static interface restrictions unrelated to ISE identity-based authorisation results.

Post-Posture Authorization Rule

Why it fails: Post-Posture Authorization Rules define the network access granted after a posture assessment completes, not the remediation link shown to users. It is tempting because authorisation rules govern post-assessment outcomes, but the download URL is delivered by the posture requirement's remediation configuration.

Client Provisioning Policy

Why it fails: Client Provisioning Policies deliver supplicant, agent and compliance software to endpoints, but they are applied during initial onboarding, not triggered by a failed posture check. It is tempting because provisioning supplies the required software, yet the remediation link on posture failure is set in the posture requirement.

Posture Requirement

Why it fails: The Posture Requirement defines the check itself and its remediation actions, but the download link is configured within the Client Provisioning Policy that the requirement references. It is tempting because requirements drive remediation, yet the actual URL field lives in the provisioning policy.

Cisco IOS syslog

Why it fails: IOS syslog on the ASA records connection, interface and VPN session events, but posture evaluation happens on the endpoint via the posture module and ISE. Syslog is correct for headend and tunnel faults; compliance verdicts need client-side DART logs and ISE posture reports.

AnyConnect VPN Gateway logs

Why it fails: Gateway logs record tunnel establishment, authentication and session events, not the endpoint's posture assessment results. They are the right source for connection and AAA failures, whereas compliance-check failures require the AnyConnect client's posture module and DART bundle on the endpoint itself.

It defaults to local switch authentication

Why it fails: ISE never delegates an unmatched TACACS+ authorisation decision back to the network device's local database; the device already forwarded the request and awaits a response. Unmatched requests hit the default authorisation policy, which returns a deny or a configured shell profile. Local fallback applies only when the ISE node is unreachable.

It prompts the user to select a profile

Why it fails: ISE cannot interactively prompt a TACACS+ client to choose a profile; the protocol exchanges attribute-value pairs, not menus. Unmatched authorisation requests instead fall through to the default policy result, typically a deny. Prompting belongs to web portals or guest flows, not device administration.

It permits access with default privileges

Why it fails: Cisco ISE denies TACACS+ authorisation requests that match no policy, returning a failure rather than granting access. It is tempting to assume a permissive default mirrors some AAA behaviours, but TACACS+ authorisation defaults to deny, so unmatched requests never receive default privileges.

The agent automatically remediates the issue

Why it fails: Automatic remediation occurs only when a remediation action is explicitly configured in the posture policy; with none defined, the agent has nothing to execute. It is tempting because posture agents do remediate, but that behaviour is policy-driven, so the endpoint simply stays non-compliant.

The device is granted full access

Why it fails: Full access is granted only when the posture result is Compliant; a Non-Compliant endpoint without remediation remains restricted by the authorisation policy. It is tempting because no remediation might suggest no enforcement, yet the compliance verdict itself drives the access decision, not the presence of remediation.

The posture agent crashes

Why it fails: Posture assessment never crashes the agent; the agent simply reports the compliance result to the policy engine. It is tempting because a missing remediation action feels like an unhandled error, but the actual outcome is that the endpoint remains non-compliant and the authorisation decision proceeds without remediation.

Checking the Network Device Group membership list.

Why it fails: Network Device Group membership is static configuration data held on the PSN; it confirms how a device is classified, not whether any TACACS+ packet arrived. It would be the right check when troubleshooting authorisation policy matching for a known device, but it cannot evidence live request receipt.

Viewing the Policy Set order of precedence.

Why it fails: Policy set order of precedence governs which authorisation policy matches a request; it reveals nothing about whether packets arrive at the PSN. It is tempting because policy misordering causes authentication failures, and checking precedence would be correct when troubleshooting why a request is matched by the wrong rule.

Checking the switch console logs for AAA server status.

Why it fails: Switch console logs record the device's own AAA server status and any local timeout or unreachable messages, which reflects the client's view rather than proof the PSN received the request. Console logging is the correct place to confirm the device is configured to send TACACS+ to the intended server.

View the Network Device list

Why it fails: The Network Device list only shows configured devices and their definitions; it records no live authentication traffic, so it cannot prove requests arrive. It is tempting because a missing or misconfigured device entry is a common cause of ignored TACACS+ requests, making this the right check when ISE rejects traffic from an unknown NAD.

Run a packet capture on the switch

Why it fails: A capture on the switch shows packets leaving the switch, not whether ISE received or processed them, so it cannot confirm ISE-side receipt. It is tempting because captures diagnose whether the switch sends anything at all, which is the correct approach when troubleshooting a client that appears silent.

Check the System Summary

Why it fails: System Summary shows node health, CPU, and service status, not per-device authentication traffic, so it cannot confirm requests from one switch. It is tempting as a general ISE health dashboard, and would be the right place to check overall deployment status or service availability rather than TACACS+ activity.

Policy distribution

Why it fails: Policy distribution is a Configuration persona function, pushing policy XML to Cisco ISE nodes; the MnT persona instead collects logs and runs reports. It tempts because policy deployment does touch every node, yet the question asks which persona owns that task, and distribution sits with Policy Administration, not monitoring.

RADIUS authentication

Why it fails: RADIUS authentication is handled by the Policy Service persona, which processes access requests against policy sets; MnT passively records and reports on those authentications. It tempts because MnT dashboards display live RADIUS logs, yet the persona performing authentication is Policy Service, not Monitoring and Troubleshooting.

Endpoint profiling probe

Why it fails: Endpoint profiling probes belong to the Profiling persona, which gathers attributes to classify endpoints; MnT only consumes the resulting logs and alarms. It tempts because profiling data appears in MnT reports, but the probe itself is a separate persona service, so it is not an MnT function.

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.

Authentication Policy

Why it fails: Authentication Policy governs authentication methods and protocols, not MAC OUI filtering. OUI restrictions belong in the MAB configuration under endpoint identity groups or global settings; Authentication Policy is correct when controlling which authentication methods, such as EAP-TLS, are permitted.

Identity Source Sequence

Why it fails: Identity Source Sequence defines the order in which identity stores are queried during authentication, not which MAC addresses may connect. OUI filtering sits in the MAB endpoint configuration; an Identity Source Sequence is correct when directing lookups across multiple identity stores.

Authorization Profile

Why it fails: An authorization profile defines the attributes returned to the network access device after authentication succeeds, such as VLAN or dACL; it cannot filter which MAC OUI addresses are permitted. OUI allow-listing is enforced by an identity policy or MAB service configuration, so this option misplaces the control.

Authentication Policy

Why it fails: Authentication Policy governs authentication behaviour such as allowed methods and MFA, not device posture evaluation. It is tempting because it is a policy condition area, but it would be correct when restricting how users authenticate rather than whether their device meets compliance requirements.

Endpoint Group

Why it fails: Posture status is evaluated by Conditional Access in Microsoft Entra ID, not by an endpoint group, which merely scopes users or devices for assignment. Endpoint groups are tempting because grouping devices feels like the natural place to express compliance state, and they would be correct for targeting policy at a device collection.

Identity Source

Why it fails: Identity Source defines where user identities originate, such as an identity store or directory, and carries no device compliance state. It is tempting because it appears as a policy condition, and it would be correct when authorising access based on which repository authenticated the user.

Policy > Policy Elements > Results > Certificate Templates

Why it fails: Certificate Templates define key usage, validity and SAN settings applied when ISE builds a certificate request; they hold configuration, not transaction logs. This is the correct place to fix a template misconfiguration, but not to trace why the CA rejected issuance.

Operations > RADIUS Livelog

Why it fails: The RADIUS Livelog records authentication and authorisation exchanges between the NAD and Cisco ISE, so it shows nothing about the CA's certificate signing response. It is the correct place when troubleshooting 802.1X authentication failures rather than certificate issuance.

Administration > System > Certificates > Certificate Signing Requests

Why it fails: The Certificate Signing Requests page lists pending CSRs awaiting manual approval; it does not log the CA interaction or its error response. It is the right place when a CSR is stuck awaiting approval, not when issuance itself fails after submission.

Dashboard > Licensing

Why it fails: Licensing status and consumption sit under Administration > System > Licensing, not a Dashboard view; the Dashboard shows health and alarms. It is tempting because dashboards commonly surface summary counters, and licensing totals look like such a counter.

Policy > Licensing

Why it fails: Policy is where policy sets, authorisation profiles and conditions live, not licence counters. It is tempting because licensing governs which policy features you may configure, so the two feel related, but no consumption figures appear there.

Operations > Licensing

Why it fails: Operations holds live sessions, alarms and troubleshooting tools such as RADIUS live logs, not licence consumption. It is tempting because Operations is the natural place to check deployment status, and licence state feels like operational health.

catalina.out

Why it fails: catalina.out captures the Tomcat servlet container's stdout and stderr, including deployment and startup errors, but not the PSN's configuration synchronisation with the primary node. It is tempting because Tomcat faults can stall services, and it would be the right choice when diagnosing web-interface or deployment failures rather than sync issues.

radius.log

Why it fails: radius.log records authentication and authorisation request handling, not configuration replication between PAN and PSN. It tempts when the PSN appears to serve requests incorrectly, but a PSN failing to receive policy updates points to the ADE-OS synchronisation logs.

prrt-server.log

Why it fails: prrt-server.log records pxGrid and REST-based service interactions, not the PSN's configuration synchronisation with the PAN, which is written to the application server or ISE sync logs. It is tempting because PRRT troubleshooting genuinely uses this file when diagnosing real-time threat-context or pxGrid client failures.

Administration > System > Settings > Profiling Feed

Why it fails: The Profiling Feed setting controls external feed subscription and update, not which ISE nodes execute the NMAP scan probe. It tempts because it is profiling-related, but per-node probe activation is configured under Administration > System > Deployment.

Policy > Profiling > Profiling Policies

Why it fails: Profiling Policies define which probe conditions and matching rules apply, not which nodes run the NMAP scan. It tempts because profiling configuration lives there, but node-specific probe enablement sits under Administration > System > Deployment.

Policy > Policy Elements > Results

Why it fails: Policy > Policy Elements > Results holds authorisation profiles, not probe configuration. The NMAP scan probe is assigned per node under Administration > System > Deployment, where each ISE node's profiling settings are defined. Results is tempting because authorisation profiles do control which profiling policies apply to endpoints, but that governs endpoint classification, not which node runs the scan.