Cisco 300-715: Implementing and Configuring Cisco Identity Services Engine (SISE)

Incorrect. TCP/8080 is not a universal requirement for Cisco ISE Feed Service. Feed retrieval is typically performed over HTTPS (TCP/443) to the feed provider’s endpoints, and the exact destinations/ports depend on the provider and ISE version. A fixed requirement to open 8080 between ISE and a feed server is not a standard prerequisite and is a common distractor.

Incorrect. Having access to an internal server to download feed updates can be an enterprise design choice (for example, if an organization mirrors or stages updates internally), but it is not a requirement for Feed Service to work. The fundamental requirement is that ISE can reach the actual feed source—commonly on the Internet—either directly or through a proxy/controlled egress.

Incorrect. A “base license” is not the defining prerequisite for Feed Service operation. While certain ISE capabilities are license-gated (for example, advanced security features, posture, etc.), the question asks for a requirement for Feed Service to work. The primary dependency is network connectivity to retrieve updates, not simply possessing a base license.

Incorrect. The request is not “redirected” to the internal store; it is already being processed against the internal store because the engineer selected Internal Users as the identity source in the policy. There is no additional redirection behavior here—ISE simply attempts authentication against the chosen store and returns success or failure.

Incorrect. Authentication is not granted unless the user exists in the selected identity store and the credentials validate successfully. If the user is only in an external store (e.g., AD) and the policy uses Internal Users, ISE cannot validate the credentials and will not grant access.

Incorrect. ISE does not automatically redirect authentication to an external identity source when the policy specifies Internal Users. External-store authentication occurs only if the Authentication Policy selects that external store (or selects an Identity Source Sequence that includes it). Without that configuration, ISE will not try the external store.

Known is not a sponsor-portal bulk creation method in Cisco ISE. While “known” can describe a guest whose identity attributes are provided (for example, name/email) versus anonymous credentials, ISE does not label bulk creation workflows as “Known.” Bulk creation is implemented through importing a list or generating random accounts.

Monthly is not a bulk guest account creation method in the sponsor portal. It may sound like a scheduling or recurrence option, but Cisco ISE sponsor workflows focus on how accounts are generated (imported list vs random generation), not on monthly batch creation as a defined method.

Daily is not a recognized bulk account creation method in the Cisco ISE sponsor portal. Similar to “Monthly,” it can be mistaken for a scheduling frequency, but ISE bulk guest creation is based on importing user data or generating random credentials, not daily generation modes.

Incorrect. MS-CHAPv2 machine authentication uses a challenge-response mechanism based on the machine account secret, but that is not what Cisco ISE refers to as the Active Directory binary comparison function in this context. AD validates the response cryptographically rather than comparing certificate-related binary values. Because the question is about binary comparison tied to AD-based authentication, this option points to the wrong authentication mechanism.

Incorrect. A user does not present a password hash directly to ISE for comparison with a stored AD hash in normal MS-CHAPv2 authentication. Instead, the protocol exchanges challenge-response values derived from the password, and AD validates them internally. That process is not the binary comparison function being referenced here, so this option is technically misleading.

Endpoint profiling in ISE helps classify devices (e.g., printers, phones, IoT) and can drive policy decisions, but it is not required to configure wireless guest access. Guest endpoints are frequently unprofiled or unknown at first association. Guest access relies more on web redirection and a guest identity store/portal workflow than on profiling services.

Captive Portal Bypass (CPB) is used when you want certain endpoints to avoid the portal (for example, devices that cannot handle web auth) and be granted access based on MAB/cert/other conditions. Turning CPB on is not required to provide guest access; in many guest designs you explicitly want the portal to appear, so CPB would be counterproductive.

A valid Active Directory user account is not required for guest access. ISE Guest Services typically uses the internal guest user database with sponsor-created accounts, self-registration, or SMS/email-based credentials. AD can be integrated for employee/contractor access or sponsor authentication, but guest users themselves do not need AD accounts.

Incorrect. Cisco ISE can query its internal identity store only if the authentication policy is configured to use Internal Users. The question asks which two actions occur in the login flow, and the universally applicable action is that the device queries ISE, not that ISE always queries its internal store. Since ISE uses either an internal or an external identity source depending on policy, A is not a required action in the general case. Selecting A together with E incorrectly implies both identity stores are queried as part of the same login process.

Incorrect. The network device does not query an external identity store such as Active Directory or LDAP directly when Cisco ISE Device Administration is deployed. The device communicates with Cisco ISE as its TACACS+ server, and ISE performs any necessary identity lookup. This separation is a core design principle of centralized AAA with ISE. Therefore B describes the wrong component performing the lookup.

