How many Wireless LAN and WLC Scenarios questions are on this page?

This page has 9 Wireless LAN and WLC Scenarios scenario questions for the SISE exam, each with detailed explanations and wrong-answer analysis.

How should I approach SISE scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to Cisco Implementing and Configuring Cisco Identity Services Engine (SISE, 300-715, CCNP Security) (SISE) questions

Scenario-based practice

Wireless LAN and WLC Scenarios

Practise Cisco Implementing and Configuring Cisco Identity Services Engine (SISE, 300-715, CCNP Security) (SISE) practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

SISE

exam code

Cisco

vendor

Scenario guide

How to approach wireless lan and wlc scenarios

Wireless questions on the CCNA cover 802.11 standards (ax/ac/n), WPA3, SSID/BSSID concepts, WLC architecture (FlexConnect, local switching), and client connectivity troubleshooting. These are mostly MCQ and multi-select.

Quick answer

Wireless security questions usually test authentication protocols (WPA2/WPA3), encryption modes, 802.11 standards and troubleshooting clients that cannot connect or associate.

WPA2 vs WPA3 authentication and encryption standards.

802.11 wireless standards, frequency bands and channel behaviour.

WLAN client troubleshooting — association, authentication and DHCP.

How SSID, authentication method and pre-shared key affect wireless access.

Practice scenarios

Question 1easymultiple choice

Open the full VLAN trunking answer →

Which option in the Cisco ISE Authorization Policy allows you to set a specific VLAN for a wireless client?

A
Policy Set Condition
Why it fails: Policy Set Conditions match attributes to select which policy set applies; they contain no authorisation result, so no VLAN can be returned. They are correct for routing requests to the right policy set. The Authorization Policy's authorisation result assigns the VLAN through a standard or Airespace attribute.
B
Authorization Profile
The Authorization Profile is the reusable object that carries VLAN and other attributes, which ISE returns in the RADIUS Access-Accept once a matching authorization rule fires. Referencing it in the policy satisfies the stem's requirement to assign a specific VLAN to the wireless client.
C
Identity Source Sequence
Why it fails: An Identity Source Sequence orders the identity stores ISE queries during authentication; it yields a pass or fail, never authorisation attributes such as a VLAN. It is correct when you need fallback across multiple stores. VLAN assignment is returned by the Authorization Policy's authorisation result.
D
Authentication Policy
Why it fails: The Authentication Policy determines how identities are verified and which identity store is queried; it returns no authorisation attributes, so it cannot assign a VLAN. It is the right place to select protocols and identity sources. VLAN assignment belongs to the Authorization Policy's authorisation result.

Full breakdown with real-world context →

Question 2mediummultiple choice

Read the full wireless explanation →

When configuring a policy set, which attribute is most commonly used to distinguish between a Wired and Wireless request?

A
Framed-IP-Address
Why it fails: Framed-IP-Address is an authorisation attribute returned to assign an address, not a request attribute identifying medium. NAS-Port-Type distinguishes wired from wireless. Framed-IP-Address tempts because it appears in policy conditions, but it reflects addressing rather than the access method that policy sets must separate.
B
NAS-Port-Type
NAS-Port-Type is a RADIUS attribute carried in the Access-Request that identifies the physical port category, such as Ethernet or Wireless-IEEE-802.11. Policy sets match on it to route wired and wireless requests down separate rule branches, satisfying the requirement to distinguish access medium.
C
Calling-Station-ID
Why it fails: Calling-Station-ID carries the endpoint's MAC or identifier, appearing in both wired and wireless requests, so it cannot separate them. NAS-Port-Type states the access medium, making it the standard discriminator. Calling-Station-ID tempts because it identifies clients, but it does not reveal the connection type.
D
Device-Name
Why it fails: Device-Name is an endpoint profiling attribute, not a RADIUS request field distinguishing access medium. Policy sets commonly separate wired and wireless using NAS-Port-Type, which identifies the connection type. Device-Name tempts because it identifies endpoints, but it cannot reliably indicate whether a request arrived over Ethernet or Wi-Fi.

