A retail chain's NOC has junior and senior network engineers using ISE for TACACS+ on branch routers. Juniors must run show commands and routine interface changes; only seniors may run reload or clear commands; and any command outside a junior's approved list must be refused. Which command-authorization design fits these two roles?
Select an answer to reveal the explanation.
Short Explanation
Exactly right: a command set is where ISE separates what a role may run from everything else. When you list only the permitted commands, anything outside the list is refused automatically. Separate sets per role keep each boundary honest, and that's the deny-by-default habit you're being tested on.
Full Explanation
Every command a user types is sent to ISE over TACACS+, where the shell profile points to a command set, the entries are matched in order, and anything the set never matched is refused. That deny-by-default behaviour is the design: juniors get a set listing their show and interface work, so daily tasks run while reload and clear fall into the refused tail, and seniors get a second set where those commands are permitted. A permit-all set with an explicit deny list fails because every command you forgot to name is allowed, putting dangerous commands in reach of a junior. One shared set fails role separation, because both roles point at the same profile, so juniors inherit senior rights no matter who logs in. A read-only junior set fails the interface-change requirement, because configuration commands are absent from the permitted list. Exam caveat: matching can use privilege level or command text with or without arguments, and that detail shifts with release and platform. Practical check: log in as a junior, run a permitted show command, then attempt a reload and watch the TACACS+ live session log reject it.