Free 300-715 Practice Test Questions 2026

Explanation:
The described flow (MAB request → ISE returns URL redirection → user sees AUP page) is the classic Central Web Authentication (CWA) flow. The ISE node (central server) handles the redirection and hosts the AUP page. The network access device (NAD) — in this case a WLC or switch — redirects HTTP traffic to ISE.

Correct Option:

D. NAD with central WebAuth
Central Web Authentication (CWA) uses the NAD (WLC or switch) to intercept HTTP traffic and redirect the client to a portal hosted on ISE. The steps match exactly: (1) MAB request to ISE, (2) ISE returns a redirect ACL via RADIUS, (3) NAD redirects the user to an ISE portal (AUP page). This is the standard deployment for guest access with Acceptable Use Policy (AUP).

Incorrect Options:

A. device registration WebAuth –
Device registration WebAuth is typically part of BYOD flows, not a simple AUP acceptance for guests. It often involves certificate enrollment.

B. WLC with local WebAuth –
Local WebAuth means the WLC hosts the portal itself, not ISE. The described flow sends a MAB request to ISE and ISE returns a redirect — that is central, not local.

C. wired NAD with local WebAuth –
Local WebAuth on a wired switch would mean the switch hosts the portal. The description explicitly says the MAB request is sent to ISE and ISE responds with URL redirection — that is central.

Reference:
Cisco ISE Central Web Authentication Guide – "CWA Flow – MAB Redirect to AUP Portal"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Guest Services – Central Web Authentication (CWA)"

Explanation:
To remove static ACLs from switch ports and let ISE dictate access, Security Group Tags (SGTs) can be assigned to endpoints via authorization policies. The switch then uses SGACLs (Security Group ACLs) to enforce communication rules between SGTs, eliminating per‑port ACLs entirely.

Correct Option:
A. security group tag within the authorization policy
In a Cisco TrustSec deployment, ISE assigns an SGT to an endpoint during authorization. The switch enforces policies based on SGT‑to‑SGT rules (SGACLs) rather than per‑port ACLs. This centralizes policy management in ISE and removes static ACL configuration from switch ports. SGT assignment is done within the authorization policy (under "Security Group" or "SGT").

Incorrect Options:
B. extended access-list on the switch for the client –
This is the opposite goal; the organization wants to remove static ACLs, not add more.

C. port security on the switch based on the client's information –
Port security limits MAC addresses on a port, not dynamic access control from ISE.

D. dynamic access list within the authorization profile –
dACLs (RADIUS downloadable ACLs) also allow ISE to push ACLs, but they are still ACLs (per‑user, not per‑port). The question specifies "remove static ACLs on the switch ports" and allow ISE to communicate what access to provide — both SGTs and dACLs can do this, but SGTs are the more comprehensive trust‑based solution.

Reference:
Cisco TrustSec and ISE Integration Guide – "Authorization Policies – Assigning SGT"
Cisco SISE 300-715 Official Cert Guide, Chapter: "TrustSec – SGT vs. dACL for Centralized Policy Enforcement"

Explanation:
For a Catalyst switch to support standard web authentication (Central Web Authentication or local web authentication) with Cisco ISE, including URL redirection, the switch must have an HTTPS web server enabled. The required commands are ip http server (enables HTTP server) and ip http secure-server (enables HTTPS server). Redirection typically uses HTTPS for secure portal communication.

Correct Options:

B. ip http server
This global command enables the switch's HTTP server. The web authentication feature requires the HTTP server to be operational to intercept HTTP requests and redirect clients to the ISE portal. Without this, web redirection will not function.

D. ip http secure-server
This global command enables the HTTPS (HTTP over SSL/TLS) server on the switch. For secure web authentication (HTTPS redirection), this is required. ISE portals typically use HTTPS, and the switch must listen on port 443 for secure redirection.

Incorrect Options:

A. ip http secure-authentication –
This is not a valid Cisco IOS command. The correct command for HTTPS server is ip http secure-server.

C. ip http redirection –
Not a valid Cisco IOS command. Redirection is configured via ACLs and authorization profiles, not a separate ip http command.

E. ip http authentication –
Not a valid command. Authentication for web access to the switch itself (for management) is configured via ip http authentication in some versions, but that is for switch management access, not for endpoint web authentication redirect.

Reference:
Cisco Catalyst Switch Configuration Guide – "Web Authentication – Enabling HTTP/HTTPS Server"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Web Authentication – Switch Configuration Commands"

Explanation:
RADIUS encrypts only the password field (user password) in the Access-Request packet, leaving the rest of the packet (username, NAS-IP, etc.) in clear text. TACACS+ encrypts the entire payload (body) of the packet, including username, password, authorization data, and accounting attributes. Only the standard TACACS+ header remains unencrypted.

