A hosting admin wants tenant admins to change their own snapshot schedules without opening tickets, while preserving isolation. What should be configured?
Select an answer to reveal the explanation.
Short Explanation
Think of tenant policy delegation like giving your tenant admin a key to their own apartment, not the whole building. They can set snapshot schedules inside their guardrails, while isolation stays intact. The trap is thinking you've got to hand over global controls or shared access to make self-service work.
Full Explanation
Tenant policy delegation lets a hosting administrator authorize tenant administrators to manage selected configuration objects, such as snapshot schedules, only within their assigned tenant. The hosting admin still defines the outer boundary: which policies, retention settings, and scheduling parameters are available, and the tenant admin cannot reach other tenants or alter platform-wide controls. This preserves Secure Multi-Tenancy isolation while reducing ticket traffic. Global retention lock override is wrong because retention lock is a compliance control intended to prevent changes to protected data, not a mechanism for routine tenant scheduling. Shared management network access is wrong because exposing management networking across tenants breaks isolation and does not itself grant policy authority. Cross-tenant replication context is wrong because replication contexts move protected data between systems or tenants for DR or migration, not for delegated policy editing. Exam caveat: exam questions may describe role assignment, policy scope, or guardrail configuration, but the concept is always tenant-scoped authority rather than platform-wide administration. Operational check: confirm a tenant admin can create or modify only policies visible inside their own tenant and cannot list or alter another tenant's policy set.