Full breakdown with real-world context →

Question 3hardmultiple choice

Full question →

A security engineer is configuring Cisco ISE BYOD with a single SSID for both employee onboarding and corporate access. The engineer wants to ensure that devices without a valid certificate are redirected to the BYOD portal, while devices with a valid certificate are granted full access. The engineer has created a client provisioning policy that provisions the native supplicant with the corporate SSID and a certificate template. However, after provisioning, devices are still being redirected to the BYOD portal on subsequent connections. Which configuration change is required to allow onboarded devices to bypass the portal?

A
Change the client provisioning policy to use a different supplicant profile that includes the certificate.
Why it fails: The client provisioning policy is used during onboarding to provision the supplicant and certificate. Changing the supplicant profile would not affect authorization decisions after onboarding. The issue is that the authorization policy still redirects devices even with a valid certificate.
B
Modify the authorization policy to include a rule that matches devices presenting a valid certificate and assigns a permit access profile, placed above the redirection rule.
The authorization policy must have a rule that matches certificate-based authentication and assigns full access. Placing it above the redirection rule ensures onboarded devices are not redirected again. Without this, all devices matching the redirection rule will continue to be redirected.
C
Add the certificate's issuer to the list of trusted CAs in the BYOD portal settings.
Why it fails: The BYOD portal settings do not control authorization bypass. Trusted CAs are used for certificate validation during authentication, but the redirect decision is made by the authorization policy. Adding the issuer to the portal settings would not stop redirection.
D
Enable the 'Allow employees to bypass BYOD portal' option in the BYOD settings.
Why it fails: Cisco ISE does not have a global 'Allow employees to bypass BYOD portal' option. Bypass behavior is controlled through authorization policies and conditions, not a simple checkbox. This option does not exist in ISE BYOD configuration.

Full breakdown with real-world context →

Question 4hardmultiple choice

Full question →

A company uses Cisco ISE BYOD with certificate-based authentication. Employees report that their devices successfully onboard and receive a certificate, but after a few days, they are unable to connect to the corporate SSID. The administrator checks ISE and finds that the devices are failing authentication with the error 'Certificate revoked'. The administrator verifies that the certificates are still valid and not expired. Which ISE feature should the administrator check to resolve this issue?

A
Certificate Revocation List (CRL) distribution point and ISE's revocation check settings
The error 'Certificate revoked' indicates that ISE is checking the certificate against a CRL and finding it listed as revoked, or the CRL is improperly configured. The administrator should verify the CRL distribution point in the certificate and ensure ISE can reach it and that the CRL is current. If the CRL incorrectly includes the certificate, or if ISE is using a stale CRL, it will reject valid certificates. Adjusting revocation check settings or updating the CRL resolves the issue.
B
Certificate Revocation List (CRL) settings in the certificate template
Why it fails: CRL settings in the certificate template define how revocation lists are published and checked, but if the certificate is not actually revoked, the CRL would not cause a 'Certificate revoked' error. The error indicates that ISE believes the certificate is revoked, which is more likely due to a misconfigured revocation check or an incorrect CRL. However, the template itself does not revoke certificates; it only defines revocation parameters.
C
Certificate template's validity period and renewal settings
Why it fails: The validity period and renewal settings affect when a certificate expires or is renewed, but the error is 'Certificate revoked', not 'expired'. If the certificate were expired, the error would indicate expiration. Since the administrator confirmed the certificates are valid and not expired, the issue is not with validity period. Renewal settings might cause a new certificate to be issued, but that would not produce a revoked error for the current certificate.
D
Online Certificate Status Protocol (OCSP) configuration in ISE
Why it fails: OCSP is used to check certificate revocation status in real-time. If OCSP is misconfigured, it could return a revoked status incorrectly, but the error 'Certificate revoked' specifically points to a revocation decision. OCSP is a potential cause, but the scenario says certificates are valid and not expired; the issue is likely that ISE is checking revocation against a CRL that incorrectly lists the certificate as revoked, or the CRL is stale. OCSP is less likely because it would typically return 'unknown' or 'good' if the certificate is valid.