Correct Option:

C. RADIUS only encrypts the password field, whereas TACACS+ encrypts the payload of packet.
This is accurate: RADIUS uses MD5 hashing to encrypt the password attribute only (e.g., User-Password). All other attributes (username, calling-station-id, framed-ip) are sent in clear text. TACACS+ encrypts the complete body of the packet (everything after the header) using a per‑session key derived from the shared secret.

Incorrect Options:

A. RADIUS encrypts only the username and password fields –
RADIUS does not encrypt the username. Only the password field is encrypted. Username is sent in clear text.

B. RADIUS encrypts the entire packet –
False. RADIUS encrypts only the password. TACACS+ encrypts the entire packet body.

D. RADIUS encrypts the entire packet, whereas TACACS+ encrypts only the username and password fields –
False. This reverses the correct behavior.

Reference:

RFC 2865 (RADIUS) – Section 3: Password hiding
RFC 8907 (TACACS+) – Section 3: Packet encryption (TACACS+ encrypts the body)
Cisco SISE 300-715 Official Cert Guide, Chapter: "RADIUS vs. TACACS+ – Encryption Comparison"

Explanation:
RADIUS and TACACS+ differ in transport protocol and AAA message separation. RADIUS uses UDP (ports 1812/1813 for authentication/accounting), while TACACS+ uses TCP port 49. Additionally, RADIUS combines authentication and authorization in the same Access-Request/Access-Accept exchange, whereas TACACS+ separates authentication, authorization, and accounting into distinct phases.

Correct Options:

B. TACACS+ uses TCP port 49, whereas RADIUS uses UDP ports 1812 and 1813.
TACACS+ uses TCP port 49 (reliable, connection‑oriented). RADIUS uses UDP port 1812 for authentication/authorization and UDP port 1813 for accounting (older RADIUS used ports 1645/1646). UDP is connectionless, which can lead to different retransmission behavior.

D. RADIUS combines authentication and authorization, whereas TACACS+ does not
RADIUS combines authentication and authorization into a single exchange. The Access-Accept packet contains both authentication success and authorization attributes (VLAN, ACL). TACACS+ separates them: Authentication occurs first (using one exchange), followed separately by Authorization (another exchange), providing more granular control.

Incorrect Options:

A. RADIUS is a Cisco proprietary protocol, whereas TACACS+ is an open standard protocol –
False. RADIUS is an open IETF standard (RFC 2865). TACACS+ was developed by Cisco and is mostly Cisco‑specific, though the specification is publicly available.

C. RADIUS offers multiprotocol support, whereas TACACS+ does not –
False. TACACS+ also supports multiprotocol (IP, IPX, AppleTalk, etc.), though in practice both are used primarily for IP.

E. RADIUS enables encryption of all the packets, whereas with TACACS+, only the password is encrypted –
False. This is the opposite: RADIUS encrypts only the password; TACACS+ encrypts the entire packet payload.

Reference:
RFC 2865 (RADIUS) – UDP ports and authentication/authorization combination
RFC 8907 (TACACS+) – TCP port 49 and AAA separation
Cisco SISE 300-715 Official Cert Guide, Chapter: "RADIUS vs. TACACS+ – Key Differences"

Explanation:
For network device administration (as opposed to network access control), TACACS+ offers significant advantages over RADIUS. Two key benefits are command authorization (granular control over which CLI commands an administrator can execute) and full payload encryption (the entire packet body is encrypted, not just the password).

Correct Options:

D. TACACS+ provides the ability to authorize specific commands while RADIUS does not
TACACS+ supports command authorization: after authentication, the TACACS+ server (ISE) can authorize individual CLI commands or command patterns (e.g., allow show running-config but deny configure terminal). RADIUS does not have this capability; it is limited to authentication and basic authorization (e.g., privilege level 15). This makes TACACS+ the preferred protocol for device administration.

E. TACACS+ encrypts the entire payload being sent while RADIUS only encrypts the password
TACACS+ encrypts the entire packet payload (username, password, authorization data, accounting information), leaving only the header unencrypted. RADIUS encrypts only the password attribute (User-Password); the username, NAS-IP, and other attributes are sent in clear text. For device administration, full encryption is a clear advantage.

Incorrect Options:

A. TACACS+ is FIPS compliant while RADIUS is not –
Both protocols can be made FIPS‑compliant when configured properly (e.g., RADIUS over IPsec or RADSEC). This is not an inherent advantage of TACACS+.

