Free 300-715 Practice Test Questions 2026

Explanation:
On a Cisco Catalyst switch, enabling 802.1X authentication requires two main steps globally and one interface-level command. At the interface level, the command dot1x pae authenticator configures the port to act as an 802.1X authenticator, initiating authentication with connected supplicants.

Correct Option:

A. dot1x pae authenticator
The dot1x pae authenticator interface command enables the port to serve as an 802.1X authenticator (Port Access Entity). This command triggers the switch to send EAP-Request/Identity packets to connected devices and start the authentication process. Without this command, the port does not participate in 802.1X authentication.

Incorrect Options:

B. dot1x system-auth-control –
This is a global configuration command, not interface-level. It enables 802.1X authentication system-wide on the switch but does not activate it on individual ports.

C. authentication host-mode single-host –
This interface command defines how many hosts are allowed on the port (single-host, multi-host, multi-domain). It does not turn on 802.1X authentication itself; it only controls host behavior after authentication is enabled.

D. aaa server radius dynamic-author –
This global command enables the switch to act as a RADIUS dynamic authorization client (for CoA). It has nothing to do with enabling 802.1X on an interface.

Reference:
Cisco Catalyst Switch Configuration Guide – "Configuring 802.1X – Interface Commands"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Configuring Network Access Devices for 802.1X"

Explanation:
Cisco ISE's NetFlow probe listens for incoming NetFlow exports from network devices such as routers and switches. Different NetFlow versions use different default UDP ports. For NetFlow version 9, the default port is UDP 9996.

Correct Option:

A. UDP 9996
The NetFlow probe in Cisco ISE uses UDP port 9996 for NetFlow version 9 by default. This is configurable in the probe settings (Administration → System → Deployment → Edit Node → Profiling Configuration → NetFlow). Network devices exporting NetFlow v9 must be configured to send flows to this port.

Incorrect Options:

B. UDP 9997 –
Cisco ISE does not use UDP 9997 as a default port for any standard probe. Some documentation references this for IPFIX, but the standard NetFlow v9 port is 9996.

C. UDP 9998 –
Not the default for NetFlow v9. UDP 9998 is sometimes used for other services but not for ISE NetFlow probes.

D. UDP 9999 –
This is the default port for NetFlow version 5 in Cisco ISE, not version 9. NetFlow v5 uses UDP 9999.

Reference:
Cisco ISE Profiling Configuration Guide – "NetFlow Probe – Default Ports"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Profiling – NetFlow Probe Configuration"

Explanation:
In Cisco ISE BYOD flows, a Native Supplicant Profile defines how the endpoint's built-in supplicant (e.g., Windows Wired AutoConfig, iOS 802.1X settings) is configured automatically. Two mandatory components are the Operating System (to apply correct settings) and Connection Type (e.g., Wireless or Wired).

Correct Options:

B. Connection Type
The Native Supplicant Profile requires specifying whether the profile is for Wireless (Wi-Fi) or Wired (Ethernet) connections. This determines which supplicant settings are pushed (SSID vs. interface selection). Without a connection type, ISE cannot generate the correct configuration payload.

E. Operating System
The profile must target a specific operating system (e.g., Windows 10, macOS, iOS, Android). Each OS has different supplicant configuration methods and XML/Profile formats. ISE uses the OS selection to deliver the correct configuration template (e.g., Windows uses WLAN Profile XML; iOS uses mobileconfig).

Incorrect Options:

A. Windows Settings –
These are optional and specific to Windows OS only. If the OS is not Windows, Windows Settings are irrelevant. Not a mandatory component for every Native Supplicant Profile.

C. iOS Settings –
Optional and specific to iOS only. Not required when the profile is for Windows or Android.

D. Redirect ACL –
Redirect ACLs are used in authorization profiles for guest portal redirection, not as a component of a Native Supplicant Profile. They are unrelated to supplicant configuration.

Reference:
Cisco ISE BYOD Configuration Guide – "Native Supplicant Profiles – Required Components"
Cisco SISE 300-715 Official Cert Guide, Chapter: "BYOD – Native Supplicant Provisioning"

Explanation (per your answer key):
The DHCP probe captures endpoint identification metadata (hostname, MAC, vendor class) from DHCP requests and acknowledgments. This information helps ISE profile devices and apply network access policies. While not strictly "traffic," DHCP is commonly used for endpoint visibility.

