Two departments will share one new Data Domain system, but the security review requires that neither can see or address the other's data, namespaces, or administration. When should the engineer capture this requirement, and what design decision does it drive?
Select an answer to reveal the explanation.
Short Explanation
Sharing-but-separated is a floorplan decision, not a padlock you add after move-in. Secure Multi-Tenancy gives each department its own context—its own namespace, network interfaces, and admin view—and retrofitting that later is far more expensive than designing it now. Capture the requirement while the blueprint still has an eraser on it.
Full Explanation
Secure Multi-Tenancy is an architectural isolation model in DD OS: contexts partition data, users, network interfaces, DNS, and administrative authority so that a tenant inside one context cannot address or even see objects belonging to another. Because the isolation boundary touches licensing, interface planning, DNS and how backup applications mount storage, it must be decided at design time. Leaning on folder-level ACLs later fails by concept because ACLs govern access inside one shared management domain where namespaces remain visible, which is weaker separation than the security review demanded. Assuming isolation appears automatically per application fails because a default single-context system is deliberately shared, not partitioned. Treating separation as a licensing step that follows capacity sizing inverts the dependency, because tenant count is an input to interface and capacity planning, not an output of it. Exam caveat: SMT permanently changes administrative workflows, so tenant administrators and escalation paths belong in the same design document. Operational check: draw the context diagram showing each department's interfaces, storage, and admin accounts, and have the security team sign that boundary map before the order is placed.