Select Two (Multi-Select) Questions

TACACS+ command set

Why it fails: A TACACS+ command set authorises which CLI commands an administrator may run on a network device; it does not classify traffic into security groups or enforce group-based ACLs. TACACS+ is correct for granular device administration accounting and command authorisation.

RADIUS shared secret

Why it fails: A RADIUS shared secret authenticates a device to a RADIUS server; it carries no security group tag and enforces no group-based policy. RADIUS is the correct choice when centralising 802.1X user or device authentication, not for defining TrustSec source-group-to-destination-group enforcement.

SMTP

Why it fails: SMTP is a mail transfer protocol, not an ISE probe; ISE probes include RADIUS, TACACS+, SNMP, DHCP, DNS and HTTP for gathering endpoint attributes. It is tempting because SMTP is a familiar network service, but ISE never queries mail servers to profile devices.

FTP

Why it fails: FTP is a file-transfer protocol, not an ISE profiling probe; it cannot query endpoints for attributes such as operating system or MAC address. It is tempting because ISE does support FTP for scheduled repository backups and log exports, where transferring files to an external server is the actual requirement.

Mapping VLANs to specific guest SSIDs.

Why it fails: VLAN-to-SSID mapping is configured on the Cisco WLC or in Cisco ISE policy sets, not in the Sponsor Portal, which only creates and manages guest accounts. It tempts because SSID and VLAN settings feel guest-related, yet such mapping belongs to wireless infrastructure configuration, not sponsor-facing guest provisioning.

Configuring global portal branding.

Why it fails: Global portal branding is configured in the Cisco ISE Admin portal under Admin > System > Portal Customisation, not the Sponsor Portal, which only exposes sponsor-scoped settings. It is tempting because sponsors can adjust their own guest-facing portal content, but tenant-wide branding sits with administrative policy configuration rather than sponsor account management.

Defining RADIUS shared secrets.

Why it fails: RADIUS shared secrets are configured on network access devices and in Cisco ISE policy elements, not in the Sponsor Portal, which only creates and manages guest accounts. It is tempting because shared secrets are part of ISE's authentication configuration, but they belong to device administration workflows rather than sponsor-facing guest provisioning.

They replace the need for accounting

Why it fails: Shell profiles set a user's default shell, environment variables and command restrictions at login; they do not record or report user activity, which accounting handles separately. They are tempting because both are configured per user in TACACS+ or RADIUS policy, so a profile can look like a substitute when auditing is actually required.

They define the command set to be used

Why it fails: Shell profiles govern session authorisation attributes — access hours, VLAN assignment, reauthentication timers and dACLs — not command authorisation. Command sets define permitted CLI commands and are referenced separately within authorisation policy. The option conflates the two distinct policy components, which are configured and applied independently in Cisco ISE.

They are used for RADIUS authentication only

Why it fails: Shell profiles are authorisation constructs applied after authentication succeeds, governing per-user or per-group session attributes such as access hours, VLANs and reauthentication timers. They are engine-agnostic and unrelated to RADIUS, which is one of several authentication protocols Cisco ISE supports independently of shell profile configuration.

Cisco IOS syslog

Why it fails: IOS syslog on the ASA records connection, interface and VPN session events, but posture evaluation happens on the endpoint via the posture module and ISE. Syslog is correct for headend and tunnel faults; compliance verdicts need client-side DART logs and ISE posture reports.

AnyConnect VPN Gateway logs

Why it fails: Gateway logs record tunnel establishment, authentication and session events, not the endpoint's posture assessment results. They are the right source for connection and AAA failures, whereas compliance-check failures require the AnyConnect client's posture module and DART bundle on the endpoint itself.

Selection of the switch interface.

Why it fails: The switch interface is a network-access setting, not a guest portal login page customisation option; portal pages are edited through the ISE portal editor. It is tempting because interface selection matters when configuring switch ports for guest access, which is the correct context for that setting.

Direct editing of the Apache server config files.

Why it fails: Cisco ISE guest portal customisation is performed through the Admin portal's portal editor and its supported fields, not by editing Apache configuration files on the node. It is tempting because direct file edits offer total control, which is the correct approach for unsupported deep customisation outside the guest portal feature.

Configuration of the RADIUS shared secret.

Why it fails: The RADIUS shared secret authenticates RADIUS client-server exchanges, so it is configured on the RADIUS server and its clients, not exposed as a guest portal customisation setting. It is tempting because guest authentication often relies on RADIUS, but that is authentication plumbing, not login page branding.

Checking the Network Device Group membership list.

Why it fails: Network Device Group membership is static configuration data held on the PSN; it confirms how a device is classified, not whether any TACACS+ packet arrived. It would be the right check when troubleshooting authorisation policy matching for a known device, but it cannot evidence live request receipt.

