Free Cisco 300-715 Practice Questions 2026 | Implementing and Configuring Cisco Identity Services Engine (SISE) v4.0 (300-715 SISE)

Explanation:
When a user marks a device as stolen via the My Devices Portal, Cisco ISE moves the device to the Blocklist endpoint identity group. Once the device is recovered, the user can change its status from "Stolen" to "Not Registered" (or "Registered" depending on portal version). This removes the device from the Blocklist group and allows re‑onboarding.

Correct Option:

B. Change the device state from Stolen to Not Registered.
In the My Devices Portal, the user can edit the device's status. Changing from "Stolen" to "Not Registered" tells ISE to remove the device from the Blocklist group and revert its registration status. The device can then be re‑onboarded (re‑registered) through the BYOD portal. This is the correct user‑self‑service action without administrator intervention.

Incorrect Options:

A. Manually remove the device from the Blocklist endpoint identity group –
Regular users do not have access to ISE administration interfaces (Administration → Identity Management → Endpoints). Only administrators can manually edit endpoint identity groups. This is not possible from the My Devices Portal.

C. Change the BYOD registration attribute of the device to None –
The My Devices Portal does not present a "BYOD registration attribute" field. Users change device state (Registered, Stolen, Not Registered), not raw attributes.

D. Delete the device, and then re‑add the device –
Deleting the device removes it from the user's portal list, but the endpoint may still remain in the Blocklist group with a stale record. Re‑adding (re‑onboarding) may fail because the MAC address is still associated with the Blocklist. Changing the status is the correct method.

Reference:
Cisco ISE BYOD User Guide – "My Devices Portal – Marking Device as Stolen and Recovery"
Cisco SISE 300-715 Official Cert Guide, Chapter: "BYOD – My Devices Portal and Blocklist Management"

Explanation:
In Cisco ISE, Network Device Groups (NDGs) are used to categorize network devices (switches, WLCs, routers) based on location, type, or other custom attributes. To identify a device as a "Medical Switch" for policy differentiation, the administrator must change the Device Type NDG. Device Type is a configurable NDG under Network Resources → Network Device Groups.

Correct Option:

A. Change the device type to Medical Switch.
Under Administration → Network Resources → Network Devices → Edit Device, there is a section for Device Type (a user‑defined network device group). By selecting or creating a Device Type called "Medical Switch", ISE can then use that NDG in authorization and authentication policies (e.g., Network Device Type EQUALS Medical Switch). This allows separate policies for endpoints connecting through those switches.

Incorrect Options:

B. Change the device profile to Medical Switch –
"Device Profile" is not a standard network device group. ISE uses profiles for endpoint profiling (e.g., "Apple-iPhone"), not for network devices.

C. Change the model name to Medical Switch –
The model name field is free‑form text (e.g., "Cisco Catalyst 9300"). Changing it to "Medical Switch" would break accuracy and is not the intended method for grouping devices.

D. Change the device location to Medical Switch –
Location is another NDG (e.g., "Building1", "CampusA"), but the requirement is to identify the device as a "Medical Switch" (type/role), not a geographical location.

Reference:
Cisco ISE Administrator Guide – "Network Device Groups (NDGs) – Device Type"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Network Resources – Network Device Group Configuration"

Explanation:
Guest endpoint registrations (MAC addresses) are stored in the Guest Endpoints identity store. Even if the guest account expires, the endpoint record may remain and allow continued access (depending on authorization rules). The Endpoint Purge Policy controls how long an endpoint remains in the database after last seen. If set to 30 days, the endpoint persists beyond the one‑day guest validity, causing continued access.

Correct Option:

A. The Endpoint Purge Policy is set to 30 days for guest devices
The Endpoint Purge Policy (Administration → Identity Management → Settings → Endpoint Purge) determines how many days an endpoint remains in ISE after its last activity. If guest endpoints are not purged for 30 days, the MAC address stays in the Guest Endpoints store. An authorization rule that allows access based on endpoint presence (e.g., Endpoints:IdentityGroup EQUALS GuestEndpoints) will continue to grant access even after the guest account expires, until the purge occurs.

Incorrect Options:

B. The RADIUS policy set for guest access is set to allow repeated authentication of the same device –
RADIUS policy set does not have a "repeated authentication" setting that overrides expiry. Authentication may succeed if the endpoint is still present.

C. The length of access is set to 7 days in the Guest Portal Settings –
This would cause access for 7 days, not one day. The administrator wanted one day, but the observed problem is access after one day. This could be a misconfiguration, but the question states the endpoint persists and allows access after the intended one‑day period. The purge policy is the direct cause of endpoint survival.

D. The Guest Account Purge Policy is set to 15 days –
Guest Account Purge removes expired guest accounts (username/password records), not the endpoint MAC address records. Endpoint records are controlled by Endpoint Purge Policy, not Guest Account Purge Policy.

Reference:
Cisco ISE Administrator Guide – "Endpoint Purge Policy – Guest Endpoints"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Guest Services – Endpoint Purge vs. Guest Account Purge"

Explanation:
Both Join and Leave operations in Active Directory require the ability to search the domain to determine if the Cisco ISE machine account already exists. For a Join operation, ISE checks for an existing account before creating one. For a Leave operation, ISE searches for the account to remove it. This search permission is common to both operations.

Correct Option:

D. Search Active Directory to see if a Cisco ISE machine account already exists.
Before joining a domain, ISE must search AD to see if a computer account with the same name already exists (to avoid conflicts). Before leaving (unjoining) a domain, ISE must search AD to locate the machine account to be removed. Both operations require the ability to perform LDAP search queries against the domain. The AD user account used for join/leave must have Read permissions to search the domain.

Incorrect Options:

A. Create a Cisco ISE machine account in the domain –
This is required only for Join (creating a new computer object), not for Leave (removing the object). Not common to both.

B. Remove the Cisco ISE machine account from the domain –
This is required only for Leave (deleting the computer object), not for Join. Not common to both.

C. Set attributes on the Cisco ISE machine account –
Setting attributes (e.g., SPN, description) is typically done during Join or post‑Join operations, but not during Leave. Not a common permission.

Reference:
Cisco ISE Administrator Guide – "Active Directory Join and Leave – Required Permissions"
Cisco SISE 300-715 Official Cert Guide, Chapter: "External Identity Sources – AD Join/Leave Operations"

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"