Three departments will share one appliance, each with its own dedicated storage space. Each department wants its own administrators who can fully manage their space but cannot see or touch what the others hold. Which design answers that?

Sharing one appliance across administrative domains is exactly what Secure Multi-Tenancy exists for: SMT partitions the system into contexts, each with its own administrators whose authority stops at the context boundary, so a department's admins manage their storage and views with enforcement rather than with forbearance. That is a platform mechanism applied to an administrative requirement, which is where a design question like this should land. Custom roles on a flat system fail by concept: with a single administration plane, hiding other tenants' filesystems in command output conceals rather than enforces - commands, metrics and configuration that were never meant to cross a boundary remain reachable underneath the cosmetic filter. File-level access controls are a client-data path: MTree ACL discipline governs how clients access stored data, not what an administrator's CLI or GUI session can administer, so it cannot scope administration at all. Named accounts with a conduct policy describe expected behavior and enforce none of it - a security-reviewed design cannot rest on norms, and the question asks for reach that stops at a boundary, which is the opposite of trust. Exam caveat: SMT reshapes addressing, contexts and administration, so it must be designed in before services migrate onto the appliance rather than bolted on afterward. Operational check: a tenant A administrator attempts to view and modify a tenant B resource and is denied at both attempts.