Free 300-715 Practice Test Questions 2026

Explanation:
The endpoint successfully bypasses 802.1X and MAB authenticates successfully, so authentication is not the issue. However, the endpoint cannot obtain an IP address. If the 802.1X timeout period is too long, the switch port remains in an unauthorized state (blocking all traffic except EAP) for an extended period, preventing DHCP from reaching the client.

Correct Option:

B. The 802.1X timeout period is too long.
When 802.1X is enabled on a port, the switch waits for the dot1x timeout tx-period (or timer reauth-period) before falling back to MAB. If this timeout is set too long (e.g., 30+ seconds), the port stays in "unauthorized" state during that period, blocking DHCP traffic. Even though MAB eventually succeeds, the client may have already failed DHCP discovery attempts. Reducing the timeout accelerates the MAB fallback.

Incorrect Options:

A. The DHCP probe for Cisco ISE is not working as expected –
DHCP probe failure affects endpoint profiling (device identification), but does not prevent the endpoint from obtaining an IP address. The DHCP process between client and DHCP server is independent of ISE probes.

C. The endpoint is using the wrong protocol to authenticate with Cisco ISE –
The exhibit explicitly states the endpoint is bypassing 802.1X and successfully using MAB. Therefore, the correct protocol (MAB) is being used and authentication succeeds.

D. An ACL on the port is blocking HTTP traffic –
HTTP (TCP 80) is unrelated to DHCP (UDP 67/68). Blocking HTTP does not affect IP address assignment. Even if an ACL blocked DHCP, MAB success would still permit DHCP if the port returns to authorized state.

Reference:

Cisco Catalyst Switch Configuration Guide – "802.1X Timers and MAB Fallback"

Cisco SISE 300-715 Official Cert Guide, Chapter: "Configuring MAB – Timeout Considerations"

Explanation:
In Cisco ISE, each user identity is linked to a specific identity store (internal or external). If a user is defined in an external store (e.g., Active Directory) but the authentication policy explicitly selects the internal store (ISE local database), ISE will look for the user internally, not find them, and thus fail the authentication.

Correct Option:

D. Authentication fails.
ISE's authentication process strictly follows the identity source defined in the authentication policy rule. When the policy points to the internal identity store, ISE searches only its local database for the user. Since the user exists only in the external identity store, no match is found, and authentication fails with "user not found." ISE does not automatically fall back or redirect to another store unless configured with multiple identity sources in a specific sequence.

Incorrect Options:

A. Authentication is redirected to the internal identity source –
ISE does not "redirect" after a policy decision. The policy explicitly selects the internal store; there is no automatic redirection to another store.

B. Authentication is redirected to the external identity source –
The policy overrides the user's original store association. ISE does not automatically switch to the external store just because the user exists there.

C. Authentication is granted –
Granting authentication without validating credentials against the correct store would be a security bypass. ISE never grants access without successful credential verification.

Reference:

Cisco ISE Administrator Guide – "Authentication Policies – Identity Source Sequence"

Cisco SISE 300-715 Official Cert Guide, Chapter: "Configuring Authentication Policies – Identity Store Precedence"

Explanation:
In a standalone Cisco ISE deployment, a single physical node runs multiple personas simultaneously. Unlike distributed deployments with separate PAN, MnT, and PSN nodes, the standalone node combines Administration (for configuration/monitoring) and Policy Service (for RADIUS/TACACS/pxGrid) personas on one server.

Correct Options:

B. Administration
The Administration persona manages system configuration, policy creation, logs, and monitoring via the ISE GUI and API. It includes the Policy Administration Node (PAN) and Monitoring & Troubleshooting (MnT) functions. A standalone node always runs this persona.

D. Policy Service
The Policy Service persona handles all RADIUS, TACACS+, and pxGrid requests. It evaluates authentication and authorization policies. In standalone mode, this persona runs alongside Administration on the same node.

Incorrect Options:

