Scenario practice questions

In a CWA scenario, the user is redirected to the portal, authenticates, but the session is not transitioning from the 'redirected' state to the 'authenticated' state. What is the most likely cause?

Trap 1: The Guest user group is missing from the Policy Set.

The Guest user group governs guest access authorisation, not the CWA state transition, which depends on the client receiving the redirect and completing posture or authentication checks. It is tempting because group membership drives many policy outcomes, but a missing group would deny access rather than stall the state machine.

Trap 2: The Redirect ACL is applied to the wrong interface.

The Redirect ACL controls which traffic is intercepted for redirection, not the state transition after authentication. A misplaced ACL would prevent redirection entirely, leaving the user unredirected rather than stuck in 'redirected'. The authenticated state depends on the CoA/re-auth exchange between Cisco ISE and the WLC, so the failure lies there.

Trap 3: The portal URL is incorrect.

An incorrect portal URL would prevent the redirect reaching the login page at all, yet the user authenticates successfully, so the URL is demonstrably reachable. It is tempting because redirect failures often trace to URL misconfiguration, but that would break the initial redirect, not the post-authentication transition.

A
The NAD is missing the 'aaa server radius dynamic-author' configuration.
Dynamic authorisation (CoA) lets the NAD accept change-of-authorisation packets from the RADIUS server. Without 'aaa server radius dynamic-author', the switch cannot process the CoA that moves the session from redirected to authenticated after portal login.
B
The Guest user group is missing from the Policy Set.
Why it fails: The Guest user group governs guest access authorisation, not the CWA state transition, which depends on the client receiving the redirect and completing posture or authentication checks. It is tempting because group membership drives many policy outcomes, but a missing group would deny access rather than stall the state machine.
C
The Redirect ACL is applied to the wrong interface.
Why it fails: The Redirect ACL controls which traffic is intercepted for redirection, not the state transition after authentication. A misplaced ACL would prevent redirection entirely, leaving the user unredirected rather than stuck in 'redirected'. The authenticated state depends on the CoA/re-auth exchange between Cisco ISE and the WLC, so the failure lies there.
D
The portal URL is incorrect.
Why it fails: An incorrect portal URL would prevent the redirect reaching the login page at all, yet the user authenticates successfully, so the URL is demonstrably reachable. It is tempting because redirect failures often trace to URL misconfiguration, but that would break the initial redirect, not the post-authentication transition.

Question 2mediummultiple choice

What is the function of the 'PassiveID' feature in a distributed ISE deployment?

Trap 1: It enables redundant authentication

PassiveID replicates authentication and accounting data from a primary node to a secondary node, letting the secondary serve sessions if the primary fails. It does not perform redundant authentication itself; it synchronises session state. It is tempting because it supports failover, which is its actual purpose in a standalone high-availability pair.

Trap 2: It replaces the need for PSNs

PassiveID is a service running on PSNs.

Trap 3: It caches RADIUS requests

PassiveID parses syslog and RADIUS accounting records to build endpoint session context; it does not cache or proxy RADIUS requests. Caching is tempting when PSN-to-PAN latency is high, but that scenario calls for a local PSN or policy cache.

A
It enables redundant authentication
Why it fails: PassiveID replicates authentication and accounting data from a primary node to a secondary node, letting the secondary serve sessions if the primary fails. It does not perform redundant authentication itself; it synchronises session state. It is tempting because it supports failover, which is its actual purpose in a standalone high-availability pair.
B
It replaces the need for PSNs
Why it fails: PassiveID is a service running on PSNs.
C
It caches RADIUS requests
Why it fails: PassiveID parses syslog and RADIUS accounting records to build endpoint session context; it does not cache or proxy RADIUS requests. Caching is tempting when PSN-to-PAN latency is high, but that scenario calls for a local PSN or policy cache.
D
It provides user identity mapping without active probing
PassiveID derives user identity from existing authentication traffic, such as RADIUS accounting or AD logins, without sending probes to endpoints. This satisfies scenarios where active probing is undesirable, mapping users to sessions passively while avoiding the network disruption and endpoint agent requirements active methods impose.

Question 3mediummultiple choice

In a distributed environment, if the Primary PAN goes offline, what happens to the Secondary PAN?

Trap 1: It disconnects from the PSNs

