Hard Difficulty Questions

SSL-offloading

Why it fails: SSL-offloading terminates TLS at the load balancer, but RADIUS traffic is UDP and typically relies on shared-secret validation rather than TLS sessions, so offloading is irrelevant here. It is tempting because it reduces backend encryption overhead, which would be correct for HTTPS-based web services.

Active-passive failover only

Why it fails: Active-passive failover leaves standby PSNs idle, so RADIUS authentication capacity is not pooled across the group. It is tempting because it simplifies state handling, which would be correct for services where session state cannot be shared between nodes.

Round-robin without persistence

Why it fails: RADIUS accounting and authorisation depend on a client staying pinned to one PSN, so round-robin without persistence splits a session across nodes and breaks state. It is tempting because round-robin suits stateless HTTP load balancing, where any node can answer any request.

deny ip any 10.1.1.0 0.0.0.255

Why it fails: This denies only IP traffic to the subnet, so non-IP protocols still pass, and it omits the trailing permit needed for everything else. It is tempting because it names the target subnet correctly. The requirement needs deny ip any 10.1.1.0 0.0.0.255 followed by permit ip any any as the last line.

permit tcp any any

Why it fails: A trailing permit tcp any any only allows TCP, dropping UDP, ICMP and other protocols that the requirement says must still reach non-denied destinations. It is tempting because it mirrors a typical implicit-permit replacement. The final line must be permit ip any any, placed after the deny for 10.1.1.0/24.

deny ip any any

Why it fails: Denying all traffic as the final line blocks every destination, not just the server subnet, contradicting the requirement to permit everything else. It is tempting because it guarantees the subnet is denied. The last line must instead be permit ip any any, with the subnet deny placed before it.

TACACS+ command set

Why it fails: A TACACS+ command set authorises which CLI commands an administrator may run on a network device; it does not classify traffic into security groups or enforce group-based ACLs. TACACS+ is correct for granular device administration accounting and command authorisation.

RADIUS shared secret

Why it fails: A RADIUS shared secret authenticates a device to a RADIUS server; it carries no security group tag and enforces no group-based policy. RADIUS is the correct choice when centralising 802.1X user or device authentication, not for defining TrustSec source-group-to-destination-group enforcement.

Mapping VLANs to specific guest SSIDs.

Why it fails: VLAN-to-SSID mapping is configured on the Cisco WLC or in Cisco ISE policy sets, not in the Sponsor Portal, which only creates and manages guest accounts. It tempts because SSID and VLAN settings feel guest-related, yet such mapping belongs to wireless infrastructure configuration, not sponsor-facing guest provisioning.

Configuring global portal branding.

Why it fails: Global portal branding is configured in the Cisco ISE Admin portal under Admin > System > Portal Customisation, not the Sponsor Portal, which only exposes sponsor-scoped settings. It is tempting because sponsors can adjust their own guest-facing portal content, but tenant-wide branding sits with administrative policy configuration rather than sponsor account management.

Defining RADIUS shared secrets.

Why it fails: RADIUS shared secrets are configured on network access devices and in Cisco ISE policy elements, not in the Sponsor Portal, which only creates and manages guest accounts. It is tempting because shared secrets are part of ISE's authentication configuration, but they belong to device administration workflows rather than sponsor-facing guest provisioning.

SGT propagation

Why it fails: SGT propagation tags traffic with a Security Group Tag for enforcement by downstream devices; it does not itself restrict access within the authorisation profile. It is tempting because SGTs enable segmentation, but that requires SGACL enforcement elsewhere. Restriction here comes from VLAN or ACL attributes in the profile.

Authentication protocol

Why it fails: The authentication protocol governs how credentials are exchanged during authentication, not what network resources the client may reach afterwards. It is tempting because protocol choice affects security posture, but it is configured in authentication policy. Restricting access requires authorisation attributes such as VLAN or ACL assignments.

Identity Source