Viewing the Policy Set order of precedence.

Why it fails: Policy set order of precedence governs which authorisation policy matches a request; it reveals nothing about whether packets arrive at the PSN. It is tempting because policy misordering causes authentication failures, and checking precedence would be correct when troubleshooting why a request is matched by the wrong rule.

Checking the switch console logs for AAA server status.

Why it fails: Switch console logs record the device's own AAA server status and any local timeout or unreachable messages, which reflects the client's view rather than proof the PSN received the request. Console logging is the correct place to confirm the device is configured to send TACACS+ to the intended server.

Policy distribution

Why it fails: Policy distribution is a Configuration persona function, pushing policy XML to Cisco ISE nodes; the MnT persona instead collects logs and runs reports. It tempts because policy deployment does touch every node, yet the question asks which persona owns that task, and distribution sits with Policy Administration, not monitoring.

RADIUS authentication

Why it fails: RADIUS authentication is handled by the Policy Service persona, which processes access requests against policy sets; MnT passively records and reports on those authentications. It tempts because MnT dashboards display live RADIUS logs, yet the persona performing authentication is Policy Service, not Monitoring and Troubleshooting.

Endpoint profiling probe

Why it fails: Endpoint profiling probes belong to the Profiling persona, which gathers attributes to classify endpoints; MnT only consumes the resulting logs and alarms. It tempts because profiling data appears in MnT reports, but the probe itself is a separate persona service, so it is not an MnT function.

Increased log storage capacity

Why it fails: Increased log storage capacity is unrelated to PSN count; PSNs handle user traffic and RADIUS authentication, not log retention. It is tempting because scaling infrastructure often implies more storage, and adding nodes does increase aggregate disk. It would be relevant if the scenario concerned log volume or retention sizing, where storage capacity genuinely drives design decisions.

Centralized database backup

Why it fails: Centralised database backup concerns data protection, not PSN count. Multiple PSNs exist to distribute authentication load and provide failover across sites or regions. Backup architecture is addressed separately through database replication and disaster-recovery tooling, so it would be the deciding factor only when designing resilience for the configuration store itself.

Install a dedicated agent on every switch

Why it fails: Switches act as NADs forwarding RADIUS requests; they need no per-switch agent, only 802.1X/MAB and CoA configuration. Installing agents resembles endpoint posture software, which is a separate function, so this is not a BYOD prerequisite. The mandatory steps involve certificate provisioning and guest/self-registration portals.

Create a local user account for every device

Why it fails: BYOD authenticates devices against external identity stores or certificate authorities, not manually created local accounts; per-device local users do not scale and bypass the registration flow. Local accounts suit small lab or fallback admin access, whereas BYOD requires PKI, an authorisation policy and a device registration portal.

Disable RADIUS authentication

Why it fails: RADIUS authentication is the transport ISE uses for 802.1X and MAB; disabling it removes the enforcement channel BYOD depends on. It is tempting because some deployments add RADIUS later, but the mandatory steps are certificate/PKI setup, portal configuration and policy sets — not tearing down the authentication protocol.

Device Administration console

Why it fails: The Device Administration console manages network device definitions and their RADIUS configuration, not per-session authorisation outcomes. It is tempting because devices are integral to ISE, but policy match results are surfaced in operational session data, such as Live Logs and authentication detail reports.

Identity Group properties

Why it fails: Identity Group properties define membership and directory attributes; they never record which authorisation policy matched a session. It is tempting because groups drive policy conditions, yet the match result lives in the session's authentication and authorisation detail, not the group object itself.

RADIUS Secret settings

Why it fails: RADIUS Secret settings hold shared keys for authenticating network devices; they store no authorisation outcome, so no policy match result appears there. It is tempting because RADIUS configuration is central to ISE deployments, but it belongs to device authentication setup, not policy evaluation reporting.

The device must be connected via VPN

Why it fails: Native Supplicant Provisioning enrols the device over the onboarding SSID or via Apple Configurator before any supplicant exists, so a VPN tunnel cannot be established first. It tempts because VPNs secure management traffic generally, and would be correct where the requirement was protecting configuration delivery rather than initial supplicant enrolment.

The device must be jailbroken

Why it fails: Native Supplicant Provisioning installs a supplicant profile on a stock, unmodified iOS device; jailbreaking breaks the platform integrity Cisco ISE relies on and is never required. It tempts because jailbroken devices can sideload profiles, which would be relevant only for unsupported or legacy hardware outside the supported iOS baseline.

Eliminates the need for RADIUS