The Secondary PAN maintains its connection to the managed firewalls and continues synchronising configuration; it does not disconnect from the PSNs when the Primary goes offline. Disconnection would only occur if the Secondary itself failed or lost network reachability.

Trap 2: It stops accepting configuration changes

A Secondary PAN continues serving existing configurations and accepts policy edits; it simply cannot commit them while the Primary is down, so this describes normal synchronisation behaviour rather than the failover outcome. It is tempting because Secondary PANs do queue configuration changes for later promotion, which applies during temporary Primary maintenance windows.

Trap 3: It automatically assumes the Primary role

The Secondary PAN remains in a passive standby state and does not automatically promote itself when the Primary fails; promotion requires manual intervention or configured failover. Automatic role assumption applies to HA pairs, not the distributed deployment described here.

A
It disconnects from the PSNs
Why it fails: The Secondary PAN maintains its connection to the managed firewalls and continues synchronising configuration; it does not disconnect from the PSNs when the Primary goes offline. Disconnection would only occur if the Secondary itself failed or lost network reachability.
B
It remains in Secondary mode until manually promoted
The Secondary PAN stays passive because Cisco ISE does not provide automatic failover; promotion to Primary requires an administrator to run the `application configure ise` promotion command or use the CLI. This satisfies the stem's constraint: no automatic role transition occurs when the Primary PAN goes offline.
C
It stops accepting configuration changes
Why it fails: A Secondary PAN continues serving existing configurations and accepts policy edits; it simply cannot commit them while the Primary is down, so this describes normal synchronisation behaviour rather than the failover outcome. It is tempting because Secondary PANs do queue configuration changes for later promotion, which applies during temporary Primary maintenance windows.
D
It automatically assumes the Primary role
Why it fails: The Secondary PAN remains in a passive standby state and does not automatically promote itself when the Primary fails; promotion requires manual intervention or configured failover. Automatic role assumption applies to HA pairs, not the distributed deployment described here.

Question 4hardmultiple choice

You want to enforce a policy where personal devices are allowed access, but only if they are not jailbroken. How is this achieved in a BYOD scenario?

Trap 1: Use ISE profiling only

Profiling identifies the operating system and manufacturer, not jailbreak or root status; that requires posture assessment via the ISE posture agent or MDM check. It tempts because profiling is the visible BYOD classification step, but jailbreak detection is a compliance condition.

Trap 2: Use an ACL on the switch

Switch ACLs filter on Layer 3/4 attributes such as IP addresses and ports, so they cannot inspect a device's jailbreak state. They are tempting because ACLs genuinely restrict network access by subnet or port, which would be correct for segmenting wired VLANs, not for posture-based BYOD admission.

Trap 3: Configure a WLC-based check

A WLC-based check inspects wireless-layer attributes like SSID, authentication type and RF data, not endpoint OS integrity, so jailbreak status stays invisible. WLC checks are tempting because they correctly enforce per-SSID policies and device registration for wireless onboarding, but posture assessment belongs to an MDM or NAC solution.

A
Use ISE profiling only
Why it fails: Profiling identifies the operating system and manufacturer, not jailbreak or root status; that requires posture assessment via the ISE posture agent or MDM check. It tempts because profiling is the visible BYOD classification step, but jailbreak detection is a compliance condition.
B
Use an ACL on the switch
Why it fails: Switch ACLs filter on Layer 3/4 attributes such as IP addresses and ports, so they cannot inspect a device's jailbreak state. They are tempting because ACLs genuinely restrict network access by subnet or port, which would be correct for segmenting wired VLANs, not for posture-based BYOD admission.
C
Configure a WLC-based check
Why it fails: A WLC-based check inspects wireless-layer attributes like SSID, authentication type and RF data, not endpoint OS integrity, so jailbreak status stays invisible. WLC checks are tempting because they correctly enforce per-SSID policies and device registration for wireless onboarding, but posture assessment belongs to an MDM or NAC solution.
D
Integrate an MDM that performs jailbreak detection
Jailbreak detection requires an MDM integration, because only an MDM agent on the device can inspect for compromised or rooted state and report it to the policy engine. This satisfies the stem's constraint of allowing personal devices only when not jailbroken.

Question 5hardmultiple choice

You are troubleshooting a scenario where an admin cannot execute a specific command despite the Command Set having 'Permit' for that command. What is a common reason?

Trap 1: The ISE Policy Set has 'Deny' as the default

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.

Trap 2: The user is in the wrong AD group

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.