Incorrect. The device does not query an internal identity store as part of Cisco ISE-based device administration. If local usernames exist on the device, that would be a separate local authentication method or fallback, not the normal ISE TACACS+ flow described here. In the ISE workflow, the device sends the request to ISE and waits for ISE to authenticate and authorize the user. Therefore D does not match the centralized device administration process.

Redirect ACL is used on the switch/WLC to permit DNS/DHCP and redirect HTTP/HTTPS traffic to the ISE BYOD portal (typically via CWA). It is an enforcement component in the authorization policy and NAD configuration, not a required field when creating a Native Supplicant Profile. It commonly appears in BYOD designs, which makes it tempting, but it is not part of the profile definition.

Windows Settings are not universally required components; they are conditional configuration options that appear only after selecting Windows as the Operating System. If you choose a different OS, Windows Settings are irrelevant. The question asks for required components to create the profile in general, so the correct requirement is the OS selection itself, not a specific OS settings subsection.

iOS Settings, like Windows Settings, are conditional and only apply when the selected Operating System is iOS. They are not required for creating a Native Supplicant Profile overall; they are optional/available fields within the profile once the OS is chosen. The required top-level component is Operating System, which then exposes iOS-specific settings if applicable.

TCP 8909 is not the standard port associated with Cisco ISE native supplicant provisioning for Windows in the BYOD workflow. It may look plausible because it resembles other “special” ISE onboarding ports, but it is not the one tested for Windows native supplicant provisioning. On the exam, Windows native supplicant provisioning maps to TCP 8905.

TCP 443 is used for HTTPS access to ISE portals (Guest, BYOD/MyDevices, Sponsor, Admin GUI, etc.). While 443 is required for users to reach the onboarding portal and download components, it is not the dedicated port specifically used for Windows native supplicant provisioning. The question asks for the native supplicant provisioning port, which is TCP 8905.

UDP 1812 is the RADIUS authentication port used between the network access device (switch/WLC/VPN) and Cisco ISE. It is not used for endpoint provisioning. BYOD/native supplicant provisioning is endpoint-to-ISE application traffic, not NAD-to-ISE RADIUS. This option is a common trap when candidates conflate authentication transport with onboarding/provisioning services.

QoS is a traffic prioritization mechanism (marking/queuing) and is not a TrustSec classification method. While TrustSec and QoS can coexist on the same network devices, QoS does not assign Security Group Tags (SGTs) to users or endpoints, nor does it define group membership for segmentation. Selecting QoS is a common distractor when candidates confuse “policy” in general with TrustSec identity segmentation.

SGACL (Security Group Access Control List) is used for enforcement, not classification. After an endpoint is classified into an SGT, SGACLs define what that SGT can access (often in matrix form: source SGT to destination SGT). SGACLs are downloaded from ISE to enforcement points or configured locally, but they do not determine which SGT a user/endpoint belongs to.

SXP (Security Group Tag Exchange Protocol) is used to propagate IP-to-SGT bindings between devices (for example, from an access switch to a firewall) when inline tagging is not available end-to-end. SXP helps other devices learn the SGT associated with an IP address, but it does not perform the original classification of the user/endpoint; it only distributes the resulting bindings.

PEAP also creates a TLS tunnel and protects inner credentials, so it is a secure method in practice. However, if the exam expects exactly two answers from this list, the more directly correct TLS-based methods are EAP-TLS and EAP-TTLS. PEAP is often discussed alongside them, but selecting it instead of EAP-TTLS would omit another valid tunneled protocol specifically designed to protect credentials. This makes PEAP a distractor in a question constrained to two choices.

EAP-MD5 does not provide a TLS tunnel or any equivalent encryption to protect credentials during the authentication exchange. It uses a challenge-response mechanism that is vulnerable to capture and offline dictionary attacks, and it does not support mutual authentication. Because it lacks credential confidentiality and stronger modern protections, it is not appropriate when the goal is to ensure credentials are not exposed. It is generally considered unsuitable for secure 802.1X deployments.

LEAP is a legacy Cisco EAP method that relies on password-based challenge-response authentication. It is well known to be vulnerable to offline dictionary attacks, meaning captured exchanges can be used to recover user passwords. LEAP does not provide the robust TLS-based protection expected in modern secure 802.1X environments. For that reason, it is deprecated and should not be chosen when credential exposure must be prevented.

