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

Explanation:
Many devices on a network (e.g., printers, IP phones, cameras, legacy equipment) do not support 802.1X supplicants. They cannot provide credentials via EAP. MAB (MAC Authentication Bypass) allows such devices to authenticate using their MAC address, ensuring they are not blocked while still providing visibility and accounting.

Correct Option:

C. The devices in the network do not have a supplicant.
MAB is used for endpoints that cannot run an 802.1X supplicant. These devices are "non‑supplicant" devices. The switch uses the device's source MAC address as the username and password, sends a RADIUS request to ISE, and grants access based on MAC address authorization. This provides authentication (weak, but functional) and visibility for devices that otherwise could not participate in port‑based authentication.

Incorrect Options:

A. The Cisco switches only support MAB –
Cisco switches support MAB, 802.1X, and web authentication simultaneously. Switches are not limited to MAB only. This statement is false.

B. MAB provides the strongest form of authentication available –
MAB is the weakest authentication method because MAC addresses can be spoofed. 802.1X with EAP‑TLS provides much stronger authentication.

D. MAB provides user authentication –
MAB authenticates the device (by MAC address), not a user. User authentication requires 802.1X (e.g., PEAP, EAP‑TLS) with credentials.

Reference:
Cisco ISE Administration Guide – "MAC Authentication Bypass (MAB) – Use Cases for Non‑Supplicant Devices"
Cisco SISE 300-715 Official Cert Guide, Chapter: "MAB – When to Use MAB vs. 802.1X"

Explanation:
Cisco TrustSec inline tagging inserts a Cisco Metadata (CMD) field between the Layer 2 header (Ethernet/802.1Q) and the Layer 3 header (IP). This metadata field carries the Security Group Tag (SGT). To verify SGT transmission between two devices, you examine this field in the Layer 2 frame.

Correct Option (per your key):

A. CMD field
The CMD (Cisco Metadata) field is a special header inserted by TrustSec-capable switches. It includes the SGT (source tag) and other metadata. When verifying SGT propagation, packet captures or switch debugs show the CMD field and its SGT value. This field is external to the IP payload and is not part of standard 802.1Q or 802.1AE.

Why other options are incorrect:

B. 802.1Q field –
The 802.1Q field carries VLAN IDs, not SGTs. TrustSec uses the CMD field independent of VLAN tags.

C. Payload –
The payload (IP packet data) does not contain the SGT. Inline tagging places metadata before the IP header.

D. 802.1AE header –
802.1AE (MACsec) encrypts the frame for security but does not carry the TrustSec SGT. SGT can be inside a MACsec encrypted frame but is not part of the MACsec header.

Reference:
Cisco TrustSec Configuration Guide – "Inline Tagging – Cisco Metadata (CMD) Field"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Cisco TrustSec – SGT Propagation with CMD Field"

Explanation:
For posture checks with a remote access VPN (e.g., ASA or FTD), the endpoint first authenticates and receives an initial authorization result (e.g., restricted access). After completing a compliance scan, ISE sends a Change of Authorization (CoA) to the VPN gateway to update the session's authorization (e.g., full access). This requires dynamic authorization to be enabled on the AAA server group.

Correct Option:

D. Enable dynamic authorization within the AAA server group
On the VPN gateway (ASA/FTD), the AAA server group for ISE must have dynamic authorization enabled. This allows the gateway to accept CoA packets from ISE. After posture compliance is determined, ISE sends a CoA to the VPN gateway with updated authorization attributes (e.g., ACL, group policy). Without this enabled, the gateway ignores CoA requests and the endpoint remains with the initial restricted access.

Incorrect Options:

A. Configure the posture authorization so it defaults to unknown status –
Posture status "unknown" is the default for endpoints that have not yet run a posture scan. This is not a configuration action for AAA; it is a policy setting. The requirement is to allow compliant access, which requires CoA, not defaulting to unknown.

