SISE Exam Questions and Answers

Policy Service Node (PSN)

PSNs handle RADIUS authentication and authorisation for endpoints, so dedicating this persona distributes the 50,000 concurrent authentication requests across nodes. The PAN concentrates policy administration and monitoring, not session processing, making it unsuitable for that load.

Source-IP affinity (persistence)

Source-IP affinity pins each client's RADIUS session to one PSN for its duration, preserving session state across the load balancer. RADIUS is stateful, so persistence prevents authentication failures caused by requests landing on different PSNs.

Initiate registration from the Primary PAN under Administration > System > Deployment

Registration must be initiated from the Primary PAN, which generates a one-time registration key; the secondary node then uses that key to join. Starting from the secondary node is not supported, so this sequence satisfies the deployment's requirement that the Primary PAN authorises the new node.

ISE Advantage

ISE Advantage is the licence tier that unlocks advanced profiling and posture services; lower tiers such as Base or Plus do not include them. This satisfies the stem's constraint of enabling both advanced profiling and posture on the deployment.

Keep the MnT node in the same high-speed network as the PAN

MnT nodes write session and accounting data continuously to the PAN, so placing them on the same high-speed network avoids WAN latency and bandwidth saturation. This satisfies the deployment's performance constraint, since replication and logging traffic across slow WAN links degrades PAN responsiveness and reporting accuracy.

Distributed Configuration Synchronization via HTTPS

Distributed Configuration Synchronization replicates the Primary PAN's configuration to all secondary nodes over HTTPS, keeping policy, identity and admin data consistent across the deployment. This mechanism maintains the configuration integrity the scenario demands, ensuring every node enforces identical policy.

Operations > Reports > Endpoints and Users > Certificate Provisioning

The Certificate Provisioning report records each CA interaction, including the SCEP or EST enrolment exchange, so it isolates why issuance fails after successful registration. It satisfies the stem's constraint by showing the specific CA error rather than generic endpoint or authentication data.

The ISE MDM Server connector

The ISE MDM Server connector polls the external MDM to obtain device compliance and jailbreak status, then feeds it into authorisation. Without this connector, ISE cannot learn the MDM's verdict, so the device never matches a Compliant condition despite the MDM reporting compliance.

To configure the native supplicant settings for secure network access

The Network Setup Assistant provisions BYOD endpoints by configuring the native supplicant with the correct SSID, authentication method and certificates. This satisfies the requirement for secure network access without manual user configuration, enabling devices to authenticate against ISE policies.

Authorization Profile with a redirect ACL and URL redirect

The Authorization Profile carries the redirect ACL and URL redirect attributes returned in the RADIUS Access-Accept after MAB succeeds. These attributes instruct the switch to intercept the session and send the user's browser to the BYOD self-service portal for registration.

Work Centers > Guest Access > Portals & Components > [Portal Name] > Portal Settings

The BYOD checkbox lives under the specific portal's own settings, reached via Work Centers > Guest Access > Portals & Components, then the named portal, then Portal Settings. This path satisfies the stem's requirement to enable BYOD for one specific registration portal rather than globally.

To allow devices to request certificates from the CA via the ISE node

The SCEP proxy relays certificate requests from BYOD endpoints to the CA, since endpoints cannot reach the CA directly. ISE acts as intermediary, forwarding the request and returning the issued certificate. This satisfies the stem's constraint of enrolling BYOD devices without direct CA connectivity.

To gather compliance data without restricting network access

Monitor Mode collects endpoint compliance data while leaving network access unrestricted, satisfying the stem's requirement for visibility without enforcement. Unlike enforcement mode, which applies remediation or restricts access based on posture results, Monitor Mode only audits and reports, letting administrators assess posture compliance before rolling out enforcement.

HTTP/HTTPS (TCP 8905)

AnyConnect sends posture data to the ISE PSN over HTTP/HTTPS on TCP 8905, satisfying the requirement for a dedicated posture transport channel. Unlike RADIUS, which carries authentication and authorisation, this separate TCP session handles endpoint posture assessment traffic exclusively, allowing the agent to report compliance details directly to the PSN.