Full breakdown with real-world context →

Question 5mediummultiple choice

Read the full wireless explanation →

You are configuring a policy set in Cisco ISE for wireless clients. You need to ensure that the policy set only applies to requests originating from a specific WLC. Which condition should you use?

A
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.
B
Radius:NAS-IP-Address
Why it fails: NAS-IP-Address identifies the network access server, but with a wireless controller the RADIUS client address may be a shared or virtual interface, so it does not reliably pin requests to one specific WLC. It is tempting as the standard way to identify a RADIUS client, and would be correct for a wired switch or VPN concentrator.
C
Radius:Called-Station-ID
Why it fails: Called-Station-ID carries the access point's SSID and BSSID, not the controller that forwarded the request, so it cannot isolate a single WLC. It is tempting because it is a wireless-specific RADIUS attribute, and would be correct when the policy must target a particular SSID or access point.
D
Device:Model
Why it fails: Device:Model reflects the endpoint's hardware model reported in the request, not the network device that originated it, so it cannot distinguish WLCs. It is tempting because it is a device-based condition, and would be correct when the policy must apply only to a specific endpoint type.

Full breakdown with real-world context →

Question 6mediummultiple choice

Full question →

A user reports that a device was incorrectly identified as a 'Cisco IP Phone' when it is actually a 'Cisco Access Point'. Which troubleshooting step should you take first?

A
Check the endpoint attributes in Context Visibility to see why it matched that policy.
Context Visibility shows the endpoint's profiled attributes and the matching policy, revealing which probe or condition classified it as a Cisco IP Phone. Inspecting this first identifies the misclassification source before editing profiles or policies.
B
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.
C
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.
D
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.

Full breakdown with real-world context →

Question 7mediummultiple choice

Read the full wireless explanation →

You are configuring a policy set for wireless clients and need to ensure that only devices matching a specific internal endpoint group are granted access. Where should you define this requirement in the Cisco ISE policy set?

A
In the Authorization Policy rule conditions
Authorization policy rules evaluate conditions after authentication and are where endpoint identity group membership is matched to grant or deny access. Defining the internal endpoint group here enforces the stem's requirement that only matching devices receive authorisation.
B
In the Results section of the Authentication Policy
Why it fails: Results sections define what happens after a rule matches, such as authorisation profiles or permissions, so they cannot evaluate endpoint group membership as an access condition. They are tempting because authorisation outcomes live there, but Results suit assigning VLANs or dACLs once the condition has already been satisfied.
C
In the RADIUS dictionary under Policy Elements
Why it fails: The RADIUS dictionary holds attribute and vendor definitions used when constructing conditions, not endpoint group membership checks. It is tempting because conditions reference dictionary attributes, but defining the requirement there is impossible; dictionaries suit adding custom vendor-specific attributes for authorisation rules.
D
In the Policy Set general authentication settings
Why it fails: General authentication settings govern protocols, identity sources and certificate behaviour for the whole policy set, not per-request endpoint group matching. They are tempting because they apply broadly across the set, but they suit enabling EAP methods or choosing identity stores, not restricting access by internal endpoint group membership.

Full breakdown with real-world context →

Question 8easymultiple choice

Full question →

A security team is deploying Cisco ISE BYOD for employee devices. They want to ensure that only devices that have completed the BYOD onboarding process and possess a valid certificate are allowed on the corporate SSID. Which ISE policy element should they configure to enforce this requirement?