B. Fix the CoA port number –
The CoA port number (default 3799 or 1700) may need verification, but the question does not indicate a port mismatch. The missing element is enabling dynamic authorization itself on the AAA server group.

C. Ensure that authorization only mode is not enabled –
Authorization only mode (e.g., aaa authorization ...) relates to policy lookup, not CoA capability. Disabling this does not enable CoA. This option is irrelevant to posture-triggered authorization changes.

Reference:
Cisco ASA/FTD Configuration Guide – "Dynamic Authorization for Posture with ISE"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Posture – VPN CoA and Dynamic Authorization"

Explanation:
Cisco ISE ships with a default guest type named "Guest" (or sometimes displayed as "Default" depending on version). This guest type defines account parameters such as maximum devices, validity periods, and portal access settings for basic guest users. Other guest types (e.g., Contractor, Daily Guest) are typically created manually or via templates.

Correct Option:

C. guest
When Cisco ISE is first installed, the default Guest Type is simply named "Guest" (or "Default Guest" in some versions). This provides a baseline for guest account creation (e.g., sponsor‑created accounts, self‑registered accounts). The administrator can customize or create additional guest types as needed.

Incorrect Options:

A. visitors –
"Visitors" is not a default guest type in Cisco ISE. It may be created by an administrator but is not included out‑of‑box.

B. sponsor –
"Sponsor" is a user group or role for portal administrators, not a guest type. Sponsor groups determine who can create guest accounts.

D. contractor –
"Contractor" is a commonly created guest type for long‑term external workers, but it is not included by default. It must be configured manually.

Reference:
Cisco ISE Guest Access Guide – "Guest Types – Default Guest Type"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Guest Services – Guest Types and Account Creation"

Explanation:
Cisco ISE supports multiple external identity stores for authentication. For password-based authentication, the two most common are LDAP (e.g., Microsoft Active Directory, OpenLDAP) and RADIUS Token Servers (e.g., RSA SecurID, Duo). LDAP stores user passwords (hashed or plain via bind), and RADIUS token servers handle one-time password (OTP) authentication.

Correct Options:

A. LDAP
LDAP (Lightweight Directory Access Protocol) identity stores are supported by ISE for password-based authentication. When a user presents a password, ISE performs an LDAP bind operation against the directory (e.g., Active Directory, OpenLDAP). LDAP is commonly used for corporate user authentication.

C. RADIUS Token Server
Cisco ISE can integrate with RADIUS token servers (e.g., RSA SecurID) to authenticate users with one-time passwords (OTP) or token-based credentials. In this case, ISE forwards the RADIUS Access-Request to the token server, which validates the password/token.

Incorrect Options:

B. OBDC –
This appears to be a typo. There is no "OBDC" identity store in Cisco ISE. The correct term is ODBC (Open Database Connectivity), which ISE does not support as an external identity store for password authentication.

D. TACACS+ Token Server –
TACACS+ is used for device administration (network device AAA), not as an external identity store for user authentication in ISE. TACACS+ token servers are not a supported external identity store type for password authentication.

E. SOL –
Not a valid identity store type. SQL databases require ODBC, which is not supported for direct password authentication in ISE.

Reference:
Cisco ISE Administrator Guide – "External Identity Sources – Supported Types (LDAP, RADIUS Token)"
Cisco SISE 300-715 Official Cert Guide, Chapter: "External Identity Sources – LDAP and RADIUS Token Integration"

Explanation:
For TACACS+ authentication with a non-Cisco network device, standard Cisco AV pairs may not be recognized. The device may require vendor-specific attributes (VSAs) or custom attributes in the Access-Accept packet. In Cisco ISE, these are configured as custom attributes within a shell profile. The shell profile defines authorization parameters sent back to the device.

Correct Option:

