Troubleshooting practice questions

PAN and PSN on separate nodes

Why it fails: Standalone means PAN, PSN and Monitoring node roles all run on one node; separating PAN and PSN describes a distributed deployment instead. It tempts because splitting roles across nodes is a genuine Cisco ISE design, but that distributed model is the alternative to Standalone, not its definition.

Only PSN role is active

Why it fails: Standalone requires all three roles — PAN, PSN and Monitoring — active on one node, so restricting to PSN alone misstates the model. It tempts because single-node deployments do exist, but that is the Standalone model itself, where every role runs together, not a PSN-only configuration.

Multiple nodes in a cluster

Why it fails: A cluster by definition contains multiple nodes sharing configuration and policy, whereas Standalone runs a single node managing its own services and data. It is tempting because clustered and standalone nodes run the same software, but the distinguishing axis is node count and shared configuration, not role.

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.

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.

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.

Enable Auto-Login

Why it fails: Auto-Login accepts stored credentials to skip the login form; it does not cache the client MAC address. It is tempting because it sounds like remembering a client, but it would be correct where returning users should be authenticated automatically from saved credentials rather than by MAC.

Enable Guest Flow Bypass

Why it fails: Guest Flow Bypass skips the portal entirely for returning clients, so it never caches the MAC; caching is governed by the MAC caching setting itself. It is tempting because bypass relates to returning clients, but it would be correct where clients should connect without any portal interaction.

Enable Device Registration

Why it fails: Device Registration enrols endpoints for posture or identity checks and does not control MAC address caching in the guest flow. It is tempting because registration implies remembering a device, but it would be the right choice when endpoints must be onboarded and profiled rather than cached for portal bypass.

Verify the dACL configuration

Why it fails: dACLs enforce permissions on the enforcement device after SGTs arrive; they do not affect SGT embedding within SXP. Verifying dACLs suits troubleshooting traffic filtering on a switch or firewall, not the SXP peer relationship carrying the tag.

Verify the RADIUS shared secret

Why it fails: The RADIUS shared secret authenticates the NAD-to-ISE conversation; it does not control whether SGTs are inserted into SXP messages. Checking it suits debugging RADIUS authentication or accounting failures, not SXP peer establishment and SGT propagation.

Verify the EAP protocol version

Why it fails: EAP version governs authentication negotiation between supplicant and authenticator, not SGT carriage. SXP encapsulates SGT-to-IP bindings in its own message payload, independent of EAP. EAP version matters when troubleshooting 802.1X authentication failures, such as supplicants negotiating EAP-TLS versus PEAP, where mismatched methods break the authentication exchange.

Increase the SNMP polling interval.

Why it fails: SNMP polling governs post-profiling attribute collection, not the DHCP-based initial profile assignment, so lengthening the interval changes nothing while the device sits in Unknown. Tuning polling intervals is tempting for reducing load or capturing slow-changing attributes, and would be correct if profiling succeeded but attributes lagged.

Delete the endpoint from the database.

Why it fails: Deleting the endpoint discards the profiling evidence rather than diagnosing why DHCP packets fail to advance the device past Unknown; the endpoint re-registers and stalls identically. Deletion is tempting as remediation for stale or corrupted records, and would be right once profiling data is confirmed corrupt and a clean re-onboard is intended.

Restart the ISE node services.

Why it fails: Restarting ISE services is disruptive and does not diagnose why the profile remains Unknown; the DHCP probe succeeding points to a later stage such as profiling policy or the endpoint database lookup. It is tempting as a quick fix, and would be reasonable only after logs identify a stuck service.

Distributed MnTs across all WAN sites

Why it fails: MnT nodes must be centralised because replication between distributed MnTs generates heavy WAN traffic and risks inconsistent logging data. Distributing them is tempting when each site needs local visibility, but ISE requires a single primary MnT with optional secondary at the same data centre.

Always place MnT in the cloud

Why it fails: ISE MnT nodes run as on-premises appliances or VMs; no cloud-hosted MnT deployment model exists. Cloud placement appeals when an organisation wants to avoid data-centre footprint, but that scenario calls for centralised on-premises MnT with adequate WAN bandwidth.

Disable logging for remote sites

Why it fails: Disabling logging removes the accounting and audit data that MnT nodes exist to store, breaking compliance and troubleshooting. It tempts when WAN bandwidth is constrained, but the correct remedy is centralising MnT and sizing the WAN link, not suppressing logs.

Restart the Active Directory domain controller

Why it fails: Restarting the domain controller addresses authentication and directory replication faults, not the redirect flow. BYOD redirection depends on the guest portal, DHCP and DNS reachability, so a controller reboot changes nothing. It would be correct when domain logon or replication is failing.