B. TACACS+ is designed for network access control while RADIUS is designed for role‑based access –
False. RADIUS is designed for network access control (802.1X, VPN). TACACS+ is designed for device administration (router/switch login). The statement reverses their typical roles.

C. TACACS+ uses secure EAP-TLS while RADIUS does not –
False. EAP‑TLS is an EAP method used with RADIUS for network access authentication. TACACS+ does not use EAP‑TLS; it has its own authentication mechanisms (PAP, CHAP, MSCHAPv1).

Reference:
Cisco ISE Device Administration Guide – "TACACS+ vs RADIUS – Command Authorization and Encryption"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Device Administration – TACACS+ Benefits"

Explanation (per exam key):
In a distributed Cisco ISE deployment, Policy Service Nodes (PSNs) can be deployed in a failover configuration for RADIUS/TACACS+ sessions. If one PSN fails, the network device (NAD) can forward requests to another PSN. This provides session failover continuity for authentication and posture sessions.

Correct Option:

D. Policy Service nodes for session failover
Multiple PSNs can be deployed in a distributed environment. NADs are configured with multiple RADIUS servers (PSNs) in priority order. If the primary PSN becomes unavailable, the NAD sends requests to the secondary PSN, providing failover for active sessions (re‑authentication may be required). This is a supported capability in distributed ISE deployments.

Incorrect Options:

A. Policy Service nodes for automatic failover –
"Automatic failover" is ambiguous. NADs can retry to secondary PSNs, but ISE does not provide automatic session state synchronization between PSNs for seamless failover.

B. Administration nodes for session failover –
Administration nodes (PAN) handle configuration and system management, not RADIUS sessions. They do not process authentication requests.

C. Monitoring nodes for pxGrid services –
MnT nodes do not run pxGrid. pxGrid runs on PSNs or dedicated pxGrid nodes.

Reference:
Cisco ISE Distributed Deployment Guide – "Policy Service Node (PSN) Failover"
Cisco SISE 300-715 Official Cert Guide, Chapter: "ISE Deployment Models – PSN Redundancy and Failover"

Explanation:
When multiple vendor firewall applications are in use, creating individual application conditions for each vendor is inefficient. Cisco ISE provides a default firewall condition (in posture policies) that checks for the presence of any enabled host‑based firewall (Windows Firewall, McAfee, Symantec, etc.) without requiring vendor‑specific checks. This meets the requirement to ensure some firewall is in place.

Correct Option:

C. Enable the default firewall condition to check for any vendor firewall application.
Under Cisco ISE posture policies, there is a predefined Firewall condition (e.g., "Windows Firewall Status" or "Firewall – Any Enabled Firewall"). This condition uses OPSWAT or native OS checks to detect if any host‑based firewall is installed and running, regardless of vendor. This is the correct solution when multiple firewall products are deployed.

Incorrect Options:

A. Use the file/registry condition to ensure that the firewall is installed and running appropriately –
File/registry conditions are vendor‑specific. Since the organization has multiple vendors, creating conditions for each would be required. The question states engineers are unable to use a specific application check, so this approach fails.

B. Use a compound condition to look for the Windows or Mac native firewall applications –
This only covers native firewalls (Windows Defender Firewall, macOS firewall). Third‑party firewalls (McAfee, Symantec) would not be detected. Does not cover "multiple vendors."

D. Enable the default application condition to identify the applications installed and validate the firewall app –
The default application condition (e.g., "Any Firewall") is essentially what option C describes, but C explicitly states "default firewall condition." The exam key points to C as the precise answer.

Reference:
Cisco ISE Posture Administration Guide – "Posture Conditions – Firewall (Default Condition)"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Posture – Default Firewall Checks for Multi‑Vendor Environments"

Explanation:
On a Cisco Wireless LAN Controller (WLC), Cisco Discovery Protocol (CDP) profiling can provide detailed device information (device type, platform, capabilities) about connected devices. The WLC can forward CDP information to ISE via RADIUS accounting or profiling probes. This is particularly useful for identifying IP phones, switches, or other Cisco devices connecting via wireless.

Correct Option:

B. CDP
CDP (Cisco Discovery Protocol) is a Layer 2 protocol that Cisco devices (including IP phones, switches, routers) use to advertise their identity, platform, capabilities, and neighbor information. When enabled on the WLC, CDP information from connected devices can be included in RADIUS accounting messages or collected via profiling. ISE uses this metadata for endpoint classification and authorization policies.

Incorrect Options:

A. DNS –
DNS (Domain Name System) resolves hostnames to IP addresses. While ISE can use DNS for profiling (hostname lookup), the WLC does not "profile" using DNS in the sense of sending device metadata to ISE.