C. shell profiles with custom attributes that define the various roles
A TACACS+ shell profile in ISE contains authorization attributes (e.g., privilege level, timeout, custom AV pairs). For non-Cisco devices, the administrator can add custom attributes (key-value pairs) to the shell profile. These attributes are included in the Access-Accept message. Based on these attributes, the non-Cisco device grants appropriate access (e.g., different privilege levels or role names). This is the correct method to send special attributes to a third-party TACACS+ client.

Incorrect Options:
A. dACLs to enforce the various access policies for the users – dACLs (downloadable ACLs) are used for RADIUS-based network access (e.g., 802.1X), not for TACACS+ device administration. TACACS+ does not use dACLs.

B. custom access conditions for defining the different roles –
Custom access conditions are part of authentication/authorization policies (rules). They are not sent to the network device; they exist only within ISE. This does not deliver attributes to the non-Cisco device.

D. TACACS+ command sets to provide appropriate access –
Command sets are used for command authorization on Cisco devices (specific CLI commands). For non-Cisco devices, command sets may not be supported or understood. Custom attributes in shell profiles are the generic solution.

Reference:
Cisco ISE Device Administration Guide – "TACACS+ Shell Profiles – Custom Attributes for Non-Cisco Devices"
Cisco SISE 300-715 Official Cert Guide, Chapter: "TACACS+ – Shell Profiles and Vendor-Specific Attributes"

Explanation:
When 802.1X authentication fails, the default switch behavior is to block the port (unauthorized state), which disrupts user connectivity. To log failures to ISE while minimizing user impact, the engineer can configure monitor mode (also known as "authentication open" or "monitor session" mode). This allows traffic to pass even on authentication failure while logging the failure to ISE.

Correct Option:

D. monitor-mode enabled
The authentication open (or monitor mode) command configures the port to remain in an authorized state even if authentication fails. The switch still attempts authentication and logs the failure to ISE (via RADIUS accounting or live logs), but the user retains network access. This minimizes user impact while providing visibility into failed authentication attempts. The exact Cisco IOS command syntax is authentication open (sometimes referred to as "monitor mode").

Incorrect Options:

A. authentication open –
This is actually the correct command to enable open (monitor) mode. The question's answer key lists D as "monitor-mode enabled," which is a conceptual description of the same feature. In some exam versions, authentication open is the correct answer, but the key here is D.

B. pae dot1x enabled –
This enables 802.1X Port Access Entity (PAE) on the switch globally, not per-interface. It does not provide monitor mode or minimize user impact on failure.

C. authentication host-mode multi-auth –
This allows multiple hosts on the same port but does not affect failure behavior. Each host still must authenticate, and failure blocks that host's traffic.

Reference:
Cisco Catalyst Switch Configuration Guide – "Authentication Open Mode (Monitor Mode)"
Cisco SISE 300-715 Official Cert Guide, Chapter: "802.1X – Monitor Mode for Logging Without Disruption"

Explanation:
When MAB endpoints are not hitting the correct authorization policies, the issue is often that ISE has not correctly identified (profiled) the device type. Without proper profiling, the endpoint remains in an unknown or generic identity group. Creating custom profiles for non‑802.1X device types allows ISE to classify them correctly, enabling the right AuthZ policies to apply.

Correct Option:

D. Identify the non‑802.1X supported device types and create custom profiles for them to profile into.
For MAB‑only devices (e.g., printers, IP cameras, badge readers), ISE uses profiling to determine the device type. Default profiles may not match specific models. By creating custom profiling policies (with conditions like OUI, DHCP options, or SNMP sysDescr), the engineer ensures endpoints are placed into correct endpoint identity groups (e.g., "Printer", "IPCamera"). AuthZ policies can then use those groups for access rules.

Incorrect Options:

A. Manually add the MAC addresses of the devices to endpoint ID groups –
This is possible but not scalable for many devices. It requires continuous manual effort and is not the recommended solution. Profiling automates this.