A. Publisher –
Publisher is a persona in a distributed multi-node deployment where one node is Publisher (primary PAN) and others are Subscribers. Standalone has no Publisher/Subscriber relationship.

C. Primary –
"Primary" is a role within personas (e.g., Primary PAN, Primary MnT) but not a separate persona. In standalone, there is no secondary node, so "primary" is not a designated persona.

E. Subscriber –
Subscriber nodes exist only in distributed deployments to replicate configuration from the Publisher. A standalone node has no Subscriber persona.

Reference:
Cisco ISE Deployment Guide – "Standalone vs. Distributed Deployment – Personas"

Explanation:
In Cisco ISE posture policies, a "posture requirement" defines a specific health check rule that endpoints must pass. Each requirement consists of two mandatory components: conditions (what to check, e.g., antivirus version) and remediation actions (what to do if the condition fails, e.g., prompt update or redirect to a remediation portal).

Correct Options:

B. Remediation actions
Remediation actions define the steps an endpoint must take when a posture condition is not met. Examples include launching a script, displaying a web notification, redirecting to a compliance portal, or automatically updating antivirus definitions. Without remediation, non-compliant endpoints have no guided path to compliance.

D. Conditions
Conditions are the actual checks performed on the endpoint, such as "registry key exists," "process is running," "file version matches," or "service is enabled." Conditions evaluate compliance status (compliant/non-compliant). Each requirement must have at least one condition.

Incorrect Options:

A. Updates –
Updates are part of ISE's software patching, not a component of a posture requirement. Posture policies reference update timestamp checks (e.g., "AV definition not older than 7 days"), but "updates" itself is not a requirement component.

C. Client Provisioning portal –
This portal delivers the AnyConnect posture agent or NAC Agent to endpoints. It is a separate configuration under Client Provisioning policies, not a component inside a posture requirement.

E. Access policy –
Access policies (authorization policies) use posture assessment results (compliant/non-compliant) to grant or deny network access. Access policy is separate from the posture requirement definition itself.

Reference:
Cisco ISE Administrator Guide – "Posture Policies – Configuring Posture Requirements"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Posture Services – Requirements and Remediation"

Explanation:
For single‑SSID BYOD, devices initially connect via open or dot1x authentication. ISE must redirect unregistered devices to a guest portal for onboarding using a Redirect ACL (sent via RADIUS Access‑Accept). Additionally, an Authentication policy must be configured to differentiate between BYOD registration flow and post‑onboarding access.

Correct Options:

C. Authentication policy
ISE needs an authentication policy to determine how to process BYOD requests. Typically, this includes MAB for unregistered devices (redirection to portal) and EAP‑TLS for provisioned devices with certificates. Multiple rules based on endpoint identity group (e.g., BYOD_Registered vs. Unknown) are defined here.

D. Redirect ACL
The Redirect ACL is a downloadable ACL (dACL) applied by the WLC. It permits DNS, DHCP, and ISE portal traffic while redirecting all other HTTP(S) traffic to the BYOD portal. This ACL must be defined on ISE (under Policy → Results → Authorization → Downloadable ACLs) and referenced in the authorization profile for unregistered devices.

Incorrect Options:

A. FlexConnect ACL –
FlexConnect ACLs are used on Cisco WLCs for branch office deployments with local switching. They are not a required configuration on ISE for BYOD. The scenario does not mention FlexConnect.

B. External identity source –
While BYOD may use an external identity store (e.g., AD) for user authentication, it is not strictly required for the single‑SSID BYOD flow. The question asks for two configurations must be done on ISE — Authentication Policy and Redirect ACL are mandatory.

E. Profiling policy –
Profiling helps classify endpoints (e.g., detect iOS vs. Android) but is not mandatory for basic BYOD functionality. The core requirements are authentication policy to handle the flow and redirect ACL to enforce portal redirection.

