Architecture And Deployment practice questions

The Secondary PAN must be manually promoted to Primary to restore MnT functionality

Why it fails: MnT runs on both PAN nodes in a high-availability pair, so the Secondary assumes the monitoring role automatically without manual promotion. Manual promotion applies to recovering a failed node, not to restoring MnT, which is why this option misstates the failover behaviour.

ISE enters a read-only state for all PSNs

Why it fails: A PAN failure does not place PSNs into read-only mode; PSNs continue authentication and authorisation, while the Secondary PAN takes over policy and monitoring duties. Read-only states relate to database replication issues or licensing problems, not to PAN failover.

MnT services immediately stop on all nodes

Why it fails: MnT services continue on the Secondary PAN node, which assumes the monitoring role after failover; they do not stop across all nodes. This option is tempting because losing the Primary PAN sounds catastrophic, but the pair is designed for automatic service continuity.

Shut down the PSN server

Why it fails: This abruptly terminates all current sessions.

Remove the PSN from the load balancer

Why it fails: While this stops new traffic, it doesn't handle ISE-specific session draining.

Change the node to an MnT-only role

Why it fails: MnT nodes are not intended to handle traffic loads.

TACACS+

Why it fails: TACACS+ is for device admin, not end-user posture.

FTP

Why it fails: FTP is not used for posture.

DHCP

Why it fails: DHCP is for IP assignment.

Upgrade PSNs, then PAN

Why it fails: Upgrading the PAN first is mandatory.

Upgrade all nodes simultaneously

Why it fails: Simultaneous upgrades are not supported and risk data corruption.

Upgrade Secondary nodes, then Primary PAN

Why it fails: This is the incorrect sequence.

Unlimited

Why it fails: ISE clusters have hard limits.

50 nodes

Why it fails: This exceeds the architectural support.

10 nodes

Why it fails: The limit is higher.

Dedicated pxGrid node only

Why it fails: The pxGrid controller role can run on a standalone node or share a persona with other services such as the PAN or MnT, so restricting it to a dedicated node is unnecessary. It is tempting because dedicated nodes isolate load, which suits very large deployments, but Cisco does not require that topology.

Monitoring node only

Why it fails: Monitoring nodes are not for pxGrid.

Primary PAN only

Why it fails: pxGrid can run on PSNs.

Authentication Proxy Node

Why it fails: Authentication Proxy Node is not an ISE persona; the valid set is Policy Administration, Policy Service, Monitoring and pxGrid. It is tempting because ISE does proxy authentication to external identity stores, so the name sounds like a real node role.

Database Node

Why it fails: Database Node is not an ISE persona; the internal database runs on the PAN and PSNs rather than as a separate deployable role. It is tempting because ISE stores endpoint and identity data, so a dedicated database node sounds architecturally reasonable.

Reporting Node

Why it fails: Reporting Node is not an ISE persona; reporting is delivered by the Monitoring persona, which also handles logging and troubleshooting. It is tempting because reporting is a distinct function, so splitting it into its own node role appears logical.

Automatic heartbeat detection

Why it fails: ISE does not use automated heartbeat failover for PAN.

External load balancer re-routing

Why it fails: The load balancer is not used for PAN administration traffic.

The secondary node must be pre-configured as a PAN

Why it fails: The secondary node is configured automatically by the Primary.

Both nodes must have different hostnames

Why it fails: Hostnames are required, but this is a standard OS requirement, not a deployment prerequisite.

The secondary node must have a different IP subnet

Why it fails: Subnet does not affect deployment.

A list of all other nodes in the cluster

Why it fails: The Primary PAN handles the discovery.

A shared secret for RADIUS

Why it fails: RADIUS secret is for network devices, not node registration.

A valid license file for the secondary node

Why it fails: Licenses are managed at the deployment level.

A factory reset is performed

Why it fails: A factory reset erases the node's configuration and identity, so it cannot satisfy any upgrade prerequisite; upgrades preserve existing settings and data. It is tempting because factory resets are used when redeploying a node or recovering from corruption, where a clean rebuild is genuinely required rather than an in-place upgrade.