B. Create an AuthZ policy to identify Unknown devices and provide partial network access prior to profiling –
This is a workaround (e.g., quarantine VLAN while profiling completes), but it does not solve the root cause of not hitting the correct policies. It defers the issue rather than fixing profiling.

C. Add an identity policy to dynamically add the IP address of the devices to their endpoint identity groups –
IP addresses change (DHCP leaks) and are not reliable identifiers for MAB. MAC address is used for MAB, not IP. Identity policies do not dynamically add IPs to groups.

Reference:
Cisco ISE Profiling Guide – "Creating Custom Profiles for Non‑802.1X Devices"
Cisco SISE 300-715 Official Cert Guide, Chapter: "MAB and Profiling – Policy Assignment"

Explanation:
When Cisco ISE is first installed, it creates several default endpoint identity groups to help organize and manage endpoints. The three default groups are Unknown (endpoints not yet identified), Blacklist (endpoints explicitly blocked), and Profiled (endpoints that have been successfully profiled). Additional groups like "RegisteredDevices" are created later via portal flows.

Correct Options:

A. Unknown
The Unknown endpoint identity group is a default group containing endpoints that have not been matched by any profiling policy or manually assigned. New endpoints first appear here (e.g., during MAB authentication before profiling completes). This group is often used in authorization policies to restrict access until profiling occurs.

D. Profiled
The Profiled endpoint identity group is a default group that contains endpoints successfully identified (profiled) by Cisco ISE. When a profiling policy matches an endpoint (e.g., "Cisco-IP-Phone", "Apple-iPad"), ISE can automatically move the endpoint from Unknown to Profiled (or to a more specific custom group).

E. Blacklist
The Blacklist endpoint identity group is a default group used to block network access for specific endpoints. Endpoints added to this group (manually or via policy) are denied access, often by an authorization rule that checks EndpointsIdentityGroup EQUALS Blacklist and returns Access-Reject or a deny ACL.

Incorrect Options:

B. whitelist –
Cisco ISE does not create a default "whitelist" endpoint identity group. Whitelisting is typically achieved using the "RegisteredDevices" group or similar, but "whitelist" is not a default group.

C. end point –
There is no default group named "end point". The default groups are "Unknown", "Blacklist", and "Profiled" (plus "RegisteredDevices" after BYOD flows).

Reference:
Cisco ISE Administration Guide – "Default Endpoint Identity Groups"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Endpoint Management – Identity Groups"

Explanation:
TACACS+ (Terminal Access Controller Access Control System Plus) is a Cisco-developed protocol used for device administration AAA. Two key characteristics are that it uses TCP port 49 (not UDP) and it separates authentication, authorization, and accounting into distinct functions, unlike RADIUS which combines authentication and authorization.

Correct Options:

A. It uses TCP port 49.
TACACS+ uses TCP port 49 as its transport protocol. TCP provides reliable, connection-oriented communication, which is important for carrying detailed authorization and accounting data. This contrasts with RADIUS, which uses UDP.

C. It separates authorization and authentication functions.
TACACS+ completely separates the three A's: authentication (who you are), authorization (what you can do), and accounting (what you did). This allows, for example, authenticating a user via one service and authorizing commands via a different policy. RADIUS combines authentication and authorization in the same Access-Request/Access-Accept exchange.

Incorrect Options:

B. It combines authorization and authentication functions. –
This describes RADIUS, not TACACS+. TACACS+ separates them.

D. It encrypts the password only. –
This describes RADIUS (which encrypts only the password field). TACACS+ encrypts the entire body of the packet (including username, password, and authorization attributes), leaving only the standard TACACS+ header unencrypted.

E. It uses UDP port 49. –
TACACS+ uses TCP, not UDP. UDP port 49 is not standard for TACACS+.

Reference:
Cisco TACACS+ Documentation – "TACACS+ vs RADIUS – Port, Transport, and AAA Separation"
Cisco SISE 300-715 Official Cert Guide, Chapter: "Device Administration – TACACS+ Characteristics"