Cisco
149+ 무료 연습 문제 (AI 검증 답안 포함)
모든 문제 &
정답 무료
상세
해설
실제 시험과
가장 유사AI 기반
모든 Cisco 300-715: Implementing and Configuring Cisco Identity Services Engine (SISE) 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
In a Cisco ISE split deployment model, which load is split between the nodes?
Log collection is primarily the responsibility of the Monitoring & Troubleshooting (MnT) persona. While you can deploy primary/secondary MnT for redundancy, ISE does not typically describe “split deployment” as splitting log collection load across nodes in the same way it splits runtime AAA across PSNs. Logs are generated by PSNs but centralized for reporting and troubleshooting on MnT.
“Device admission” is not a standard ISE persona load category. Admission decisions are made through policy evaluation during AAA (RADIUS) transactions on PSNs. Because the actual processing unit is AAA, “device admission” is an imprecise description and not the best answer for what is explicitly split between nodes in a split deployment model.
AAA is the runtime workload handled by Policy Service Nodes (PSNs). In a split deployment, multiple PSNs are deployed so that RADIUS/TACACS+ authentication, authorization, and accounting requests are distributed across nodes. This is the key load that is scaled horizontally and “split” to improve performance and provide high availability for network access services.
“Network admission” describes the overall NAC function (allow/deny/quarantine access), but in ISE this is implemented through AAA policy evaluation on PSNs. The exam typically expects the precise architectural term: the load being distributed is AAA processing (RADIUS/TACACS+). Therefore, while related, “network admission” is too broad compared to AAA.
Core Concept: A Cisco ISE “split deployment” refers to separating (splitting) the Policy Administration Node (PAN) and Monitoring & Troubleshooting (MnT) roles across different nodes, while distributing the runtime authentication/authorization workload across Policy Service Nodes (PSNs). The question asks which load is split between nodes—this points to the runtime AAA processing handled by PSNs. Why the Answer is Correct: AAA (Authentication, Authorization, and Accounting) is the primary runtime workload in ISE. In a split deployment, you scale and distribute AAA by deploying multiple PSNs and having network access devices (NADs) send RADIUS/TACACS+ requests to different PSNs (often via load balancing, DNS round-robin, or NAD server lists). This “splits” the AAA transaction load across nodes, improving performance and resiliency. Key Features / Best Practices: - Use multiple PSNs for scale and redundancy; NADs should be configured with at least two PSNs. - Keep PAN dedicated to administration/policy changes and MnT dedicated to logging/reporting to avoid resource contention. - Consider PSN “persona” placement close to NADs (latency-sensitive) and use node groups for policy/service selection. - Accounting records are part of AAA; they are processed by PSNs and forwarded to MnT for reporting. Common Misconceptions: - “Log collection” sounds like something you might split, but in ISE architecture log collection/reporting is centralized on MnT (with primary/secondary MnT for redundancy), not typically described as the split load in a “split deployment model.” - “Network admission” and “device admission” are broad terms that describe the overall function (NAC), but the specific load that is distributed across nodes is the AAA request processing. Exam Tips: - Remember the personas: PAN = configuration/policy admin, PSN = runtime AAA, MnT = logs/reporting. - When you see “load split” or “scale out,” think PSNs and AAA (RADIUS/TACACS+ transactions). Redundancy for PAN/MnT is important, but the classic scaling/load distribution is PSN AAA processing.
Which two features are available when the primary admin node is down and the secondary admin node has not been promoted? (Choose two.)
New AD user 802.1X authentication is a runtime authentication service handled by PSNs. The PSN evaluates the authorization policy and can query Active Directory directly, provided the AD join and connectivity were already established before the PAN outage. The fact that the user is 'new' does not inherently require PAN availability, because PAN is not in the live authentication path. Therefore, 802.1X authentications for AD users can continue while the primary admin node is down.
Hotspot is a guest access portal feature and is not the best answer in this HA scenario because guest portal administration and related workflows are tied more closely to PAN-managed services and configuration state. While some already-deployed portal pages may still be reachable from PSNs, exam questions typically do not treat hotspot as a guaranteed available feature when PAN is down and the secondary has not been promoted. The safer interpretation is that guest portal operations are impacted until administrative services are restored. Therefore, hotspot is not one of the two expected answers.
Posture is also a runtime service delivered by PSNs using previously replicated posture policies and compliance rules. The PAN is used to configure posture conditions and policies, but once those settings are distributed, PSNs can continue posture assessment and enforcement. Existing posture workflows, redirection, and remediation decisions remain functional as long as the PSNs and related services are healthy. Thus posture remains available even when the primary PAN is down and the secondary has not been promoted.
Guest AUP is part of the guest portal experience rather than a core runtime authentication service like 802.1X or posture. Although PSNs can host portal pages, guest workflows are generally considered dependent on PAN-managed guest services and are not the canonical 'still available' features in this failure state. The question asks for the two features that remain available, and Cisco exam logic typically points to PSN runtime services instead of guest portal functions. For that reason, guest AUP is not the best choice.
BYOD onboarding depends on portal workflows, device registration, certificate provisioning, and onboarding state management. These processes are more sensitive to administrative-plane availability than standard RADIUS authentication or posture checks. Even if some components are PSN-hosted, BYOD is not generally considered fully available when the primary PAN is down and the secondary has not been promoted. Therefore, BYOD is not one of the correct answers in this scenario.
Core concept: This question tests Cisco ISE high availability behavior when the Primary Policy Administration Node (PAN) is down and the Secondary PAN has not yet been promoted. In that state, administrative access and configuration changes are unavailable, but distributed runtime services on Policy Service Nodes (PSNs) continue to operate using the last replicated configuration. Authentication, authorization, and posture processing are handled by PSNs, not by the PAN itself. Why correct: New AD user 802.1X authentication (A) and posture (C) remain available because they are runtime services processed by PSNs. As long as the PSNs already have the necessary configuration and maintain connectivity to external services such as Active Directory, they can continue to authenticate users and perform posture assessment even while the PAN is unavailable. Key features: - PAN is responsible for administration, configuration, and replication, not live RADIUS processing. - PSNs continue serving authentication and posture requests with existing replicated policy. - External identity source lookups such as AD can still be performed by PSNs if connectivity remains intact. - Lack of PAN promotion mainly affects management, configuration changes, and certain portal administration tasks. Common misconceptions: A common mistake is assuming that all user-facing services stop when the PAN fails. In reality, most live access services continue because PSNs are the runtime engines. Another misconception is over-associating guest portal pages with availability in this specific HA scenario; while some portal content may still be cached or served, exam questions typically distinguish core runtime policy services from administrative portal workflows. Exam tips: For ISE HA questions, separate admin-plane functions from data-plane/runtime functions. If PAN is down but PSNs are healthy, think of RADIUS authentication, authorization, and posture as still working. Be cautious with answers involving guest/BYOD portal workflows, because those often depend on administrative services or are treated as impacted in exam scenarios.
How is policy services node redundancy achieved in a deployment?
Creating a node group is the Cisco ISE method for achieving Policy Service Node redundancy in the deployment. Node groups allow PSNs to coordinate for session-related services and provide redundancy for features that depend on PSN state awareness. This is the platform-specific answer because the question asks how PSN redundancy is achieved in ISE, not how a NAD chooses alternate RADIUS servers.
Deploying both primary and secondary nodes refers to personas such as the Policy Administration Node, where a primary and secondary role exists. Policy Service Nodes do not operate in a primary/secondary relationship for redundancy. They are service nodes that are grouped for redundancy rather than assigned those administrative roles.
Enabling a VIP is not the native Cisco ISE mechanism for PSN redundancy. A virtual IP generally implies the use of an external load balancer, which may be part of some designs but is not the built-in deployment answer expected here. The exam objective for PSN redundancy points to node groups instead.
Using a RADIUS server list on the NAD provides failover from the network device perspective, allowing it to try another PSN if one is unreachable. However, that is not the ISE deployment mechanism that achieves PSN redundancy. The question asks specifically about redundancy in the deployment, which is implemented through node groups within Cisco ISE.
Core concept: In Cisco ISE, Policy Service Node (PSN) redundancy within a deployment is achieved by using a node group. A node group logically associates PSNs so they can provide redundancy for session-related services and maintain consistent behavior for features that require PSN coordination. This is an ISE-specific deployment construct, not merely a network device failover configuration. Why correct: A node group is the mechanism Cisco ISE uses to provide PSN redundancy for services that depend on state sharing or coordinated handling between PSNs. While NADs can be configured with multiple RADIUS servers for availability, that is device-side failover and not the deployment feature asked for here. The exam wording points to the ISE configuration method, which is the node group. Key features: - Node groups are used to pair or group PSNs for redundancy of session-aware services. - PSNs are otherwise active service nodes and do not use a primary/secondary model like PAN. - NAD RADIUS server lists improve reachability and failover, but they do not by themselves create ISE PSN redundancy semantics. - VIPs are not a native ISE redundancy mechanism for PSNs. Common misconceptions: Candidates often confuse NAD-side RADIUS failover with ISE-side PSN redundancy. They also mix up PAN primary/secondary behavior with PSN design. Another common mistake is assuming a VIP is a built-in ISE feature for PSN high availability. Exam tips: If the question asks how PSN redundancy is achieved in the deployment itself, think node group. If the question instead asks how a NAD fails over between PSNs, then a RADIUS server list on the NAD would be relevant. Watch for wording that distinguishes ISE architecture from network device configuration.
Which command displays all 802.1X/MAB sessions that are active on the switch ports of a Cisco Catalyst switch?
This is not the best answer because it targets a single interface (Gi1/0/x) rather than displaying all active sessions on the switch. Also, typical IOS syntax would be "show authentication sessions interface Gi1/0/x" optionally followed by "details"; the trailing word "output" is not a valid keyword. It’s useful for per-port troubleshooting, not for a switch-wide session list.
Correct. "show authentication sessions" displays authentication session information for all interfaces on the switch, including sessions established via 802.1X and MAB. It’s the standard global verification command to quickly see which endpoints are authenticated, on which ports, and by what method. From there, you can narrow down to an interface or request details if needed.
Incorrect because "show authentication sessions output" is not valid IOS CLI syntax; "output" is not a keyword for this command. The option is a distractor that confuses the idea of viewing the command output with an actual command modifier. The correct approach is to run "show authentication sessions" (and optionally add interface/details filters).
Incorrect for two reasons: it is interface-specific (so it does not show all sessions across the switch), and it lacks the typical optional "details" keyword that is often used for deeper inspection. While "show authentication sessions interface Gi1/0/x" can be valid on many platforms for per-port viewing, it does not meet the requirement to display all active sessions.
Core Concept: This question tests operational verification of access control on a Cisco Catalyst switch using IEEE 802.1X and MAB (MAC Authentication Bypass). In an ISE deployment, the switch (NAD) is the Policy Enforcement Point (PEP) and maintains per-port authentication sessions (dot1x, mab, webauth) that you must be able to display and troubleshoot. Why the Answer is Correct: The command that displays all active 802.1X/MAB sessions across the switch is "show authentication sessions". It provides a switch-wide view of authentication sessions, typically listing interface, MAC address, method (dot1x/mab), status (Auth/Unauth), domain, VLAN/SGT (platform-dependent), and session identifiers. This is the fastest way to confirm which endpoints are currently authenticated and by which method, without limiting output to a single interface. Key Features / Best Practices: - Use "show authentication sessions" for a global snapshot, then drill down with "show authentication sessions interface Gi1/0/x details" (or similar) when you need per-port deep troubleshooting. - Pair with "show access-session" on some platforms/IOS-XE releases where that command is preferred/available. - In ISE workflows, validate that the method matches design: 802.1X for supplicants, MAB for non-supplicants, and confirm reauth timers, critical VLAN behavior, and authorization results. Common Misconceptions: Many candidates assume you must specify an interface to see sessions, but the question asks for all sessions active on switch ports, which implies a global command. Also, options containing the word "output" are not valid IOS CLI syntax; they look like exam distractors that confuse “command output” with a command keyword. Exam Tips: - If the question says “all sessions,” choose the non-interface-specific command. - Remember the common troubleshooting flow: global sessions view (show authentication sessions) -> per-interface details -> RADIUS/ISE logs. - Watch for invalid syntax distractors (extra words like “output”).
What is the purpose of the ip http server command on a switch?
Incorrect. ip http server enables the switch’s HTTP service (TCP/80), not HTTPS. HTTPS on the switch is enabled with ip http secure-server. While WebAuth solutions often involve HTTPS portals on ISE, this specific command does not “enable the https server for users.” It enables HTTP functionality on the switch, which may be used for redirect handling or management depending on configuration.
Incorrect. 802.1X is enabled with commands such as dot1x system-auth-control globally and interface-level authentication configuration (e.g., authentication port-control auto). The ip http server command is unrelated to EAP/802.1X processing and does not activate dot1x authentication on switch ports.
Incorrect. MAB (MAC Authentication Bypass) is configured under the interface with mab and related authentication/AAA settings. It leverages RADIUS to ISE but does not require enabling the switch’s HTTP server. ip http server does not affect MAB behavior or MAC-based authentication flows.
Correct. ip http server enables the switch’s embedded HTTP server, which is commonly required for web authentication features where the switch intercepts an HTTP request from an unauthenticated endpoint and issues an HTTP redirect (302) to an ISE portal (CWA) or a local login page. This command supports the NAD-side redirection mechanism used in WebAuth deployments.
Core Concept: The question tests understanding of Cisco IOS “web authentication” (WebAuth) on a switch and what local services must be enabled on the NAD (Network Access Device) to support the redirection flow used with ISE Central WebAuth (CWA) or Local WebAuth. Why the Answer is Correct: The ip http server command enables the switch’s embedded HTTP server. In WebAuth/CWA designs, the switch must be able to accept an initial HTTP request from an unauthenticated client and then issue an HTTP 302 redirect to the configured redirect destination (often ISE’s guest portal). That redirect behavior relies on the switch running an HTTP service to intercept and respond to the client’s web request. Therefore, enabling ip http server is a prerequisite on many IOS/IOS-XE switches for web authentication redirection to function. Key Features / Configuration Notes: - ip http server enables HTTP (TCP/80) on the switch; ip http secure-server enables HTTPS (TCP/443). - In ISE CWA, the NAD typically redirects HTTP to ISE (or to an ISE portal FQDN) and may also use ACLs (e.g., redirect ACL) and URL-redirect attributes returned by ISE. - Best practice is to prefer HTTPS for device management (ip http secure-server) and restrict/disable plain HTTP management access when not required. However, WebAuth redirection may still require the HTTP server feature depending on platform and WebAuth mode. Common Misconceptions: Many candidates confuse “enabling the HTTP server” with “enabling HTTPS for users” or with “turning on 802.1X/MAB.” 802.1X and MAB are controlled by AAA and interface authentication commands (e.g., dot1x system-auth-control, mab, authentication port-control), not by ip http server. Also, ip http server does not automatically create a guest portal; it only enables the switch’s HTTP service used for functions like redirection and (optionally) device management. Exam Tips: - Remember: WebAuth/CWA redirection is a NAD function; the switch must be able to intercept HTTP and send redirects. - Distinguish ip http server (HTTP) vs ip http secure-server (HTTPS). - Don’t conflate WebAuth prerequisites with 802.1X/MAB enablement; those are separate features and commands.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
What is a requirement for Feed Service to work?
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.
Correct. Cisco ISE must have Internet access (directly or via an approved proxy/egress path) to download feed updates from external sources. Without outbound connectivity (and supporting services like DNS and required firewall rules), the Feed Service cannot retrieve updated feed content, causing updates to fail and the feed data to become outdated.
Core concept: Cisco ISE Feed Service is the mechanism ISE uses to retrieve external “feeds” (for example, security intelligence such as IP/domain reputation, threat indicators, or other update content depending on the ISE version and enabled features). The key dependency is reachability from ISE to the feed source so it can periodically download updates. Why the answer is correct: For Feed Service to function, Cisco ISE must be able to reach the feed update source. In the standard design, this means Cisco ISE needs Internet access (directly or via a proxy, depending on your deployment) to download feed updates from Cisco or other external providers. Without outbound connectivity to the feed source, the service cannot retrieve updates, and the feed content becomes stale. Key features/configuration/best practices: - Ensure outbound connectivity (typically HTTPS) from the ISE node(s) that perform feed updates (commonly the PAN, depending on the feed type and version). - If your environment restricts direct Internet access, use an approved proxy or a controlled egress path; validate DNS resolution, certificate trust, and firewall rules for the required destinations. - Monitor feed update status and timestamps in ISE operational views/logs to confirm successful synchronization. Common misconceptions: - It’s easy to assume a specific port like TCP/8080 is required; however, feed downloads are generally over HTTPS (TCP/443) and depend on the provider, not a fixed 8080 requirement. - Another trap is thinking an “internal server” is required. While some organizations mirror content internally, that is an optional architecture choice, not a baseline requirement. - Licensing (for example, “base license”) is not the core prerequisite for the Feed Service mechanism itself; connectivity to the feed source is. Exam tips: When you see “Feed Service” requirements, focus first on reachability and update retrieval path (Internet/proxy/DNS/firewall). If an option states a very specific nonstandard port without context, be skeptical. Also distinguish between “required for the service to work” versus “possible enterprise design alternatives” (like staging feeds internally).
What happens when an internal user is configured with an external identity store for authentication, but an engineer uses the Cisco ISE admin portal to select an internal identity store as the identity source?
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.
Correct. ISE will attempt to authenticate the user against the internal identity store selected in the Authentication Policy. Because the user is not found (or credentials cannot be validated) in Internal Users, the authentication transaction fails. Only an Identity Source Sequence with multiple stores could provide a fallback path.
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.
Core Concept: This question tests Cisco ISE authentication policy behavior when the selected Identity Source (identity store) does not contain the user account. In ISE, the identity store used for authentication is determined by the Authentication Policy (or by an Identity Source Sequence). ISE does not “follow” a user’s profile to another store during authentication; it strictly uses the store chosen by policy. Why the Answer is Correct: If a user actually exists in an external identity store (for example, Active Directory, LDAP, or an external database) but the engineer configures the policy/identity source for that authentication attempt to use the Internal Users database, ISE will attempt to validate the credentials against Internal Users only. Because the user is not present there (or the password does not match an internal record), the identity lookup fails and authentication fails. ISE does not automatically redirect the request to the external store unless an Identity Source Sequence is configured that tries multiple stores in order. Key Features / Best Practices: - Use an Identity Source Sequence when you need fallback behavior (e.g., try AD first, then Internal Users for break-glass/admin accounts). - Ensure Authentication Policy rules match the intended use case (802.1X vs MAB vs TACACS+ device admin) and select the correct identity source per rule. - For admin access (TACACS+), it’s common to use AD/LDAP for day-to-day and keep a local internal admin as emergency access, but that requires explicit policy design. Common Misconceptions: Many assume ISE “knows” a user is external and will redirect automatically. ISE does not do dynamic redirection based on a user’s intended store; it only evaluates the configured identity source(s). “Redirection” is more associated with web authentication flows (e.g., redirecting to a portal), not identity store selection. Exam Tips: When you see “configured to use store X but policy selects store Y,” default outcome is failure unless an Identity Source Sequence includes both and is selected by policy. Always map: Request type → Authentication Policy rule → Identity Source (or Sequence) → Result.
Which two methods should a sponsor select to create bulk guest accounts from the sponsor portal? (Choose two.)
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.
Imported is a correct bulk creation method. Sponsors can upload a CSV (or similar) file containing multiple guest entries, allowing ISE to create many guest accounts in one operation. This is commonly used for planned events where attendee information is available in advance and you want accounts tied to specific identities.
Random is a correct bulk creation method. ISE can generate a batch of guest accounts with randomly created usernames/passwords, typically used for printing guest credentials or handing out temporary access codes at events. The guest type settings still govern validity, expiration, and any device/account limits.
Core Concept: This question tests Cisco ISE Guest Services (Sponsor Portal) capabilities for creating guest accounts in bulk. In ISE, sponsors can create multiple guest users at once using “bulk” creation workflows, which are designed for events, training sessions, conferences, or any scenario where many temporary credentials are needed quickly. Why the Answer is Correct: The two sponsor-portal methods that support bulk guest account creation are Imported and Random. - Imported: The sponsor uploads a file (typically CSV) containing guest user details (for example, name, email, phone, validity dates, and sometimes username). ISE then creates many accounts in one operation. This is the classic “bulk import” approach. - Random: ISE generates a batch of accounts with system-generated random usernames and/or passwords. This is commonly used when you want printable credentials (guest slips) without needing to pre-collect user identity details. Key Features / Best Practices: - Imported bulk creation is best when you have attendee lists ahead of time and want traceability (known identity attributes) and possibly email/SMS notifications. - Random bulk creation is best for walk-up events where you just need a stack of time-limited credentials. Ensure the guest type and sponsor group enforce appropriate expiration, max devices, and acceptable use policy. - In both cases, the guest type configuration (validity period, account expiration, login options, and notification settings) controls lifecycle and security. Common Misconceptions: Options like Daily and Monthly sound like “bulk scheduling,” but they are not bulk creation methods in the sponsor portal; they relate more to reporting/recurrence concepts, not account generation. Known can be confused with “known guests,” but that describes identity data quality, not a bulk creation mechanism. Exam Tips: For ISE Guest Services, remember the sponsor portal supports creating accounts individually or in bulk. Bulk is typically either (1) upload/import from a file or (2) generate a batch of random credentials for printing/distribution. If the option set includes “Imported” and “Random,” those are the two to select.
Which two values are compared by the binary comparison function in authentication that is based on Active Directory?
Correct. One use of the Active Directory binary comparison function is to compare the certificate presented by the endpoint with the certificate associated with the corresponding account in Active Directory. This is relevant in certificate-based authentication workflows where ISE must determine whether the certificate belongs to the AD user or machine. The comparison is certificate-oriented rather than password-oriented, which is why this option fits the question precisely.
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.
Correct. Certificate identity matching commonly involves fields such as the Subject Alternative Name and the Common Name when correlating a presented certificate to an AD identity. These values are used during certificate-based authentication logic to help establish whether the certificate maps to the expected directory object. In the context of the binary comparison function described in Cisco ISE exam material, these certificate identity values are part of the comparison process.
Core concept: In Cisco ISE, the Active Directory binary comparison function is associated with certificate-based authentication against AD, where ISE can compare certificate-related identity values to determine whether the presented certificate belongs to the AD user or machine account. This is distinct from password-based MS-CHAPv2 processing, which uses challenge-response validation rather than a certificate binary comparison function. Why the answers are correct: The binary comparison function can compare the user-presented certificate against a certificate stored in Active Directory, which directly matches option A. It also evaluates certificate identity fields such as Subject Alternative Name and Common Name for matching and identity correlation, which aligns with option D. Key features: - Used in AD-based certificate authentication scenarios, especially EAP-TLS. - Helps bind a presented certificate to an AD account. - Works with certificate attributes and AD-published certificate data rather than password challenge-response exchanges. Common misconceptions: - A frequent mistake is assuming any AD authentication question refers to MS-CHAPv2. Here, the phrase binary comparison function points to certificate comparison behavior, not password verification. - Another trap is thinking password hashes are directly compared by ISE. In MS-CHAPv2, AD validates challenge-response values, which is a different mechanism. Exam tips: If the question mentions Active Directory and binary comparison function, think of certificate-to-AD matching in EAP-TLS contexts. Eliminate options that describe MS-CHAPv2 password or machine credential exchanges unless the question explicitly mentions PEAP or MS-CHAPv2.
What is needed to configure wireless guest access on the network?
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.
A WEBAUTH (redirection) ACL is a core requirement for wireless guest access using captive portal/CWA. It enforces pre-auth restrictions while allowing DHCP/DNS and access to the ISE guest portal, and it enables the NAD (such as a Cisco WLC) to redirect HTTP/HTTPS traffic to ISE. Without it, redirection and controlled pre-auth access will fail.
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.
Core Concept: Wireless guest access with ISE typically uses Central Web Authentication (CWA) / guest portal flows. The wireless LAN controller (or other NAD) must be able to redirect unauthenticated HTTP/HTTPS traffic to the ISE Guest portal while still permitting essential network services (DHCP, DNS, and access to ISE portal IP/FQDN). This is accomplished with a redirection ACL (often called a WEBAUTH ACL on WLC). Why the Answer is Correct: A WEBAUTH (redirect) ACL is required so the NAD can enforce “walled garden” access: allow DHCP/DNS and allow traffic to ISE (and sometimes CRL/OCSP) while denying or redirecting all other web traffic to the captive portal. Without this ACL, clients either get full access without seeing the portal (no enforcement) or get blocked entirely and cannot reach the portal to authenticate/register. In Cisco WLC designs, the ACL is explicitly referenced by the authorization result (Airespace ACL name) along with the URL-redirect attribute pointing to ISE. Key Features / Configuration Points: - On WLC: create a pre-auth redirect ACL (WEBAUTH ACL) permitting DHCP (67/68), DNS (53), and ISE portal IP(s)/FQDN resolution, then apply it via ISE authorization profile. - In ISE: configure Guest portal, Guest access policy set, and an Authorization Profile that returns URL Redirect (CWA) plus the ACL name. - Best practice: ensure certificate trust for HTTPS portal, and include any required external services (DNS, NTP, OCSP/CRL) in the walled garden as needed. Common Misconceptions: Profiling (option A) is not a prerequisite for guest access; guests are often unknown endpoints. Captive Portal Bypass (option C) is used to skip portal for specific devices/conditions, not to enable guest access. Active Directory accounts (option D) are not required for guest access because ISE can use its internal Guest user store and sponsor portal workflows. Exam Tips: For guest/CWA questions, look for “redirect ACL / pre-auth ACL / walled garden” as a must-have on the NAD. Also remember: Guest users commonly authenticate against ISE Guest (internal) rather than AD, and profiling is optional/auxiliary, not foundational.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Which two actions occur when a Cisco ISE server device administrator logs in to a device? (Choose two.)
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.
Correct. In Cisco ISE Device Administration, the network device does not authenticate administrators locally by default; instead, it sends the login request to Cisco ISE using TACACS+. Cisco ISE is the central policy decision point for both authentication and authorization in this workflow. Although the wording says 'authorization server,' this best matches the required step where the device queries ISE for the admin login decision. After ISE evaluates policy, it returns the appropriate authorization result such as shell profile or command set.
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.
Correct. Cisco ISE can be configured to use an external identity store such as Active Directory or LDAP for device administration authentication. In that case, after receiving the TACACS+ request from the device, ISE queries the external identity source to validate the administrator credentials. This is a standard and common deployment model for centralized administrator authentication. The device itself never talks directly to the external identity store in an ISE-based design.
Core concept: Cisco ISE Device Administration uses TACACS+, where the network device acts as the TACACS+ client and Cisco ISE acts as the TACACS+ server. When an administrator logs in to a managed device, the device sends the authentication and authorization request to Cisco ISE, and ISE then validates the credentials against the configured identity source. The correct actions are that the device queries Cisco ISE and that Cisco ISE may query an external identity store such as Active Directory or LDAP. A common misconception is to think the device contacts the identity store directly or that both internal and external identity stores are queried for the same login. Exam tip: remember the flow as Device -> ISE -> Identity Store, with ISE returning the authorization result back to the device.
Which two components are required for creating a Native Supplicant Profile within a BYOD flow? (Choose two.)
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.
Connection Type is required because the supplicant configuration must match how the endpoint will access the network (for example, wireless 802.1X vs wired 802.1X). This selection influences the parameters ISE provisions (SSID/network identification, authentication method expectations, and how the endpoint should initiate the connection). Without connection type, ISE cannot build the correct onboarding payload.
Operating System is required because native supplicant provisioning is OS-dependent. ISE must know whether it is generating settings for Windows, macOS, iOS, Android, etc., since each platform supports different configuration mechanisms and EAP behaviors. Selecting the OS also determines which additional OS-specific configuration sections become available in the profile wizard.
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.
Core Concept: This question tests Cisco ISE BYOD onboarding, specifically the configuration of a Native Supplicant Profile. In a BYOD flow, ISE can provision a device to use 802.1X by pushing a supplicant configuration (for example, EAP-TLS) so the endpoint can authenticate securely after onboarding. Why the Answer is Correct: A Native Supplicant Profile is fundamentally defined by (1) what type of network connection it will be used for and (2) what endpoint platform it targets. Therefore, the two required components are Connection Type and Operating System. Connection Type determines whether the profile is for wired 802.1X, wireless 802.1X, or other supported onboarding contexts, which affects the supplicant configuration elements and how the endpoint will connect. Operating System is required because ISE generates OS-specific provisioning instructions and configuration payloads (e.g., Windows vs macOS vs iOS/Android have different supplicant capabilities and configuration methods). Key Features / Configuration Notes: In ISE, Native Supplicant Profiles are used by BYOD portals and onboarding policies to install certificates and configure the supplicant for EAP-TLS. The OS selection drives what settings pages/fields appear (e.g., Windows-specific options vs Apple iOS configuration profiles). The connection type aligns the profile with the SSID/wired access method and ensures the correct network parameters are provisioned. Common Misconceptions: Redirect ACL is often associated with BYOD because it is used on the NAD to redirect unknown endpoints to the BYOD portal (central web auth). However, it is not a required attribute of the Native Supplicant Profile itself; it is part of the access policy/authorization result on the network device. Similarly, “Windows Settings” and “iOS Settings” sound like required components, but they are conditional sub-settings that appear after you choose the OS; they are not universally required as top-level components. Exam Tips: For BYOD questions, separate “portal/onboarding artifacts” (supplicant profile, certificate provisioning, OS-specific payload) from “network enforcement artifacts” (redirect ACL, dACL, VLAN, SGT). If the question is about creating the profile, focus on the profile’s defining attributes: connection type + OS; enforcement items belong to authorization policy and NAD configuration.
Which port does Cisco ISE use for native supplicant provisioning of a Windows laptop?
TCP 8905 is the correct port for Cisco ISE native supplicant provisioning on Windows. In BYOD onboarding, the endpoint may reach the ISE portal over 443, but the actual provisioning service that pushes/configures the Windows native 802.1X supplicant uses this dedicated TCP port. If TCP 8905 is blocked, onboarding often fails after the portal page loads.
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.
Core Concept: This question tests Cisco ISE BYOD onboarding and, specifically, native supplicant provisioning for Windows endpoints. In ISE, “native supplicant provisioning” refers to ISE pushing 802.1X supplicant settings (EAP method, SSID/profile, certificate usage, etc.) to the endpoint so it can authenticate using EAP-TLS/PEAP without manual configuration. Why the Answer is Correct: Cisco ISE uses TCP 8905 for native supplicant provisioning of Windows endpoints. During BYOD onboarding (often via the MyDevices portal), the endpoint is redirected to ISE, downloads the provisioning components/profiles, and communicates with ISE over the dedicated provisioning port. TCP 8905 is the well-known port associated with ISE’s native supplicant provisioning service for Windows. Key Features / Configuration Notes: - This is part of the BYOD workflow (MyDevices portal + onboarding policy + certificate provisioning). - Ensure network devices, firewalls, and ACLs allow client-to-ISE connectivity on required onboarding ports (in addition to standard web access). - Native supplicant provisioning is distinct from general portal access (HTTPS/443). 443 is necessary for the web portal, but the actual provisioning channel for Windows uses the dedicated TCP port. - In real deployments, missing TCP 8905 reachability commonly causes onboarding to fail after the portal loads successfully, leading to partial installs or inability to push the WLAN/802.1X profile. Common Misconceptions: Many assume HTTPS 443 is the only requirement because users interact with a web portal. However, ISE onboarding can involve additional services/ports beyond the portal itself. Another common confusion is mixing RADIUS (UDP 1812) used for authentication between NAD and ISE with endpoint provisioning traffic, which is endpoint-to-ISE. Exam Tips: For 300-715, memorize the “special” ISE ports tied to onboarding/provisioning. If the question says “native supplicant provisioning (Windows),” think TCP 8905. If it says “portal access,” think TCP 443. If it says “RADIUS authentication,” think UDP 1812/1813 (auth/accounting) between NAD and ISE, not endpoint provisioning.
In which two ways can users and endpoints be classified for TrustSec? (Choose two.)
VLAN can be used as a basis for TrustSec classification through VLAN-to-SGT mapping. In this approach, endpoints placed into a specific VLAN are automatically assigned a corresponding SGT, providing a straightforward way to group devices when identity-based controls are limited. It is considered a more static/coarse method than per-session assignment, but it is common in transitional (brownfield) deployments.
Dynamic classification refers to per-session SGT assignment based on context (user identity, AD group, endpoint profiling, posture, location, etc.). In ISE, this is typically achieved in the Authorization Policy by returning an SGT (or Security Group) to the NAD via RADIUS. This is the preferred approach because it supports granular, scalable, identity-driven segmentation without relying on IP addressing or VLAN boundaries.
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.
Core concept: Cisco TrustSec classifies users and endpoints into Security Groups (SGTs) so that access control can be enforced using Security Group Access Control Lists (SGACLs). The classification itself is the act of assigning an SGT to a session/endpoint, and that assignment can be done in multiple ways depending on the enforcement point and integration. Why the answers are correct: A (VLAN) is correct because TrustSec can classify endpoints based on VLAN-to-SGT mapping. This is a common method when 802.1X/MAB is not available everywhere or when you want a simple, deterministic mapping at the access layer. The network device (or ISE via policy) can map an endpoint’s VLAN to an SGT, effectively classifying the endpoint into a TrustSec group. B (dynamic) is correct because the most common and recommended TrustSec classification is dynamic SGT assignment based on identity and posture context (user, group, endpoint type, posture, location, time, etc.). In ISE this is typically done via authorization policy results that return an SGT (or a Security Group name) to the NAD using RADIUS, enabling per-session, context-aware classification. Key features / best practices: - Dynamic classification via ISE authorization scales best and aligns with Zero Trust principles: classify by identity/context, not by IP/subnet. - VLAN-to-SGT mapping is useful for brownfield networks and for devices that cannot do 802.1X, but it is coarser-grained and can be bypassed if VLAN placement changes. - TrustSec enforcement is done with SGACLs on capable devices; classification (SGT assignment) and enforcement are separate steps. Common misconceptions: - SGACL is not a classification method; it is the enforcement policy applied after classification. - SXP is a transport mechanism for propagating IP-to-SGT bindings to devices that need them; it does not classify users/endpoints by itself. - QoS is unrelated to TrustSec identity classification. Exam tips: If the question asks “how users/endpoints are classified,” think “how an SGT gets assigned.” Typical answers are dynamic (per-session from ISE) and static methods such as VLAN-to-SGT (or IP/subnet-to-SGT in other contexts). If it asks “how policy is enforced,” that points to SGACLs, not classification.
A network engineer needs to ensure that the access credentials are not exposed during the 802.1X authentication among components. Which two protocols should be configured to accomplish this task? (Choose two.)
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-TLS is one of the most secure 802.1X authentication methods because it uses certificates for both client and server authentication. Since authentication is based on the TLS handshake and certificate validation, user passwords are not transmitted at all. This prevents credential exposure on the wire and also reduces the risk of password theft or replay. In enterprise Cisco ISE deployments, EAP-TLS is widely recommended when a PKI and client certificate management are available.
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.
EAP-TTLS establishes a TLS tunnel using the server certificate before any inner authentication takes place. Once that encrypted tunnel is in place, user credentials such as PAP, CHAP, or MSCHAP can be sent securely without being exposed in cleartext on the network. Its main security benefit is that the credential exchange is protected by TLS, which is exactly what the question is asking about. Although not always as commonly emphasized as PEAP in Cisco examples, it is still a valid secure tunneled EAP method.
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.
Core concept: The question asks which 802.1X EAP methods prevent access credentials from being exposed during authentication. The key idea is to choose EAP methods that either use certificates instead of passwords or create a TLS-encrypted tunnel to protect any inner credential exchange. Why correct: EAP-TLS uses mutual certificate authentication so no password is sent, and EAP-TTLS creates a TLS tunnel before carrying inner authentication data, protecting credentials in transit. Key features: TLS-based EAP methods provide confidentiality and server authentication, and in some cases client authentication as well. Common misconceptions: PEAP is also a tunneled method and protects credentials, but when asked for two protocols that ensure credentials are not exposed, EAP-TLS and EAP-TTLS are the directly correct TLS-based methods from the list; EAP-MD5 and LEAP are insecure. Exam tips: Eliminate legacy or non-tunneled methods first, then select EAP methods that explicitly rely on TLS for credential protection.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
What allows an endpoint to obtain a digital certificate from Cisco ISE during a BYOD flow?
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.
The Supplicant Provisioning Wizard is the BYOD onboarding component that configures the endpoint for secure network access and enables certificate enrollment. During the BYOD flow, SPW guides the user, provisions the supplicant/network profile as needed, and requests/installs a client certificate (often from the ISE Internal CA). This certificate is then used for EAP-TLS authentication, completing the secure BYOD onboarding process.
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.
Core Concept: In a Cisco ISE BYOD flow, the endpoint must be onboarded so it can authenticate securely (typically using EAP-TLS). This requires the endpoint to obtain and install a client certificate. Cisco ISE accomplishes this through its BYOD onboarding components, which guide the user and provision the certificate and (often) the wireless profile. Why the Answer is Correct: The Supplicant Provisioning Wizard (SPW) is the mechanism that enables an endpoint to obtain a digital certificate from Cisco ISE during BYOD. SPW is launched as part of the BYOD onboarding portal flow (often after an initial web authentication/redirect). It installs or configures the supplicant (where applicable), requests a certificate from ISE’s internal CA (or via an integrated CA), installs that certificate into the appropriate certificate store, and can configure the network profile so the device can rejoin using certificate-based authentication. Key Features / Configuration Notes: - Uses ISE BYOD portals and onboarding policies to determine which devices/users can onboard. - Typically issues certificates from ISE Internal CA (or an external CA integration), enabling EAP-TLS. - Can provision supplicant settings and wireless profiles (SSID, security settings) depending on OS. - Works with authorization policies that transition the endpoint from a limited onboarding VLAN/ACL to full access after successful certificate authentication. Common Misconceptions: Many confuse the My Devices Portal with the actual certificate issuance mechanism. The portal is primarily for device management (view/rename/delete) and can initiate onboarding, but it is not the component that performs supplicant configuration and certificate provisioning. Likewise, “Network Access Control” is a broad concept, not a specific BYOD certificate enrollment tool. Exam Tips: When you see “BYOD flow” plus “obtain a digital certificate,” think “onboarding” and “SPW/Certificate Provisioning.” Associate My Devices Portal with lifecycle management and visibility, not the actual certificate enrollment action. Also remember that the end goal is usually EAP-TLS with an ISE-issued (or CA-issued) certificate to uniquely identify the endpoint.
What occurs when a Cisco ISE distributed deployment has two nodes and the secondary node is deregistered?
Correct. Deregistering the secondary node removes it from the ISE deployment and it must reinitialize without the deployment registration/replication relationship. This process triggers a restart (commonly experienced as a node restart/reboot) on the deregistered secondary node so it can come up as a standalone node and stop participating in distributed services.
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.
Core concept: This question tests Cisco ISE node registration/deregistration behavior in a distributed deployment (PAN/MnT/PSN roles) and what happens operationally when a node is removed from the deployment. In ISE, nodes are “registered” to a Primary PAN (administration persona) and receive replicated configuration, certificates/trust relationships, and role assignments. Deregistering a node removes it from the deployment and breaks that replication relationship. Why the answer is correct: When the secondary node is deregistered, that node must transition from being a member of the distributed deployment to operating independently. To complete this transition cleanly, ISE restarts services (and in practice the node reboots/restarts) so it can reinitialize as a standalone system with its local configuration state and without the deployment trust/replication bindings. The primary node remains in control and does not need to restart because its role as the deployment anchor (Primary PAN) is unchanged. Key features and best practices: Deregistration is a controlled administrative action typically performed from the Primary PAN. After deregistration, the removed node no longer receives policy/config updates, no longer participates in replication, and any personas it hosted (PSN/MnT/secondary PAN) are no longer part of the deployment. Best practice is to plan for an outage of services hosted on the removed node (for example, RADIUS/TACACS+ if it was a PSN) and ensure redundancy before removal. Common misconceptions: It’s easy to assume the primary becomes “standalone” (option D) because only one node remains, but the primary is already the authoritative node; it simply continues as a single-node deployment. Another misconception is that both nodes must restart to renegotiate trust—ISE does not require the primary to restart just because a member node is removed. Exam tips: For SISE exam questions, distinguish between “failure” scenarios (node down) and “administrative change” scenarios (deregister/remove). Administrative deregistration impacts the removed node most directly (service restart/reboot and loss of deployment membership). The primary PAN generally remains stable unless you change its role or perform upgrades/patching.
A user reports that the RADIUS accounting packets are not being seen on the Cisco ISE server. Which command is the user missing in the switch's configuration?
“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 network default start-stop group radius” is the correct command to enable RADIUS accounting for network access sessions such as 802.1X and MAB on access ports. Once configured, the switch generates Accounting-Start and Accounting-Stop messages (and optionally interim updates if configured) and sends them to the RADIUS server/group (ISE), resolving the issue of accounting packets not being seen.
“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.
Core concept: This question tests Cisco IOS AAA accounting configuration for network access (802.1X/MAB) and how those accounting records are sent to Cisco ISE over RADIUS. In ISE deployments, you typically want RADIUS accounting (start/stop and optionally interim updates) so ISE can track session state, correlate authentications to active sessions, and support visibility/troubleshooting. Why the answer is correct: If the switch is not sending any RADIUS accounting packets to ISE, the most common missing piece is enabling AAA accounting for the “network” service. On Cisco switches, 802.1X/MAB port-access sessions fall under “aaa accounting network …”. Without this command, the switch can still authenticate users via RADIUS (authentication/authorization), but it will not generate accounting start/stop records for those network sessions. Therefore, adding: “aaa accounting network default start-stop group radius” enables accounting for network access sessions and causes the switch to send RADIUS Accounting-Start and Accounting-Stop messages to the configured RADIUS server group (ISE). Key features / best practices: - Use “start-stop” to generate both session start and end records; consider “aaa accounting update periodic <minutes>” for interim updates if required by your operational model. - Ensure the switch has “aaa new-model” enabled and that the RADIUS server/group is correctly defined (server IP, shared secret, source-interface, reachability). - In ISE, confirm the NAD is added and that RADIUS accounting is allowed/received (Live Logs, RADIUS Accounting reports, and node packet captures). Common misconceptions: - “exec” accounting is for administrative logins (VTY/console) and won’t create accounting for 802.1X/MAB sessions. - “resource” accounting is unrelated to user network access sessions. - “radius-server vsa send accounting” only affects whether vendor-specific attributes are included in accounting packets; it does not enable accounting generation. Exam tips: Map the AAA accounting keyword to the use case: - “network” = 802.1X/MAB/port-access sessions - “exec” = device administration sessions If the symptom is “no accounting packets seen,” look first for the missing “aaa accounting network …” line rather than attribute/VSA tuning commands.
A network administrator has just added a front desk receptionist account to the Cisco ISE Guest Service sponsor group. Using the Cisco ISE Guest Sponsor Portal, which guest services can the receptionist provide?
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.
Sponsors in the Guest Sponsor Portal are intended to onboard visitors. A receptionist in a sponsor group can create guest user accounts, set expiration/validity, choose allowed guest types (as permitted), and manage those accounts (reset credentials, extend time, disable/delete, reprint). This matches the real-world front desk workflow and aligns with sponsor group permission design in ISE Guest Services.
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.
Core Concept: Cisco ISE Guest Services separates “who can create/manage guest accounts” (Sponsors using the Sponsor Portal) from “who authenticates/authorizes guests on the network” (ISE Policy Sets, authentication sources, and authorization profiles). A user placed into a Guest Service sponsor group becomes a Sponsor and gains Sponsor Portal capabilities based on the sponsor group’s permissions. Why the Answer is Correct: A front desk receptionist added to the Cisco ISE Guest Service sponsor group can use the Guest Sponsor Portal to create guest accounts (for example, daily visitors), set validity periods, generate credentials (username/password), and manage those accounts (extend, disable, reset password, reprint, etc.). This is the primary operational role for reception/front-desk staff: onboarding guests quickly without giving them administrative access to ISE policy. Key Features / How It Works: Sponsor groups define what sponsors can do: create accounts, approve requests, manage accounts they created (or all accounts, depending on configuration), choose guest types, set maximum durations, and optionally print/email/SMS credentials. The Sponsor Portal is a workflow tool; it does not change network policy. Actual guest access is enforced by ISE authentication (often MAB/WebAuth/802.1X) and authorization rules (dACLs, VLANs, SGTs) configured by ISE administrators. Common Misconceptions: It’s easy to confuse “guest services” with “guest policy.” Sponsors do not configure authorization settings (that’s an admin task in Policy Sets/Authorization Profiles). Sponsors also do not “authenticate guests to ISE”; authentication occurs when the guest connects and the NAD redirects to ISE (CWA) or performs 802.1X/MAB. “Keeping track of guest user activities” sounds plausible, but detailed activity tracking is typically done via ISE Live Logs/Reports and requires admin/reporting permissions, not basic sponsor capabilities. Exam Tips: For 300-715, remember the role split: - Sponsor Portal = account lifecycle (create/manage/approve) within limits of sponsor group. - ISE Admin/Policy = authentication/authorization design and enforcement. If a question mentions a receptionist/sponsor, the expected capability is creating and managing guest accounts, not changing policy or performing authentication itself.
Interface: GigabitEthernet2/0/36
MAC Address: 000e.84af.59af
Status: Authz Success
Domain: DATA
Oper host mode: single-host
Authorized By: Authentication Server
Vlan Policy: 10
Handle: 0xE0000000
Runnable methods list:
Method State
dot1x Authc Success
Refer to the exhibit. Which command is typed within the CLI of a switch to view the troubleshooting output?
This is the correct command. It queries the authentication session table for a specific endpoint MAC address and, with “details,” displays deep troubleshooting fields such as Authz status, host mode, “Authorized By,” VLAN/policy results, session handle, and the runnable methods list (dot1x/MAB). The exhibit is clearly a per-MAC detailed session output.
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.
Core Concept: This question tests your ability to identify the Cisco switch CLI command used to display detailed 802.1X/MAB authentication session troubleshooting information for a specific endpoint. In ISE deployments, the switch is the Policy Enforcement Point (PEP). When troubleshooting “Authz Success/Failure,” VLAN assignment, authorization source, and method state, you typically inspect the live authentication session on the NAD. Why the Answer is Correct: The exhibit output format (Interface, MAC Address, Status: Authz Success, Domain, Oper host mode, Authorized By, Vlan Policy, Handle, and “Runnable methods list” showing dot1x Authc Success) matches the detailed per-session view produced by: show authentication sessions mac <mac> details This command filters directly by the endpoint MAC and provides the richest session context: which method succeeded (dot1x vs mab), current authorization status, assigned VLAN/policy, and which server authorized the session (ISE). It is the most precise command to reproduce the shown output because the exhibit is clearly centered on a single MAC address session. Key Features / Best Practices: - Use per-session “details” output to confirm method order (dot1x first, then MAB), host mode (single-host/multi-auth), and authorization results (VLAN, dACL, SGT where applicable). - Pair this with switch debugs (when needed) and ISE Live Logs for end-to-end correlation (MAC, username, session ID/handle). - In exam scenarios, recognize that “show authentication sessions … details” is the go-to for actionable session troubleshooting on IOS/IOS-XE access switches. Common Misconceptions: - Commands that show interface-wide summaries can look similar but won’t necessarily include the same per-MAC “Runnable methods list” and granular fields. - “registrations” is typically associated with device tracking/registration concepts, not 802.1X session state. Exam Tips: - If the question shows a single endpoint’s MAC and deep session fields (status, authorized by, VLAN policy, method list), choose the command that targets a session and includes “details.” - When you see “Authz Success” and method state lines, think: show authentication sessions [mac|interface] … details.
Cloud Pass를 다운로드하여 모든 Cisco 300-715: Implementing and Configuring Cisco Identity Services Engine (SISE) 연습 문제를 무료로 이용하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.