Reference:
Cisco ISE BYOD Deployment Guide – "Single SSID Onboarding"
Cisco SISE 300-715 Official Cert Guide, Chapter: "BYOD – Authentication Policy and Redirect ACL"

Explanation:
Context-sensitive sharing between Cisco ISE and a Cisco ASA (e.g., Security Group Tag (SGT) exchange, adaptive policy updates) requires pxGrid. pxGrid enables real-time publishing and subscribing of session, endpoint, and SGT data between ISE and other platforms like ASA running TrustSec or pxGrid client services.

Correct Option:

C. pxGrid
The pxGrid (Platform Exchange Grid) persona allows ISE to securely share contextual information (SGT, device profiles, session state) with Cisco ASA (running pxGrid client capabilities) and other security products. For ASA to receive SGT mapping or perform dynamic policy updates based on ISE context, pxGrid must be enabled on the ISE node and the ASA must be registered as a pxGrid client.

Incorrect Options:

A. Administration –
The Administration persona provides GUI access, policy configuration, and monitoring. It does not handle real-time context sharing with ASA. Administration is for management plane functions, not data exchange.

B. Policy Service –
The Policy Service persona handles RADIUS and TACACS authentication/authorization. It does not natively share context (e.g., SGTs) with ASA; that requires pxGrid. RADIUS alone cannot push SGT-to-IP mappings dynamically.

D. Monitoring –
The Monitoring persona (MnT) collects logs and alerts. It does not participate in live context exchange with ASA. MnT is passive for reporting and troubleshooting, not active policy sharing.

Reference:
Cisco ISE Administrator Guide – "pxGrid: Platform Exchange Grid – Use Cases with Cisco ASA"
Cisco SISE 300-715 Official Cert Guide, Chapter: "pxGrid Architecture and Personas"

Explanation:
By default, a switchport performs 802.1X authentication first and only falls back to MAB after a timeout. To immediately run MAB for non-802.1X capable endpoints (e.g., printers, IP phones), the authentication order command must specify MAB before dot1x.

Correct Option:

A. authentication order mab dot1x
This command configures the switch to attempt MAB first, followed by 802.1X if MAB fails or times out. For a non-802.1X capable endpoint, the switch immediately sends a MAB RADIUS request without waiting for 802.1X timeouts, drastically improving authentication speed. The default order is dot1x mab (dot1X first).

Incorrect Options:

B. authentication fallback –
This command is incomplete. The correct syntax is authentication fallback mab, but it only enables MAB as a fallback after 802.1X times out. It does not "immediately" run MAB; the switch still waits for 802.1X first.

C. dot1x pae authenticator –
This enables the port as an 802.1X authenticator but has no effect on MAB order. MAB may still work but only after dot1x timeout, not immediately.

D. access-session port-control auto –
This enables 802.1X authentication (auto mode) but does not change the authentication order. Without authentication order mab dot1x, dot1x still runs first.

Reference:
Cisco Catalyst Switch Command Reference – authentication order Cisco SISE 300-715 Official Cert Guide, Chapter: "Configuring MAB – Authentication Order"

Explanation:
In Cisco ISE guest access, each guest user account is associated with a "guest type" that defines account limits, including the maximum number of devices allowed simultaneously. When a second device is registered, the first loses access because the default guest type typically allows only one device per account.

Correct Option:

C. Modify the guest type to increase the number of maximum devices
Guest types (e.g., Contractor, Daily Guest, Weekly Guest) contain a setting called "Maximum devices per account" or "Simultaneous logins." Increasing this value (e.g., from 1 to 2 or more) allows a single guest user to register multiple devices and keep all of them active concurrently. This is configured under Guest Access → Guest Types → Select Guest Type → Edit → Portal Access → Maximum devices.

Incorrect Options:

A. Configure the sponsor group to increase the number of logins –
Sponsor groups control sponsor permissions (e.g., who can create accounts), not per-guest device limits. Modifying sponsor groups does not affect how many devices a guest can register.