The node is in 'Standalone' mode

Why it fails: Standalone mode describes a single-node deployment, not a prerequisite for upgrading a distributed node. Upgrades require the node to be registered, synchronised and healthy within the deployment, with adequate disk space and a valid backup.

Insufficient memory on the node

Why it fails: Node join failures stem from certificate, DNS, NTP, or connectivity problems, not host memory. Insufficient RAM degrades performance after a successful join rather than preventing registration with the PAN. The option tempts because resource shortages cause many deployment faults, but the join process itself is gated by trust and name resolution, not memory.

License mismatch between nodes

Why it fails: ISE nodes in a deployment share licensing centrally through the PAN; mismatched licences do not block a node from joining. Join failures trace to certificate trust, DNS resolution, time synchronisation, or port connectivity instead. The option tempts because licensing errors do surface elsewhere in ISE, but they are not a registration gate for deployment membership.

Incorrect browser version

Why it fails: Node registration is a server-to-server process using certificates, DNS, and NTP; the administrator's browser plays no part in whether a node joins. Browser version matters only for GUI rendering and administration access. The option tempts because browser compatibility issues are common in ISE administration, but they cannot prevent a node from joining a deployment.

Database Migration Service

Why it fails: This is a backend tool, not a configurable service.

Administrator Service

Why it fails: Admin services are controlled globally via PAN.

The Secondary PAN must be manually promoted using the ise/admin CLI before it can take over, and it cannot receive configuration updates until promotion occurs.

Why it fails: Manual promotion is not required for PAN failover in ISE. The Secondary PAN continuously receives configuration replication from the Primary PAN and can take over automatically. Requiring an administrator to run a promotion command would defeat the high-availability purpose of the Secondary PAN persona.

Both PANs operate in active/active mode, and configuration changes made on either PAN are immediately replicated to the other, providing simultaneous administrative access.

Why it fails: Cisco ISE does not support active/active PAN operation. Only one PAN is active for configuration at a time; the Secondary PAN is a standby that receives replicated configuration but does not accept concurrent administrative changes. This option describes a load-balanced model that does not exist for the PAN persona in ISE.

The Secondary PAN can accept configuration changes only after the Primary PAN is shut down, and it never receives automatic configuration updates from the Primary PAN.

Why it fails: The Secondary PAN does receive automatic configuration replication from the Primary PAN while both are online. It cannot accept configuration changes concurrently with the Primary PAN, but it is not dependent on Primary shutdown to receive updates. This option incorrectly describes both the replication and the failover behavior.

Monitoring and Troubleshooting Node (MnT)

Why it fails: The MnT persona collects logs, alarms, and reporting data from other nodes but does not perform certificate provisioning or endpoint onboarding. It is not involved in the BYOD flow or in issuing certificates to endpoints. Deploying an MnT node would not address the need for certificate provisioning without a publicly signed certificate.

pxGrid controller node

Why it fails: The pxGrid controller facilitates information sharing between ISE and other systems, such as threat defense or SIEM. It does not provide certificate provisioning or endpoint onboarding. While important for integration, it does not fulfill the requirement of issuing certificates to BYOD devices without a publicly signed certificate.

Policy Administration Node (PAN)

Why it fails: The PAN is responsible for storing and distributing configuration and policies to other nodes. It does not provide certificate provisioning services for endpoints. While it manages the overall deployment, it does not directly interact with endpoints for BYOD onboarding or certificate enrollment, so it cannot satisfy the requirement of issuing certificates without a publicly trusted CA.

Enable the Monitoring persona on the Secondary PAN to allow it to take over.

Why it fails: The Monitoring persona (MnT) handles logging and reporting, not administrative functions. Enabling MnT on the Secondary PAN does not enable it to take over the PAN role. This is unrelated to PAN failover and would not provide the required automatic failover.

Configure the Secondary PAN as a standalone node and manually promote it when needed.

Why it fails: A standalone node does not participate in the ISE deployment as a PAN. Manual promotion is not automatic failover and would cause downtime. This approach does not meet the requirement for automatic takeover and would require administrative action, which is not desired.

