During a post-deployment review, an auditor asks what technically prevents a tenant A administrator from reading tenant B data on a shared Data Domain system. What must be configured to enforce that separation?
Select an answer to reveal the explanation.
Short Explanation
Think of it like apartment security: locks on drawers don't stop someone wandering into another unit; you need walls and a separate entryway. Secure Multi-Tenancy gives each tenant its own enforced context, isolating network and data, not just permissions. Don't confuse tenant isolation with MTree access controls.
Full Explanation
Secure Multi-Tenancy creates separate tenant contexts on a shared Data Domain system. Each context has its own administrative scope, network resources, and data namespace, so a tenant administrator is confined to the tenant context where the account exists. That enforced boundary prevents tenant A from enumerating or reading tenant B MTrees, even if the administrator knows the other tenant's path. Role-based MTree permissions granted to each tenant's admin accounts control access within a tenant, but permissions alone do not create a hard separation between tenants. Separate retention-lock policies applied to tenant MTrees protect data from deletion or alteration for a retention period; they do not restrict who may read another tenant's data. Network VLAN separation without Secure Multi-Tenancy contexts can isolate traffic segments, but it does not enforce tenant-level data and management isolation on the appliance. Exam caveat: When an audit question asks what technically prevents cross-tenant reading, choose enforced tenant context isolation rather than convention-based permission settings. Operational check: From a tenant A administrator session, attempt to view or access tenant B MTrees and network resources; the session should be denied because the context boundary excludes them.