Policy > Policy Elements > Results > Client Provisioning > Resources

AnyConnect posture agent packages are uploaded as Client Provisioning resources under Policy > Policy Elements > Results > Client Provisioning > Resources. From there they are referenced by client provisioning policies and pushed to endpoints during onboarding.

File Remediation Action

A File Remediation Action specifies the download link and instructions presented to the user when a posture check fails, satisfying the requirement to supply compliance software. Other remediation types, such as Windows or Antivirus actions, trigger local updates rather than offering a downloadable installer.

Service Condition

A Service Condition inspects the endpoint's running services and processes via the posture agent, matching the named 'Cisco AnyConnect' service. It directly satisfies the requirement to verify that specific service is running, unlike file, registry or application conditions.

Policy > Policy Elements > Conditions > Posture > Registry Condition

Registry conditions are posture policy elements, so they are authored under Policy Elements before being referenced in posture policies. Defining the specific registry key here lets ISE evaluate endpoint compliance and grant access only to matching endpoints.

The Network Access Device (NAD)

The Network Access Device intercepts the guest's initial HTTP request and issues the redirect to the Cisco ISE CWA portal. Redirection happens at the NAD, not the client or policy server, because the NAD controls the traffic path before authorisation completes.

The ISE server certificate is self-signed or not trusted by the client device.

Guest portal redirection presents the ISE server certificate to the client browser. If that certificate is self-signed or issued by a CA the client does not trust, the TLS handshake triggers a warning. Replacing it with a CA-signed certificate trusted by client devices resolves the warning.

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.

Enable MAC Caching

Enabling MAC Caching lets the guest portal cache the endpoint's MAC address after successful authentication, so returning clients bypass the portal. This directly satisfies the stem's requirement: the MAC address is not being cached, causing repeated authentication failures. The setting is the specific control governing that caching behaviour.

Assign a downloadable ACL (dACL) in the Authorization Profile.

A downloadable ACL in the Authorization Profile pushes a per-user access control list to the network device, permitting the guest to reach the printer while denying other internal resources. This satisfies the requirement for granular, session-specific access.

Hotspot Portal

The Hotspot Portal satisfies the no-authentication constraint by presenting a click-through Accept button, granting network access without credentials. Unlike the Sponsored-Guest or Self-Registered portals, which require sponsor approval or credential creation, the Hotspot flow performs no identity lookup against Microsoft Entra ID, so unauthenticated visitors gain access immediately.

Administration > Network Resources > Network Device Groups

Administration > Network Resources > Network Device Groups is the exact path where Cisco ISE stores device group definitions, satisfying the requirement to define a new Network Device Group. Groups created here feed into authorisation policy conditions and device registration, so the hierarchy is available immediately for policy evaluation.

Configure the 'Privilege Level' field to 15

Setting the Privilege Level field to 15 in the Shell Profile assigns the maximum TACACS+ privilege directly at authorisation, so the administrator lands in enable mode on login without issuing an enable command. This satisfies the stem's requirement for immediate privilege level 15 placement.

TACACS+ Livelogs

TACACS+ Livelogs capture per-request authentication detail, including the matched policy set and authorisation result, which the stem requires. Unlike passive log files, Livelogs stream live request attributes and rule evaluations, so you can pinpoint exactly why a device's TACACS+ authentication attempt succeeded or failed.

Deny 'show running-config' and permit all other commands

TACACS+ command sets evaluate commands sequentially, so explicitly denying 'show running-config' before permitting the remaining 'show' commands blocks only that variant. Ordering matters: a broad permit placed first would authorise the restricted command before the deny is reached.

TCP 49

TACACS+ uses TCP port 49 for communication between Cisco ISE and network devices. Unlike RADIUS, which uses UDP ports 1812 and 1813, TACACS+ separates authentication, authorisation and accounting over a single TCP connection, making port 49 the default for device administration.

The command is executed on the device upon login