Application Visibility and Control (AVC) is a Cisco feature (commonly on WLC/routers/firewalls) used to identify and classify applications using NBAR2 and enforce QoS or security policies. It is unrelated to BYOD onboarding or certificate issuance. AVC does not provision supplicants, does not interact with ISE to enroll certificates, and is not part of the ISE BYOD certificate workflow.

My Devices Portal is an end-user portal in Cisco ISE used to view and manage registered devices (for example, list devices, rename, revoke/forget devices, and sometimes initiate onboarding). While it is part of the BYOD user experience, it is not the mechanism that actually provisions the supplicant and installs the certificate. The certificate enrollment action is performed by the onboarding/SPW process.

Network Access Control (NAC) describes the overall security approach of controlling who/what can access the network and under what conditions. Cisco ISE is a NAC platform, but “Network Access Control” is not a specific feature that allows an endpoint to obtain a certificate during BYOD. The certificate provisioning step is handled by the BYOD onboarding process, specifically the Supplicant Provisioning Wizard.

Incorrect. The primary node (Primary PAN) remains the deployment anchor and does not need to restart when a secondary node is deregistered. Deregistration is a membership change affecting the removed node; the primary continues running and simply updates its deployment inventory to reflect that the secondary node is no longer registered.

Incorrect. Both nodes do not restart. Only the deregistered node needs to restart to complete the transition out of the deployment. The primary node continues operating normally; forcing both nodes to restart would be unnecessary and would introduce avoidable downtime for administration and any personas still running on the primary.

Incorrect. The primary node does not “become standalone” as a special state due to deregistration; it already functions independently as the Primary PAN. After removal of the secondary, the deployment simply becomes a single-node deployment from an operational perspective, but the primary does not require a role/state change event like deregistration.

“aaa accounting resource default start-stop group radius” is not the correct accounting method for 802.1X/MAB sessions. Resource accounting is used for tracking system/resource usage and is platform/feature dependent, not for per-port network access session accounting. Even if configured, it would not cause the switch to emit RADIUS accounting start/stop records for endpoint authentication sessions toward ISE.

“radius-server vsa send accounting” controls whether the switch includes Vendor-Specific Attributes (VSAs) in RADIUS accounting packets. It does not enable accounting by itself. If accounting is not configured (for example, missing “aaa accounting network …”), there will be no accounting packets to decorate with VSAs, so ISE would still see nothing.

“aaa accounting exec default start-stop group radius” enables accounting for EXEC sessions (administrative logins to the switch via console/VTY/SSH). This is useful for TACACS+/RADIUS device administration auditing, but it does not apply to endpoint network access sessions on switchports. Therefore it would not make 802.1X/MAB RADIUS accounting packets appear on ISE.

Keeping track of guest user activities is primarily a monitoring/reporting function (Live Logs, Reports, Context Visibility) and is typically restricted to ISE admins or users with reporting permissions. A basic sponsor/receptionist role is designed for operational guest account handling, not security analytics or auditing of guest network activity. Sponsors may see limited account status, but not comprehensive activity tracking.

Authorization settings (VLAN/ACL/SGT assignment, dACLs, authorization profiles, and policy rules) are configured in the ISE Admin UI under Policy Sets and related policy components. These are administrative tasks requiring elevated privileges. Sponsor group membership does not grant the ability to modify network authorization behavior; it only governs guest account workflows and sponsor portal actions.

Guest authentication is performed by Cisco ISE during network access (for example, Central Web Auth redirect, 802.1X, or MAB) based on the configured policy and identity stores. A sponsor does not “authenticate” users; they only create credentials or approve access. The actual authentication exchange occurs between the endpoint, NAD, and ISE, not via sponsor portal actions.

Incorrect. “show authentication registrations” is not the standard command used to display 802.1X/MAB session troubleshooting output like Authz status, VLAN policy, and method state. It may be confused with registration or tracking-related outputs on some platforms, but it does not match the exhibit’s per-session authentication details format.

Incorrect. The issue is the command syntax, not the fact that it uses an interface. On Cisco IOS/IOS-XE, the valid troubleshooting command is typically `show authentication sessions interface gigabitethernet2/0/36 details`, which can display the same detailed fields shown in the exhibit, including status, domain, host mode, authorization source, VLAN policy, and method state. Because this option omits the required `sessions` keyword and `details`, it does not match the command needed to reproduce the displayed output.

Incorrect. “show authentication sessions method” is not the right command to reproduce the specific per-endpoint detailed output in the exhibit. Method-based views (where supported) are generally summary/grouping outputs and won’t present the same single-session fields (Authorized By, VLAN Policy, handle, runnable methods list) tied to one MAC.