During post-deployment validation, you apply backup retention and replication policies. One week later, the application owner reports that snapshots were silently missed for several days. No storage-team alert was generated. What should the applied policies have included?
Select an answer to reveal the explanation.
Short Explanation
Think of a policy without alerts like a smoke detector with no battery: it can still do its job, but nobody hears you when it fails. If snapshots, tiering, or replication go quiet, your monitoring should scream first, not the app owner. That’s why failure alerting belongs in the policy, not just in a report later.
Full Explanation
Applying a Data Domain policy is not complete until its failure states are observable. Snapshots, tiering, and replication can fail or stall without changing the visible success of a backup job, so policy design should include event-driven alerting for missed snapshots, stalled tiering, and replication failures routed to the monitoring channel configured during bring-up. This creates proactive detection: the platform, not the application owner, surfaces the gap. A retention exception that records missed snapshots as successful is wrong because it changes accounting without making the failure visible or actionable, masking data-protection gaps. A weekly summary report is too slow for a silent failure that may require immediate remediation, and it shifts detection away from automated monitoring. Increasing snapshot frequency does not fix missed executions or stalled data movement; it can increase load while leaving the same blind spot. Exam caveat: on the exam, choose the answer that ties policy execution to monitoring/alerting rather than post-hoc reporting or schedule tuning. Operational check: after creating or modifying a policy, deliberately cause a safe test failure and confirm the monitoring destination receives a missed snapshot, tiering, or replication alert.