Why it fails: TrustSec still relies on RADIUS for 802.1X authentication and for propagating security group tags via SXP or device authorisation; it replaces IP-based ACLs with SGT-based policy enforcement, not the authentication protocol. It is tempting because TrustSec centralises policy, but RADIUS remains the transport for identity and tag exchange.

Reduces network latency

Why it fails: TrustSec enforces role-based access through security group tags and SGACLs, adding classification and tagging overhead rather than reducing latency. It is tempting because centralised policy can cut churn in large environments, but latency reduction is not an architectural benefit; the correct answers concern simplified, scalable policy enforcement.

Automatic dACL creation

Why it fails: TrustSec propagates security group tags and enforces SGACLs dynamically on switches and firewalls; it does not auto-generate downloadable ACLs, which belong to Cisco ISE's dACL feature for traditional ACL enforcement. It is tempting because both centralise policy, but dACL creation is an ISE authorisation function, not a TrustSec benefit.

Identity Source Sequence

Why it fails: An Identity Source Sequence belongs to the authentication policy, where ISE resolves the user's credentials against ordered identity stores. The authorisation policy instead evaluates conditions such as AD group membership or RADIUS attributes. Selecting it here confuses the two policy stages, though it is the correct component when configuring authentication source fallback.

Command Set

Why it fails: A Command Set applies to TACACS+ device administration, restricting which CLI commands an administrator may run on network devices. RADIUS authorisation rules instead use authorisation profiles, dACLs and VLAN assignments. It would be correct for a TACACS+ command authorisation policy, not a RADIUS-based one.

FTP inspection

Why it fails: FTP inspection is not a profiling probe; ISE collects attributes via NetFlow, DHCP, RADIUS, SNMP, NMAP and similar sources, not FTP session content. FTP would matter only when profiling an endpoint that exposes attributes through file transfers, which ISE does not parse.

SSH terminal login

Why it fails: SSH terminal login is not a supported ISE profiling collection method; probes gather attributes passively or via SNMP, DHCP, RADIUS, NetFlow and NMAP. SSH login would be relevant only for interactive device administration, not automated endpoint attribute collection.

Only encrypts the password field

Why it fails: TACACS+ encrypts the entire packet body, not merely the password field, leaving only the header in clear text. It is tempting because RADIUS does encrypt only the password attribute within Access-Request packets, so that description fits RADIUS rather than TACACS+.

Uses UDP port 1812

Why it fails: TACACS+ encapsulates its traffic in TCP, using port 49, so UDP 1812 is factually wrong; that port belongs to RADIUS authentication. It is tempting because RADIUS and TACACS+ are both AAA protocols frequently compared, and RADIUS does rely on UDP 1812/1813.

Configure an SGT

Why it fails: SGTs are for RADIUS, not TACACS+.

Enable MAB

Why it fails: MAB is for wired/wireless access, not admin access.

Eliminates the need for shared secrets

Why it fails: NDGs group network devices for policy assignment; they do not remove the shared secret each device still needs to authenticate with Cisco ISE. It is tempting because NDGs centralise authorisation policy, but the RADIUS or TACACS+ shared secret remains a per-device credential requirement.

Automatically updates the device config

Why it fails: NDGs only classify devices for policy assignment; they never push configuration changes to the device itself. It is tempting because grouping devices feels like centralised management, but configuration updates require a separate provisioning tool, not ISE authorisation policy.

Replaces the need for TACACS+ command sets

Why it fails: Command sets remain separate authorisation objects that NDGs reference when assigning policy; grouping devices does not replace them. It is tempting because NDGs simplify applying consistent policy across many devices, but the command set itself still defines the permitted TACACS+ commands.

User password stored in the endpoint registry

Why it fails: EAP-TLS authenticates with X.509 client certificates, so no password is transmitted or checked; the registry copy is irrelevant. Passwords belong to PEAP-MSCHAPv2, where a credential is validated against Active Directory — that is when a stored password would matter.

Active Directory GPO to force login

Why it fails: EAP-TLS validates the supplicant's client certificate against a trusted CA chain; a GPO forcing interactive login neither issues nor presents that certificate. GPOs suit pushing wireless profiles or certificate auto-enrolment settings, not the authentication exchange itself.

SMTP

Why it fails: SMTP carries email, which plays no part in enrolling, securing or retiring employee-owned devices. It would be correct for messaging infrastructure, not device lifecycle management. BYOD depends on 802.1X, EAP, RADIUS, TLS and MDM enrolment standards instead.

FTP

Why it fails: FTP transfers files without encryption or device posture checks, so it cannot enrol, authenticate or remediate a personal device. It is the right protocol for bulk unencrypted file movement on trusted networks. BYOD lifecycle control relies on 802.1X, EAP, RADIUS and TLS instead.