A
An authorization policy that permits access only when the endpoint presents a valid certificate and is registered in the BYOD identity group.
The authorization policy is where ISE decides whether to grant, deny, or restrict network access. By requiring a valid certificate and membership in the BYOD identity group, the policy ensures that only devices that completed onboarding and hold a certificate are allowed on the corporate SSID. This directly enforces the stated requirement.
B
A guest portal configuration that requires users to register their devices before accessing the network.
Why it fails: Guest portals are used for guest access and self-registration, not for enforcing certificate-based access for employee BYOD devices. While a portal may initiate onboarding, it does not control whether a device with a valid certificate is permitted on the corporate SSID after provisioning.
C
A client provisioning policy that matches the corporate SSID and requires certificate enrollment.
Why it fails: Client provisioning policies determine which devices receive provisioning profiles during onboarding. They do not enforce access control after onboarding. While they are part of the BYOD flow, they cannot by themselves restrict network access to devices that already have a valid certificate; that enforcement belongs in the authorization policy.
D
A posture policy that checks for the presence of the BYOD certificate on the endpoint.
Why it fails: Posture policies assess endpoint compliance using posture agents or conditions, not certificate possession for network admission. While posture can check for certain attributes, it is not the correct mechanism to enforce that a device has completed BYOD onboarding and holds a valid certificate for EAP-TLS authentication.

Full breakdown with real-world context →

Question 9mediummultiple choice

Read the full wireless explanation →

A network administrator is deploying a guest wireless network using Cisco ISE. They want guests to authenticate through a web portal, but they do not want guests to have to create their own accounts. Instead, they want employees to pre-create guest accounts and provide credentials to visitors. Which ISE feature should the administrator configure to enable this workflow?

A
Sponsor portal
The sponsor portal allows authorized employees (sponsors) to create and manage guest accounts in advance. Sponsors can generate credentials and provide them to visitors. This matches the requirement of employees pre-creating guest accounts. Thus, configuring the sponsor portal is the correct solution.
B
Hotspot portal
Why it fails: A hotspot portal is designed for guest access without authentication, often with a simple click-through. It does not support pre-created accounts by sponsors. Guests would not need credentials, so this fails to meet the requirement of employees creating accounts. Therefore, this option is not suitable.
C
Device registration portal
Why it fails: A device registration portal is used for registering devices, often for BYOD scenarios, not for creating guest accounts. It does not provide a way for sponsors to pre-create guest credentials. This option does not align with the need for sponsor-managed guest accounts. Hence, it is incorrect.
D
Self-registration guest portal
Why it fails: A self-registration guest portal allows guests to create their own accounts without sponsor involvement. This does not meet the requirement because the administrator wants employees to pre-create accounts. Self-registration would let guests sign up themselves, which is the opposite of the desired workflow. Therefore, this option is incorrect for the scenario.

Full breakdown with real-world context →

These SISE practice questions are part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style SISE questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Wireless LAN and WLC Scenarios

How to approach wireless lan and wlc scenarios

Quick answer

Related SISE topic practice pages

Architecture And Deployment practice questions

BYOD practice questions

Endpoint Compliance practice questions

Web Auth And Guest Services practice questions

Network Access Device Administration practice questions

Profiler practice questions

Policy Enforcement practice questions

SISE fundamentals practice questions

SISE scenario practice questions

SISE troubleshooting practice questions

Practice scenarios

Which option in the Cisco ISE Authorization Policy allows you to set a specific VLAN for a wireless client?

When configuring a policy set, which attribute is most commonly used to distinguish between a Wired and Wireless request?

You are configuring a policy set in Cisco ISE for wireless clients. You need to ensure that the policy set only applies to requests originating from a specific WLC. Which condition should you use?

A user reports that a device was incorrectly identified as a 'Cisco IP Phone' when it is actually a 'Cisco Access Point'. Which troubleshooting step should you take first?

You are configuring a policy set for wireless clients and need to ensure that only devices matching a specific internal endpoint group are granted access. Where should you define this requirement in the Cisco ISE policy set?

A security team is deploying Cisco ISE BYOD for employee devices. They want to ensure that only devices that have completed the BYOD onboarding process and possess a valid certificate are allowed on the corporate SSID. Which ISE policy element should they configure to enforce this requirement?