Set up a load balancer in front of the PANs to distribute administrative traffic.

Why it fails: Load balancing is used for PSNs to distribute RADIUS traffic, not for PAN administrative functions. PANs do not support load balancing for administrative access. This configuration would not provide automatic failover for the PAN role and is not a supported design.

Deploy a Secondary PAN and ensure that PSNs are registered to both PANs for policy updates.

Why it fails: PSNs are registered to the deployment, not individually to both PANs. They receive policy updates from the Primary PAN. If the Primary PAN fails, the Secondary PAN takes over and PSNs continue to function with cached policies. The concept of registering to both PANs is not accurate.

Deploy at least two PSNs and configure them to use the Secondary PAN for policy retrieval.

Why it fails: PSNs retrieve policies from the PAN, but they do not directly use the Secondary PAN for policy retrieval. Instead, they cache policies and can continue to operate if the PAN is down. Deploying multiple PSNs provides redundancy for authentication services, but the statement about using the Secondary PAN is incorrect.

Deploy multiple PSNs and ensure they have network connectivity to the PANs and to each other.

Why it fails: While PSNs need connectivity to the PANs for policy updates, they do not require connectivity to each other for authentication. Each PSN operates independently and can authenticate endpoints using cached policies. This option is partially correct but not the most critical practice for PAN downtime resilience.

PSNs will stop authenticating endpoints after 24 hours if they cannot reach a PAN.

Why it fails: PSNs do not have a hard-coded 24-hour limit. They can continue to authenticate using cached policies indefinitely, as long as the policies do not change. The 24-hour figure is not a standard limit. Authentication continues until the PSN is restarted or the cache is cleared.

PSNs will reject authentication requests until a PAN becomes available again.

Why it fails: PSNs are designed for high availability and will continue to authenticate using cached policies. They do not reject requests solely because a PAN is unavailable. This ensures that network access is not disrupted during administrative outages.

PSNs will automatically promote one of themselves to take over the PAN role.

Why it fails: PSNs cannot be promoted to PAN. The PAN role is a separate persona that must be explicitly configured. PSNs handle authentication and authorization but do not have administrative capabilities. Automatic promotion is not a feature of ISE.

The Secondary PAN can be used for monitoring and troubleshooting (MnT) functions.

Why it fails: The MnT persona is separate and can be enabled on a PAN, but it is not a default function of the Secondary PAN. In a distributed deployment, MnT is typically dedicated to separate nodes or co-located with the PAN. The Secondary PAN's primary role is to serve as a backup for the Primary PAN, not to handle MnT.

The Secondary PAN can be used to offload some of the authentication load from the Primary PAN.

Why it fails: The Secondary PAN does not handle authentication traffic. Authentication is performed by PSNs. The Secondary PAN is primarily for administrative redundancy. Offloading authentication to a PAN is not a supported function; PANs do not have the Policy Service persona enabled by default.

The Primary PAN also acts as a PSN by default.

Why it fails: The Primary PAN does not act as a PSN by default. While it is possible to enable the Policy Service persona on a PAN, it is not recommended for large deployments due to performance considerations. By default, the PAN is dedicated to administration and monitoring functions.

Policy Administration Node (PAN)

Why it fails: The PAN stores policy configuration and pushes it to other nodes; it does not process endpoint authentication requests, so it cannot offload that load. It is tempting because it is a dedicated persona in distributed deployments, but the Policy Service Node is the persona built to handle authentication and authorisation traffic.

Standalone Node

Why it fails: A standalone node runs every persona on one appliance, so it cannot be dedicated to authentication and will bottleneck at 50,000 concurrent endpoints. It is tempting for small sites where simplicity and cost matter, but distributed deployments separate the Policy Service Node precisely to scale authentication independently.

Monitoring and Troubleshooting Node (MnT)

Why it fails: The MnT persona handles logging, reporting and monitoring, not authentication processing, so it cannot absorb RADIUS or TACACS+ load. It is tempting because it is a dedicated node in large deployments, but its purpose is visibility and troubleshooting; the Policy Service Node exists specifically to serve authentication and authorisation requests.