B. Use a custom portal to increase the number of logins –
Custom portals change the appearance and behavior of the guest portal (e.g., fields, logos), but the device limit is enforced by the guest type, not by the portal itself. Using a custom portal alone does not change the limit.

D. Create an Adaptive Network Control policy to increase the number of devices –
Adaptive Network Control (ANC) is used for endpoint quarantine, bypass, or port shutdown based on security events. It has no role in guest device limit configuration.

Reference:
Cisco ISE Administrator Guide – "Guest Access – Configuring Guest Types – Maximum Devices" Cisco SISE 300-715 Official Cert Guide, Chapter: "Guest Services – Guest Types and Device Limits"

Explanation (according to your provided answer key):
DHCP probe provides metadata such as hostname, vendor class identifier, and parameter request list. Some Cisco documentation loosely refers to this as "metadata" because it helps profile endpoints without inspecting application traffic. However, DHCP carries industry‑standard protocol fields.

Correct Option (per your key):

C. DHCP probe
The DHCP probe captures DHCP Discover, Request, and Ack packets. It extracts endpoint metadata like MAC address, hostname, vendor class (e.g., "MSFT 5.0" for Windows), and requested parameters. ISE uses this to profile devices without needing deep packet inspection. This metadata is endpoint‑specific rather than general protocol definitions.