Why it fails: An identity source determines which store authenticates the client; it does not restrict access once authentication succeeds. It is tempting because identity sources underpin authorisation decisions, but they belong in authentication policy. Restricting network access requires attributes such as VLAN, ACL or dACL within the authorisation profile itself.

User forgot their Wi-Fi password

Why it fails: A forgotten Wi-Fi password simply fails authentication, so the device never joins the network and cannot be assigned to a quarantine VLAN. It is tempting because failed authentication sounds like a security trigger, but quarantine applies to devices that authenticate successfully yet fail posture checks such as outdated antivirus or missing patches.

The device is too new

Why it fails: A device being too new is not a quarantine trigger; posture assessment checks compliance attributes such as patch level, antivirus state and OS version, not hardware age. It is tempting because unknown devices are quarantined, yet novelty alone does not indicate non-compliance.

Manually map IP to SGT on all switches

Why it fails: ISE provides dynamic SXP or Cisco TrustSec SGT mapping.

Configure the SGACL on the client

Why it fails: SGACLs are enforced on the enforcement device, not the client.

Create a dACL with SGT 10

Why it fails: dACLs are for IP-based filtering, not SGT-based filtering.

Increase the idle timeout on the WLC's WLAN configuration.

Why it fails: Idle timeout settings affect session termination, not the initial portal redirection process.

Verify the WLC's 'Web Auth Redirect' configuration and ensure the 'Virtual Gateway' address is reachable.

Why it fails: While important, the most frequent point of failure in CWA redirection is the client's inability to resolve the ISE FQDN.

Re-import the Guest Portal certificate on the WLC.

Why it fails: The WLC does not require the ISE portal certificate for the initial redirect handshake.

prrt-server.log

Why it fails: This is for RADIUS-related logs.

guest.log

Why it fails: This is for guest access flows.

admin.log

Why it fails: This is for administrative configuration changes.

In the Client Provisioning Resource file

Why it fails: The Client Provisioning Resource file holds posture conditions and agent download rules, not remediation script bodies. Script content belongs in the remediation configuration itself, which is why that file is the wrong location despite being where client provisioning policy is defined.

In the Posture Policy XML

Why it fails: Posture Policy XML defines the posture conditions and the remediation action type, but the script body itself is not stored there. It is tempting because the policy references the remediation, and would be correct for declaring which remediation applies, yet the actual script content must live in the client provisioning resource.

On the endpoint in the AnyConnect directory

Why it fails: The AnyConnect directory on the endpoint holds installed client files, not the remediation script definition pushed by ISE. It is tempting because the endpoint executes the script, and would be correct for local client binaries, but posture remediation scripts are defined centrally in the client provisioning resource, not on the endpoint.

Context Visibility > Endpoints

Why it fails: Context Visibility > Endpoints shows endpoint identity, compliance and posture status summaries, not the raw registry value the agent read. It is tempting as the central endpoint inventory, but it is correct for reviewing device compliance state, not for inspecting the actual attribute data collected by a posture condition.

Client Provisioning > Resources

Why it fails: Client Provisioning > Resources stores agent provisioning artefacts such as profiles and certificates, not posture assessment results. It is tempting because posture conditions are configured nearby, but it is correct for distributing configuration to endpoints, not for viewing the registry value the agent actually detected.

Policy > Posture > Conditions

Why it fails: Conditions only defines the registry check and its expected value; it never displays what the agent actually read from the endpoint. The agent's collected registry data appears under Policy > Posture > Endpoints, where per-endpoint results are listed. Conditions is tempting because that is where the check itself is configured.

Framed-IP-Address

Why it fails: Framed-IP-Address carries the IP assigned to the guest endpoint by the NAS, so it identifies the device's address, not the network device serving the request. It is tempting because it locates the endpoint itself, which suits scenarios tracking a client's assigned address rather than the physical access point handling authentication.

Calling-Station-ID