C. DHCP –
DHCP profiling is common on wired switches (via DHCP snooping), but on a WLC, DHCP information is already available (client IP, hostname, vendor class). However, CDP provides richer device identity (especially for Cisco endpoints) and is specifically the correct answer for device discovery on a Cisco WLC.

D. ICMP –
ICMP (ping, traceroute) is not used for passive profiling. ICMP can test connectivity but does not provide device metadata.

Reference:
Cisco Wireless Controller Configuration Guide – "CDP Profiling for Endpoint Identification"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Profiling – CDP on WLC for Device Classification"

Explanation:
The dot1x system-auth-control command is entered in global configuration mode on a Cisco Catalyst switch. It globally enables 802.1X authentication on the switch, allowing 802.1X to be configured on individual interfaces. Without this command, 802.1X cannot be activated on any port.

Correct Option:

B. globally enables 802.1x
dot1x system-auth-control is the global command that enables the 802.1X authentication framework on the switch. Once this command is issued, individual interfaces can be configured with dot1x pae authenticator and authentication port-control auto. It is a prerequisite for any 802.1X operation on the switch.

Incorrect Options:

A. causes a network access switch not to track 802.1x sessions –
False. This command enables 802.1X and session tracking, not disables it.

C. enables 802.1x on a network access device interface –
This is an interface‑level command (e.g., dot1x pae authenticator), not the global command.

D. causes a network access switch to track 802.1x sessions –
While the switch does track sessions, this is a side effect, not the primary description. The primary purpose is to globally enable 802.1X.

Reference:
Cisco Catalyst Switch Command Reference – dot1x system-auth-control
Cisco SISE 300-715 Official Cert Guide, Chapter: "Configuring 802.1X on Cisco Switches – Global Enablement"

Explanation:
When configuring a Native Supplicant Profile for wired devices (used with posture agents), two critical settings define how the supplicant authenticates. The Allowed Protocol (e.g., EAP‑TLS, PEAP) determines which EAP methods are permitted, and the Certificate Template (if using EAP‑TLS) defines the certificate used for authentication. These directly impact connection testing and profile availability.

Correct Options:

C. certificate template
The certificate template specifies which client certificate (e.g., machine certificate, user certificate) the native supplicant uses for EAP‑TLS authentication. This is essential for wired 802.1X testing, especially when posture agents are involved. Without a certificate template, EAP‑TLS cannot function.

E. allowed protocol
The allowed protocol setting (e.g., EAP‑TLS, PEAP) defines which authentication protocols the native supplicant will attempt. For wired devices, this must match the authentication policy on the switch and ISE. This setting directly affects connectivity testing.

Incorrect Options:

A. authentication mode –
Authentication mode (e.g., user authentication, machine authentication) is a separate configuration, but it is not typically listed as a primary setting within the Native Supplicant Profile wizard alongside certificate and protocol. The exam key points to C and E.

B. proxy host/IP –
Proxy settings are for client provisioning portal access or posture agent updates, not for native supplicant authentication configuration.

D. security –
"Security" is too generic. It may refer to 802.1X settings, but the specific configurable parameters are allowed protocol, certificate template, and authentication mode.

Reference:
Cisco ISE Client Provisioning Guide – "Native Supplicant Profile – Wired Settings (Certificate Template, Allowed Protocols)"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Client Provisioning – Native Supplicant Profile Configuration"

Explanation:
To mitigate brute force attacks on guest passwords, the password policy must enforce strength (complexity) and lifespan (regular change). Minimum password length (e.g., 8 characters) increases the search space for brute force, while password expiration ensures that even if a password is compromised, it remains valid only for a limited time.

Correct Options:

A. minimum password length
Setting a minimum password length (e.g., 8, 10, or 12 characters) increases the number of possible combinations, making brute force and dictionary attacks significantly more time‑consuming and resource‑intensive. This is a fundamental password complexity requirement.

D. password expiration period
A password expiration period forces the guest to change the password after a defined number of days (e.g., 1 day, 7 days). This limits the window of opportunity for an attacker who has obtained a valid password, reducing the impact of a successful brute force or credential theft.

Incorrect Options:

B. active username limit –
This limits the number of concurrent active users with the same username, not password complexity. It does not directly mitigate brute force attacks.

C. access code control –
Not a standard Cisco ISE guest password policy setting. "Access code" may refer to one‑time codes, but it is not a complexity requirement.

E. username expiration date –
Username expiration is account‑level (the entire guest account expires), not a password policy setting for mitigating brute force attacks during the account's validity.

Reference:
Cisco ISE Guest Access Guide – "Guest Password Policy – Complexity and Expiration Settings"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Guest Services – Password Policies for Brute Force Mitigation"