A manufacturer runs ISE as three VMs on a shared vSphere cluster that still has spare CPU and memory. The licence already covers every endpoint, wired profiling is active, and the monitoring dashboards stay responsive, yet RADIUS requests queue and time out in the 08:00 reauthentication wave. Which change best restores authentication capacity?
Select an answer to reveal the explanation.
Short Explanation
Authentication rate is a Policy Service Node job, so adding nodes is how you buy throughput in ISE. Each VM only scales within its own allocation, so making another role bigger won't feed the RADIUS queue. You add capacity where the queue actually forms.
Full Explanation
Authentication throughput is a Policy Service Node function: the PSN terminates RADIUS, runs authentication and authorization, and performs profiling for the endpoints it serves, so horizontal scale is the lever when requests queue. Adding nodes and spreading the primary, secondary and tertiary RADIUS server lists across them puts processing power directly where the queue forms, and your spare cluster capacity makes that affordable. Enlarging the monitoring node addresses log indexing and reporting, which your responsive dashboards show is already healthy, so it leaves the RADIUS queue untouched. A higher licence tier changes which features a deployment may use rather than how fast a node answers a RADIUS request, and your licence already covers every endpoint, so nothing about the wave changes. A separate Monitoring node sounds like a clean split, yet the profiling service only runs on the Policy Service persona, so the work does not move and the queue does not shrink. Exam caveat: exact VM sizing guidance changes between ISE releases, so reason from roles rather than memorising core counts. Practical check: during the next wave watch RADIUS live sessions and CPU per PSN, then confirm each device lists the new nodes in its server group.