Trap 3: The TACACS+ shared secret is incorrect

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.

A
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.
B
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.
C
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.
D
The command is blocked by the switch's local configuration
Cisco ISE authorises commands through the Command Set, but the switch's local configuration, such as a privilege level or parser view restriction, can still deny execution. Authorisation succeeds while the device itself blocks the command, so the admin cannot run it despite the Permit result.

Question 6easymultiple choice

What is the purpose of an Authorization Profile's 'Common Tasks'?

Trap 1: To group devices together

Common Tasks specifies the enforcement actions applied to an authorised session, not device grouping. Grouping devices is tempting because authorisation conditions often match device groups, but those groups are defined in network device groups, which policies reference rather than the profile itself.

Trap 2: To define user permissions for ISE UI

Common Tasks defines session-authorisation actions returned to the network device, not administrative rights within the ISE interface. Defining UI permissions is tempting because both concern authorisation, but administrative RBAC is configured through ISE admin accounts and personas, not through an authorisation profile.

Trap 3: To store identity sources

Common Tasks selects the actions an authorisation result applies to a session, such as VLAN assignment or dACL, not identity source definitions. Storing identity sources is tempting because authorisation policies reference them, but that configuration belongs to identity source sequences, not to a profile's task list.

A
To group devices together
Why it fails: Common Tasks specifies the enforcement actions applied to an authorised session, not device grouping. Grouping devices is tempting because authorisation conditions often match device groups, but those groups are defined in network device groups, which policies reference rather than the profile itself.
B
To configure standard RADIUS attributes easily
Common Tasks provides predefined shortcuts that populate standard RADIUS attributes, such as VLAN or ACL assignments, into the authorization profile without manual entry. This simplifies and standardises attribute configuration, ensuring consistent access policy enforcement during authentication.
C
To define user permissions for ISE UI
Why it fails: Common Tasks defines session-authorisation actions returned to the network device, not administrative rights within the ISE interface. Defining UI permissions is tempting because both concern authorisation, but administrative RBAC is configured through ISE admin accounts and personas, not through an authorisation profile.
D
To store identity sources
Why it fails: Common Tasks selects the actions an authorisation result applies to a session, such as VLAN assignment or dACL, not identity source definitions. Storing identity sources is tempting because authorisation policies reference them, but that configuration belongs to identity source sequences, not to a profile's task list.

Question 7easymultiple choice

A network administrator is configuring posture remediation for Windows endpoints that fail a check for Windows Defender real-time protection. The administrator wants to provide users with a link to enable real-time protection manually. Which remediation type should be configured in the posture policy to achieve this?

Trap 1: Application

An Application remediation action launches a specific application on the endpoint, such as an antivirus update tool. This is useful for launching a program but does not provide a link to instructions. For manual enablement of a Windows setting, a link is more appropriate and simpler to configure.

Trap 2: File

A File remediation action delivers a file to the endpoint, such as a script or installer, which the user must run. While this can automate remediation, it does not provide a simple link for manual steps. For enabling real-time protection, a file-based approach would be overkill and less user-friendly than a direct link.

Trap 3: Script

A Script remediation action executes a predefined script on the endpoint to perform automatic remediation. This could enable real-time protection, but it requires scripting expertise and may not be desired for a simple manual step. The scenario specifies providing a link for manual action, so a script is not the correct choice.

A
Application
Why it fails: An Application remediation action launches a specific application on the endpoint, such as an antivirus update tool. This is useful for launching a program but does not provide a link to instructions. For manual enablement of a Windows setting, a link is more appropriate and simpler to configure.
B
File
Why it fails: A File remediation action delivers a file to the endpoint, such as a script or installer, which the user must run. While this can automate remediation, it does not provide a simple link for manual steps. For enabling real-time protection, a file-based approach would be overkill and less user-friendly than a direct link.
C
Link
A Link remediation action provides a clickable URL that users can follow to perform a manual remediation step, such as enabling Windows Defender real-time protection. This is ideal when the remediation cannot be automated or when the administrator wants to guide users to a specific resource. It does not require scripting or file distribution.
D
Script
Why it fails: A Script remediation action executes a predefined script on the endpoint to perform automatic remediation. This could enable real-time protection, but it requires scripting expertise and may not be desired for a simple manual step. The scenario specifies providing a link for manual action, so a script is not the correct choice.