Why it fails: Calling-Station-ID carries the guest endpoint's MAC address, identifying the device rather than its physical location. It is tempting because it uniquely identifies the client and supports device-based policy, and would be correct where the requirement is to track or authorise a specific endpoint rather than determine where the request originated.

NAS-IP-Address

Why it fails: NAS-IP-Address identifies the network access device's own interface address, not the guest's physical location. It is tempting because it does locate infrastructure, and would be correct where the requirement is to identify which RADIUS client or switch forwarded the request, rather than tracking the guest endpoint.

Modify the guest portal settings

Why it fails: Guest portal settings control the self-registration and sign-in experience, not which policy set Cisco ISE matches traffic to. Policy set selection depends on matching conditions such as identity source or NAS; changing portal branding or login options leaves the traffic still evaluated against the wrong set.

Change the authentication sequence

Why it fails: The authentication sequence orders identity stores within a single policy set; it cannot redirect traffic into a different policy set. ISE selects the policy set first, via matching conditions, then runs that set's sequence. Reordering stores only matters once the correct set is already chosen.

Reorder the policy sets

Why it fails: Reordering policy sets changes evaluation priority but does not guarantee guest traffic matches the Guest set if its conditions or assignment are wrong. It is tempting because order does affect which set applies first, and would be correct when a guest is already targeted by the Guest set but a higher-priority set intercepts them.

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.

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.

All sessions are terminated

Why it fails: Existing sessions continue unaffected; the PSN caches the last policy and keeps enforcing it, so users are not disconnected. Termination happens only when the PAN is unreachable during a fresh authentication or posture check. The option is tempting because losing the PAN sounds catastrophic, but resilience is exactly what the PSN's cached policy is designed to provide.

The PSN enters emergency mode

Why it fails: Emergency mode is not a state a PSN enters on PAN loss; the PSN simply continues serving sessions using its cached policy until the PAN returns. Emergency mode is a separate licensed feature for PAN outage authorisation fallback, configured deliberately. The option tempts because 'emergency' suggests automatic failover, but no such automatic transition occurs here.

The PSN reboots

Why it fails: Loss of PAN does not trigger a reboot.

Place custom policies in the system policy folder.

Why it fails: The system policy folder is overwritten by Feed Service updates, so placing custom policies there guarantees their loss. It is tempting because that folder holds active policies; it would be correct only for vendor-supplied policies that updates are meant to replace.

Export custom policies before every update.

Why it fails: Exporting copies policies out but leaves the originals in the overwritten location, so the update still replaces them unless manually re-imported. It is tempting as a backup habit; it would be correct for preserving configuration before a risky change, not for preventing overwrite.

Disable automatic updates.

Why it fails: Disabling automatic updates stops the Feed Service entirely, so profiling policies never receive vendor signature and policy refreshes. It is tempting because it removes the overwrite risk; it would be correct only where no feed connectivity is permitted, not for controlled update retention.

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.

The device is using a static IP.

Why it fails: Static IP addressing does not prevent profiling; Cisco ISE profiles endpoints using attributes such as DHCP, MAC OUI, and SNMP, and static addressing merely removes DHCP-derived data. It is tempting because missing DHCP fingerprinting can weaken profiling, but static IP alone still permits other probes to identify a Windows workstation.

The endpoint is not authenticated.

Why it fails: Authentication is not required for endpoint profiling; Cisco ISE identifies devices from DHCP, MAC OUI, SNMP, and NetFlow attributes gathered before any 802.1X or MAB exchange. It is tempting because authentication feeds posture and identity data, but an unauthenticated Windows workstation can still be profiled correctly from those network probes.

The endpoint has a firewall enabled.

Why it fails: A host firewall blocks inbound probes but does not itself cause an Unknown profile, since profiling also relies on DHCP, SNMP, and NetFlow data that traverse independently. It is tempting because blocked probe traffic can degrade profiling accuracy, yet the typical cause of Unknown is absent or failed authentication supplying insufficient identity attributes.