Re-configure the DHCP server

Why it fails: DHCP scope options such as DNS server and default gateway are what direct a BYOD client to the portal; misconfigured options break redirection. Reconfiguring the server is therefore a valid troubleshooting step, not an incorrect one, so it does not belong in this answer set.

Change the switch model

Why it fails: Swapping the switch model alters hardware capacity and port configuration, which does not affect portal redirection logic. The failure lies in DHCP, DNS or the portal service itself. Changing switches would be correct when the device cannot provide required VLAN or PoE capabilities.

The endpoint will be profiled based on the MAC OUI only.

Why it fails: MAC OUI identifies only the hardware vendor, not the device type, so phones would not be correctly profiled as IP phones. It is tempting because OUI matching is a genuine profiling condition and would be correct if the goal were merely to classify endpoints by manufacturer rather than identify phone models.

The SNMP trap probe will still work.

Why it fails: Traps are push-based, but queries for detailed CDP data will fail.

ISE will automatically update the community string on the switch.

Why it fails: ISE has no mechanism to push SNMP community strings to switches; it only reads via SNMP, so the mismatch persists until an administrator corrects it manually. Automatic remediation is tempting because ISE can push other configurations, such as downloadable ACLs, and would apply if the requirement involved those rather than SNMP credentials.

Authentication Policy

Why it fails: Authentication Policy records the identity source and authentication result, not the authorisation rule. It is tempting because policy naming suggests rule matching, but authorisation rules sit within authorisation policy sets; the Authorization Policy column shows the matched authorisation rule, which is what the stem asks for.

Policy Set

Why it fails: Policy Set identifies the top-level policy set that processed the request, not the individual authorisation rule inside it. It is tempting because policy sets contain rules, but the stem asks for the specific matched rule, which appears in the Authorization Policy column.

Result

Why it fails: The Result column shows the final authorisation outcome (Permit or Deny) rather than which rule produced it. It is tempting because a failed authorisation is visible there, but Result gives no rule identity; the Authorization Policy column names the specific matched rule needed for troubleshooting.

The ISE Policy Set has 'Deny' as the default

Why it fails: A Policy Set default of Deny applies only when no rule matches the request; a matching rule with a Command Set permitting the command would still authorise it. It is tempting because default-deny behaviour does block unmatched sessions, but the stem states the Command Set already contains Permit, so the failure lies in matching or command-set assignment.

The user is in the wrong AD group

Why it fails: Group membership affects which authorisation policy or command set the admin matches, but the stem already establishes that a Command Set with Permit exists and is presumably assigned. It is tempting because wrong group placement commonly causes authorisation failures, yet the question asks why a permitted command still fails, which points to command-set configuration.

The TACACS+ shared secret is incorrect

Why it fails: An incorrect TACACS+ shared secret breaks authentication between the network device and ISE, so the admin session fails before any authorisation policy is evaluated. It is tempting because secret mismatches do cause login failures, but here the admin authenticates successfully and only one command is refused, which points to command-set or policy-set evaluation instead.

Re-register the device.

Why it fails: Re-registering re-runs profiling, but the misclassification stems from the endpoint's profiling attributes, so the device would simply be re-identified as a Cisco IP Phone again. Re-registration suits onboarding a genuinely new endpoint or recovering a stale identity, not correcting an existing device's profile.

Delete all profiling policies.

Why it fails: Deleting all profiling policies removes the very rules that classify endpoints, wiping correct profiles and forcing every device to reprofile, which does not fix the misclassification. It is tempting as a clean slate, and it would be correct when policies are corrupt or conflicting across many endpoints.

Restart the ISE node.

Why it fails: Restarting the ISE node interrupts authentication and profiling for all users while leaving the misclassification cause untouched; the wrong profile simply reapplies. It is tempting because restarts clear transient faults, and it would be correct for a hung service or stuck process, not a profiling logic error.

Monitoring > Reports > TACACS

Why it fails: Monitoring > Reports > TACACS holds authentication and authorisation reports, not the accounting log viewer. It is tempting because TACACS+ reporting lives there, but accounting records are viewed under Operations > TACACS > Accounting, which is the dedicated location.

Administration > System > Logging

Why it fails: Administration > System > Logging configures logging levels and targets, not TACACS+ accounting records. It is tempting as the general logging area, but accounting logs are viewed under Operations > TACACS > Accounting, so this path holds no session records.

Policy > Policy Elements

Why it fails: Policy > Policy Elements defines authorisation profiles, command sets and conditions, not accounting records. It is tempting because TACACS+ policy governs device administration, but accounting logs are viewed under Operations > TACACS > Accounting, which stores the session data.