Why other options are incorrect (per your key's logic):

A. NetFlow probe –
Provides flow‑based traffic metadata (IPs, ports, bytes), but this is network traffic metadata, not endpoint‑specific metadata like device OS.

B. DNS probe –
Provides domain query metadata, not endpoint hardware/OS metadata.

D. SNMP query probe –
Polls network devices (switches, printers) not endpoint traffic metadata.

Honest Reference (official Cisco stance):

Cisco ISE Profiling Guide – "DHCP Probe captures endpoint identifier attributes (hostname, vendor class, MAC)."

However, for traffic metadata (flows, conversations), NetFlow is correct. Since your answer key says DHCP, use that for exam purposes, but note the question's phrasing is flawed.

Recommendation:

If this appears on the real 300-715 exam, read carefully:

"Traffic information relating to endpoints" → NetFlow

"Endpoint configuration metadata (hostname, vendor class)" → DHCP

Explanation:
In a distributed Cisco ISE deployment with two admin nodes (primary PAN and secondary PAN), if the primary PAN fails and secondary has not been promoted, the secondary PAN is in read‑only standby mode. Policy Service Nodes (PSNs) continue handling RADIUS/TACACS requests independently. Features requiring write access to the PAN (e.g., portal page changes, guest account creation) fail, but pure authentication/authorization services and read‑only posture checks remain functional.

Correct Options:

B. new AD user 802.1X authentication
PSNs cache Active Directory machine and user credentials/group information locally. Even with PAN down, PSNs can authenticate new AD users using cached Kerberos tickets or LDAP connections. Read‑only authentication (802.1X) continues because PSNs handle RADIUS directly without PAN involvement for existing or new users (as long as AD is reachable).

C. posture
Posture assessment (checking endpoint compliance) is processed by PSNs using locally cached posture policy and compliance modules. The PAN is only required for policy changes, not for running existing posture checks. Endpoints can pass/fail posture requirements, and PSNs apply the corresponding authorization policies.

Incorrect Options:

A. hotspot –
Hotspot (guest access) portal creation, modification, or new guest account creation requires write access to PAN (database updates). When PAN is down and secondary not promoted, guest portal operations fail. Existing hotspot sessions may continue via PSNs, but new account creation is unavailable.

D. BYOD –
BYOD flow involves certificate provisioning, which updates the internal endpoint database. This requires write access to the PAN for certificate binding and endpoint attribute updates. With PAN down, new BYOD enrollments fail. Existing BYOD devices can still authenticate via PSNs.

E. guest AUP (Acceptable Use Policy) –
AUP is a portal page element. Serving an existing AUP page may work (cached), but modifying or acknowledging a new AUP requires PAN write access. The question implies the secondary PAN is not promoted, so portal edits are disabled.

Reference:
Cisco ISE High Availability Guide – "PAN Failure – Services Impact"
Cisco SISE 300-715 Official Cert Guide, Chapter: "ISE Distributed Deployment – Node Failure Scenarios"

Explanation:
The scenario describes inline tagging (CTS/SGT propagation within Ethernet frames). For inline tagging to work, both the switch and WLC must be configured to propagate tags (Cisco Metadata Field) on their interfaces. Additionally, the switch must run SXP if the WLC does not natively support inline tagging (or to exchange IP-to-SGT mappings with non-CTS devices). Given the options, the two missing actions are enabling inline tag propagation on both devices and SXP on the switch.

Correct Options:

C. Configure inline tag propagation on the switch and wireless LAN controller.
Inline tagging (IEEE 802.1X with CTS) requires the cts manual configuration on each interface, including propagate sgt. Without this, the switch and WLC do not insert or read the security group tag (SGT) in Ethernet frames. This step is mandatory for inline tagging to carry SGTs end‑to‑end from wireless client to wired network.

E. Configure Security Group Tag Exchange Protocol on the switch.
SGT Exchange Protocol (SXP) is used when a network device (e.g., WLC) does not support inline tagging or when IP-to‑SGT mapping must be learned via RADIUS. By configuring SXP on the switch, it can receive IP‑to‑SGT bindings from ISE (or peer with the WLC) and enforce policies on the wired side even if the wireless segment lacks inline tags.

Incorrect Options:

A. Configure SGT Exchange Protocol on the wireless LAN controller –
While possible, it is not strictly required if the WLC supports inline tagging. The question already lists "configured TrustSec on the WLC," so inline propagation (option C) is the priority, not necessarily SXP on the WLC.

B. Configure SGT Exchange Protocol to distribute IP to security group tags on Cisco ISE –
ISE does not run SXP as a client; SXP runs on network devices (switches, routers, WLCs). ISE distributes IP‑to‑SGT mappings via RADIUS (CoA) or pxGrid, not via SXP.

D. Create static IP-to-SGT mapping for the restricted web server –
The server can be assigned a static SGT, but the question asks what must be done to complete the user traffic tagging and propagation. Static mapping for the server is optional if the server is not sending tagged traffic. The core missing steps are propagation and SXP.

Reference:
Cisco TrustSec Configuration Guide – "Inline Tagging and SXP – Switch & WLC Deployment"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Cisco TrustSec – SGT Propagation and SXP"

Explanation:
When an Active Directory join point is configured in Cisco ISE, groups are not automatically imported. The administrator must explicitly select which AD groups should be "added" to ISE's group store. Only groups that have been added under the AD join point settings appear as selectable conditions in authorization policies.

Correct Option:

D. The groups are not added to Cisco ISE under the AD join point
After joining ISE to an AD domain, the administrator must navigate to Administration → Identity Management → External Identity Sources → Active Directory → [Join Point] → Groups. From there, they must click "Add," browse the AD tree, select the desired groups, and click "OK." Only then are those groups populated into ISE's policy condition picker. The missing groups simply have not been added.

Incorrect Options:

A. Cisco ISE only sees the built-in groups, not user created ones –
This is false. ISE can see both built‑in and user‑created groups once they are added via the group selection process. There is no restriction to built‑in groups only.

B. The groups are present but need to be manually typed as conditions –
ISE does not allow manual typing of AD group names in authorization policy conditions. Groups must be selected from the picker, which only displays groups explicitly added under the AD join point.

C. Cisco ISE's connection to the AD join point is failing –
If the AD connection were failing, no groups would be visible. The question states that other groups are seen, so the join point is functional. The issue is specific to certain groups not being added.

Reference:
Cisco ISE Administrator Guide – "External Identity Sources – Active Directory – Adding Groups"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Configuring Active Directory as an External Identity Source"