Correct Option (per your key):

D. Configure the DHCP probe within Cisco ISE
The DHCP probe passively listens for DHCP packets (Discover, Offer, Request, Ack) on the network. It extracts metadata such as MAC address, hostname, vendor class identifier (e.g., "MSFT 5.0" for Windows), and parameter request list. ISE uses this to profile endpoints (e.g., identify printers, phones, laptops) and enforce access policies.

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

A. Configure the RADIUS profiling probe –
RADIUS probe captures authentication metadata (username, Framed-IP, Calling-Station-ID). It does not reveal endpoint traffic patterns or DHCP-level metadata.

B. Configure NetFlow to be sent to the Cisco ISE appliance –
NetFlow captures traffic flow metadata (IPs, ports, ToS bits). This is ideal for "traffic going across the network," but your key does not select it.

C. Configure SNMP to be used with the Cisco ISE appliance –
SNMP queries network devices (switches, printers) but does not passively capture client traffic metadata from DHCP.

Reference (per your key's intent):
Cisco ISE Profiling Guide – "DHCP Probe – Endpoint Metadata Collection"

Honest note for your exam preparation:
If the exam question specifically says "metadata information about the traffic going across the network" (i.e., flow data), the correct answer is NetFlow (B). If the question emphasizes endpoint identification metadata (hostname, OS, MAC), DHCP is correct. Be prepared for both interpretations on the real 300-715 exam.

Explanation:
When reviewing reports in Cisco ISE, TACACS+ offers granular visibility into command-level accounting (what commands were executed on a device), while RADIUS primarily reports on network access sessions (connect/disconnect). This is a key reporting advantage for device administration.

Correct Option:

C. TACACS+ provides command accounting, and RADIUS combines authentication and authorization.
TACACS+ separates authentication, authorization, and accounting into distinct processes. Its accounting logs include each command entered by an administrator, including timestamps, command strings, and success/failure status. RADIUS combines authentication and authorization in a single Access-Request/Accept exchange, and its accounting typically records session start/stop and data usage, not individual commands. For compliance reports, command accounting is a major advantage.

Incorrect Options:

A. TACACS+ reduces authentication latency, and RADIUS increases latency –
False. TACACS+ uses TCP (potentially higher latency), while RADIUS uses UDP (lower latency). Latency differences are negligible in reporting context.

B. TACACS+ performs secure communication with IPsec, and RADIUS uses DTLS encryption –
Both can be secured. RADIUS with DTLS (RADSEC) or IPsec; TACACS+ can use IPsec or TLS. This is not a reporting advantage.

D. TACACS+ uses SSL certificates, and RADIUS does not have encryption –
False. RADIUS encrypts only the password (using MD5), while TACACS+ encrypts the entire body. Modern RADIUS (RADSEC over TLS) addresses this. The reporting advantage is command accounting, not encryption.

Reference:
Cisco ISE Device Administration Guide – "TACACS+ Accounting vs. RADIUS Accounting – Reporting Differences"

Explanation:
The engineer needs to disable 802.1X authentication on switchports while still allowing all endpoints to connect without any authentication. The port-control option force-authorized places the port in an authorized state permanently, bypassing all authentication.

Correct Option:

D. force-authorized
The force-authorized port-control setting (configured via authentication port-control force-authorized) disables 802.1X authentication on the interface. The port immediately moves to an authorized state without any EAP exchange or RADIUS communication. All traffic is allowed unconditionally. This is equivalent to turning off 802.1X on the port, which meets the requirement of disabling authentication while maintaining connectivity.

Incorrect Options:

A. pae-disabled –
This is not a valid port-control option. The pae command (dot1x pae authenticator) has authenticator or supplicant options, not pae-disabled. This would not correctly disable authentication.

B. force-unauthorized –
This forces the port into an unauthorized state, blocking all traffic except EAPOL (802.1X). Endpoints would not be able to connect. This is the opposite of what is required.

C. auto –
The auto (or automatic) port-control setting enables 802.1X authentication. The port starts unauthorized and only becomes authorized after successful authentication. This does not disable authentication.

Reference:
Cisco Catalyst Switch Command Reference – authentication port-control force-authorized
Cisco SISE 300-715 Official Cert Guide, Chapter: "Configuring 802.1X – Port-Control Modes"

Explanation:
Pushing supplicant profiles (e.g., Native Supplicant Profiles, AnyConnect configuration) to endpoints is part of client provisioning. In Cisco ISE, this traffic originates from the Policy Service Node (PSN), which hosts all portal services including client provisioning portals.

Correct Option:

B. policy service
The Policy Service persona (PSN) hosts the Client Provisioning portal, which delivers supplicant profiles, posture agents, and anyconnect configuration to endpoints. When a workstation connects and triggers the provisioning flow, it downloads the profile from the PSN's built-in web server (typically over TCP ports 8443 or 8905 for HTTPS). In a lab without an external deployment server, the PSN directly serves these profiles to endpoints.

Incorrect Options:

A. monitoring –
The Monitoring (MnT) node handles logs, alerts, and reports. It does not host client provisioning portals nor serve supplicant profiles to endpoints. MnT is passive for client traffic.

C. administration –
The Administration (PAN) node manages configuration and policies but does not directly serve supplicant profiles to endpoints. All client-facing services (portals, downloads) run on PSNs.

D. authentication –
This is not a Cisco ISE persona. Authentication is a service provided by the Policy Service persona. There is no "authentication" node type.

Reference:
Cisco ISE Client Provisioning Guide – "Client Provisioning Portals – PSN Requirements"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Client Provisioning – Ports and Personas"

Explanation:
Posture conditions in Cisco ISE check endpoint compliance. To verify that specific services (e.g., Windows Service "DHCP Client" or "Symantec Endpoint Protection") are running on a workstation, a Service posture condition must be created. The non-OPSWAT API version is used when the service check does not rely on an external anti-malware vendor's OPSWAT library.

Correct Option (per your key):

D. Create a service posture condition using a non-OPSWAT API version.
Service posture conditions check for the presence, status, or startup type of Windows services (e.g., "Running," "Stopped," "Automatic"). The non-OPSWAT API version uses native WMI or registry queries without requiring an OPSWAT license. This is sufficient for checking standard Microsoft services or custom services not covered by OPSWAT's anti-malware definitions.

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

A. Create a registry posture condition using a non-OPSWAT API version –
Registry conditions check registry keys/values, not service status. While useful for many checks, they cannot verify if a service is currently running.

B. Create an application posture condition using an OPSWAT API version –
Application conditions check for installed software versions, not running services. OPSWAT is typically used for anti-malware definition versions.

C. Create a compound posture condition using an OPSWAT API version –
Compound conditions combine multiple conditions (AND/OR logic). The requirement is simply to check a service, not to combine multiple checks. OPSWAT is not relevant for basic service status.

Reference:
Cisco ISE Posture Administration Guide – "Posture Conditions – Service Conditions"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Posture – Configuring Service Checks"

Explanation:
To have a centralized server (Cisco ISE) control reauthentication timers instead of the local switch configuration, the switch must be configured to accept reauthentication timer values from the RADIUS server. The authentication timer reauthenticate server command enables this behavior.

Correct Option:

C. Issue the authentication timer reauthenticate server command on the switch.
This interface-level command configures the switch to use the reauthentication timer value provided by the RADIUS server (Cisco ISE) via the Session-Timeout or Termination-Action AVPs. Without this command, the switch uses its locally configured timer. When enabled, ISE can dynamically set different reauthentication intervals per endpoint or policy.

Incorrect Options:

A. Configure Cisco ISE to replace the switch configuration with new timers –
ISE cannot directly replace switch configuration. ISE sends RADIUS attributes, but the switch must be configured to accept them. The server command is required on the switch.

B. Configure Cisco ISE to block access after a certain period of time –
ISE can terminate sessions via CoA, but that is different from setting reauthentication timers. This does not address the requirement of using a centralized server for timers.

D. Issue the authentication periodic command on the switch –
The authentication periodic command enables periodic reauthentication but uses the locally configured timer. It does not instruct the switch to accept timers from the RADIUS server.

Reference:
Cisco Catalyst Switch Command Reference – authentication timer reauthenticate server
Cisco SISE 300-715 Official Cert Guide, Chapter: "Configuring 802.1X – Reauthentication Timers"

Explanation:
In a standalone Cisco ISE deployment, a single physical node runs all personas simultaneously. The restriction is that these personas (Administration, Policy Service, Monitoring) are enabled by default and cannot be individually disabled or modified; the node functions as an all-in-one appliance.

Correct Option:

C. Personas are enabled by default and cannot be edited on the node.
In a standalone deployment, after the initial installation, all three core personas (PAN, MnT, PSN) are active on the single node. Under Administration → System → Deployment, the checkboxes for these personas are greyed out or cannot be unchecked. Unlike distributed nodes where you can selectively enable/disable personas (e.g., run a node as PSN-only), the standalone node forces all personas to remain enabled.

Incorrect Options:

A. Only the Policy Service persona can be disabled on the node –
False. In standalone mode, no persona can be disabled. The system is designed to run all personas together. Disabling any persona would break core functionality.

B. The domain name of the node cannot be changed after installation –
False. The domain name (DNS suffix) can be changed in Administration → System → Settings → Windows Settings or via CLI. This is not a standalone-specific restriction.

D. The hostname of the node cannot be changed after installation –
False. The ISE node hostname can be changed using the CLI command hostname or through ise-apply-config. Changing hostname may require re-joining AD but is permitted.

Reference:
Cisco ISE Deployment Guide – "Standalone Deployment – Persona Restrictions"
Cisco SISE 300-715 Official Cert Guide, Chapter: "ISE Deployment Models – Standalone Limitations"

Explanation:
When authentication is disabled and third-party switches are used (which may not support Cisco TrustSec inline tagging or SXP), static SGT classification must rely on IP address to SGT mapping. This method uses the IP subnet or individual IP addresses to assign SGTs without requiring authentication or vendor-specific protocols.

Correct Option:

B. IP Address to SGT mapping
IP address to SGT mapping (configured via RADIUS or local CLI with cts sgt-map static) assigns a security group tag to traffic based on source or destination IP address. This works even when 802.1X or MAB is disabled and on third-party switches that do not support CTS or SXP. ISE can also push these mappings via RADIUS or they can be statically configured on the switch.

Incorrect Options:

A. VLAN to SGT mapping –
While possible, VLAN mapping is less granular and requires the switch to trust VLAN tags, which may not be reliable across third-party devices. Authentication is not required, but VLAN mapping is less common for static classification.

C. L3IF to SGT mapping –
Layer 3 interface to SGT mapping assigns an SGT to all traffic entering a specific routed interface. This does not require authentication but is less flexible than IP mapping and may not be supported uniformly on third-party switches.

D. Subnet to SGT mapping –
Subnet mapping is essentially a subset of IP address mapping. However, the standard Cisco term and configuration object is "IP Address to SGT mapping," which includes both individual IPs and subnets. The exam expects "IP Address to SGT mapping" as the correct answer.

Reference:
Cisco TrustSec Configuration Guide – "Static SGT Classification – IP Address to SGT Mapping"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Cisco TrustSec – SGT Classification Methods"

Explanation:
To restrict sponsor portal access to specific employees, the administrator must configure sponsor groups in Cisco ISE. Sponsor groups define which Active Directory or internal users/groups are permitted to log into the sponsor portal and create guest accounts. Modifying these groups ensures only authorized employees can sponsor guests.

Correct Option:

C. Modify the sponsor groups assigned to reflect the desired user groups.
Under Guest Access → Sponsor Groups, the administrator creates or edits a sponsor group and assigns specific user groups (e.g., "AD\Sponsors" or "ISE\HR-Employees") to that group. Only members of these assigned groups can authenticate to the sponsor portal. This is the primary method for restricting sponsor portal access to necessary employees.

Incorrect Options:

A. Configure an identity-based access list in Cisco ISE to restrict the users allowed to login –
Identity-based ACLs apply to network access (e.g., VLAN ACLs), not to portal authentication. The sponsor portal uses identity policies, not ACLs, for access control.

B. Edit the sponsor portal to only accept members from the selected groups –
The sponsor portal settings page allows you to select an "Allowed Sponsor Group," but you must first create and populate that sponsor group. Option C is the prerequisite action (modifying sponsor group assignments). The exam typically expects the group configuration as the answer.

D. Create an authorization rule using the Guest Flow condition to authorize the administrators –
Authorization rules control network access after authentication, not portal access. Guest Flow conditions are for redirecting unauthenticated users to portals, not for restricting sponsor login.

Reference:
Cisco ISE Guest Access Guide – "Sponsor Groups – Configuring Sponsor Access"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Guest Services – Sponsor Portal Authorization"