The Shell Profile's Auto-Command runs automatically once authentication succeeds, satisfying the requirement that a predefined command execute at login. Cisco ISE pushes this attribute to the network device during authorisation, so the device executes it immediately without user input, which is precisely the behaviour the scenario describes.

The network device must be configured to send SNMP traps to the ISE PSN IP address.

SNMP Trap profiling depends on receiving unsolicited trap PDUs from network devices, so each device must target the ISE PSN's IP address as a trap receiver. Without that destination configured, no trap reaches ISE and profiling fails, directly satisfying the stem's requirement for endpoints lacking DHCP options.

HTTP probe

The HTTP probe inspects the User-Agent string within HTTP traffic, revealing the endpoint's operating system and browser type. This satisfies the stem's web-portal scenario, where HTTP is the only traffic available, unlike NetFlow or DHCP probes.

To indicate the confidence level that the device is correctly profiled.

The Certainty Factor is a numeric score expressing how confident the profiling conditions are that a device matches an endpoint profile. A low value means the collected attributes are inconclusive, so ISE withholds assignment to the correct group until confidence rises.

The SNMP Query probe will fail to collect CDP/LLDP data from the switch.

The SNMP Query probe authenticates to the switch using the configured read community string. A mismatch causes the switch to reject the request, so the probe cannot retrieve CDP or LLDP neighbour data and profiling fails.

Operations > RADIUS Livelogs

RADIUS Livelogs capture live authentication and authorisation exchanges, showing the actual attributes received from the network access device. Inspecting them confirms whether the profiler condition's attribute arrives and with what value, exposing mismatches that prevent correct endpoint matching.

Configure an IP helper-address on the Layer 3 device for the client VLAN pointing to the ISE node.

DHCP broadcasts stay within the client subnet, so the Layer 3 device must relay them. An IP helper-address on the client VLAN forwards those requests to the ISE node, letting the probe receive traffic from endpoints on a different subnet.

SGACL definition

SGACLs supply the actual permit or deny rules applied to traffic between source and destination SGTs. Without a defined SGACL, the TrustSec Matrix has no enforceable access control entries, so this component is mandatory for SGT-based enforcement in an SGA policy.

TrustSec Matrix configuration

The TrustSec Matrix defines which source-to-destination SGT pairs are permitted or denied, so SGA policy cannot resolve enforcement decisions without it. It supplies the group-to-group policy lookup that SGACLs alone lack, satisfying the stem's requirement for a complete SGA deployment.

SGT mapping

SGT mapping translates the Security Group Tag values carried in the traffic into enforceable policy conditions, satisfying the requirement that the Scalable Group Access policy knows which tag corresponds to which group before enforcement. Without this mapping, the policy engine cannot match tagged flows to the intended authorisation rules.

NetworkDevice:Name

NetworkDevice:Name matches the network access device's configured name in ISE, so the policy set applies only to requests from that specific WLC. This satisfies the constraint of scoping the policy set to one wireless controller.

Authorization Profile

The authorization profile holds the actual enforcement attributes — VLAN, dACL, SGT, URL redirect — that ISE returns once a rule matches. The rule's conditions only select it; the profile supplies the result, satisfying the stem's requirement for the component defining the rule's outcome.

Cisco IOS-style extended access-list format

TrustSec dACLs require Cisco IOS-style extended access-list syntax, not standard IP ACLs or vendor-neutral formats. This satisfies the stem's mandatory format constraint, as the SISE exam expects entries such as "permit ip any any" with protocol, source, and destination fields.

Condition matching

Each Policy Set contains conditions evaluated top-down against the RADIUS request attributes; the first set whose conditions all evaluate true is selected. This condition matching is the mechanism that determines Policy Set selection before authentication policy is applied.

Allowed Protocols

Certificate validation for EAP-TLS is governed by the Allowed Protocols configuration, where the specific EAP method's options define which certificate authorities and checks ISE accepts. Enabling EAP-TLS there determines how the client certificate is validated during authentication.