Monitoring -> Alarms

Why it fails: Alarms report threshold breaches and syslog severity events, not the RADIUS attributes returned in an Access-Accept, so they cannot show the VLAN value sent to the NAD. Alarms suit alerting on failed authentications or endpoint posture failures, not inspecting per-session authorisation payloads.

Policy Simulation

Why it fails: Policy Simulation evaluates a hypothetical session against policy and shows the resulting authorisation profile, but it does not display the live attributes actually transmitted to the NAD for a real session. It suits pre-deployment testing of rule changes, not confirming what a specific production authentication returned.

TCP Dump

Why it fails: TCP Dump captures raw packets on an ISE interface, but encrypted RADIUS attributes and the absence of policy-evaluation context make the returned VLAN value hard to isolate. It suits diagnosing reachability, dropped RADIUS requests or certificate exchange failures, not verifying which authorisation result policy produced.

The user password has expired

Why it fails: 'Internal CA Error' indicates ISE's internal certificate authority failed to issue the certificate, typically due to a misconfigured or expired CA certificate chain. An expired user password would surface as an authentication failure, not a CA-side issuance error, though both block provisioning.

The client certificate is too small

Why it fails: 'Internal CA Error' originates from ISE's internal certificate authority during issuance, so key size is irrelevant; the CA rejects or fails before any size check matters. It tempts because certificate properties do affect enrolment, but this error points to CA configuration, not client key length.

The network switch is blocking port 443

Why it fails: 'Internal CA Error' is generated by ISE's internal certificate authority when it cannot issue the certificate, so transport blocking is unrelated; port 443 blocking would produce a connectivity or timeout failure instead. It tempts because provisioning uses HTTPS, but the error names the CA, not the network path.

Administration > System > Logging

Why it fails: Administration > System > Logging configures logging targets and levels, not live authentication events. Live authentications and profiler attribute results appear under Operations > RADIUS > Live Logs. It is tempting because both are logging-related menus, but only Live Logs shows received attributes in real time.

Policy > Profiling > Profiling Policies

Why it fails: Profiling Policies only define the conditions and rules that assign endpoints to profiles; they do not display live probe or authentication traffic. It is tempting because the fault lies in a profiler condition, but this page is for authoring conditions, not verifying whether ISE actually receives the attribute.

Context Visibility > Endpoints

Why it fails: Context Visibility shows endpoint attributes and posture, not the live RADIUS authentication or profiler probe logs where received attributes are recorded. It is tempting because it displays profiled endpoint data, and would be right for auditing endpoint attribute accuracy after profiling has already succeeded.

Change the posture policy to use a file condition instead of a registry condition, as file checks are more reliable.

Why it fails: Switching to a file condition does not address the specific requirement of checking a registry key. File conditions check for file existence, version, or hash, not registry values. This would not validate the intended registry setting and could introduce new compliance gaps. The registry condition is appropriate; it just needs correct configuration.

Reinstall the AnyConnect Posture module on the affected endpoints to ensure the latest version is used.

Why it fails: The scenario states the AnyConnect Posture module is installed and communicating with ISE. Reinstalling is unnecessary and time-consuming. The issue is not with the agent's presence or version but with the posture condition evaluation. Reinstallation would not change how the registry condition is evaluated.

Restart the Cisco ISE Policy Service Node to clear any cached posture results that might be stale.

Why it fails: Restarting the PSN is disruptive and unlikely to fix a condition definition error. Posture results are evaluated in real time based on the conditions; they are not persistently cached in a way that would cause compliant endpoints to appear non-compliant. This action would not address the root cause and could affect other users.

The endpoint's MAC address is not in the OUI database.

Why it fails: The OUI database is used to identify the hardware vendor from the MAC address. If the OUI were unknown, the endpoint might not match any Windows policy, but the scenario indicates it is already profiled as a Windows Workstation. The OUI is not the reason for failing to meet the higher certainty threshold of a more specific policy.

The endpoint has not been assigned to the correct Endpoint Identity Group.

Why it fails: Endpoint Identity Groups are used to group endpoints for policy and reporting, but they do not influence which profiling policy matches. The profiling engine evaluates policies based on collected attributes and certainty factors, independent of identity group membership. Assigning the endpoint to a different group would not change the certainty factor or the policy match.

The 'Windows 10 Enterprise' policy is disabled.

Why it fails: If the policy were disabled, it would not be evaluated at all, and the endpoint would likely not match any Windows 10 policy. However, the scenario states the endpoint has matching attributes for both policies, implying the policy is active. A disabled policy would not produce the specific symptom of a lower certainty match; the issue is the threshold, not the policy state.