The design requires encryption at rest and cloud tiering, and the installation checklist includes a step confirming the order actually includes those features. When should that entitlement check happen, and why?
Select an answer to reveal the explanation.
Short Explanation
Discovering a missing license is like arriving on a job site without the permit—it may be somebody else's mistake, but it's still your day that's ruined. Confirm the order carries encryption and cloud tiering before you travel. The checklist step exists so procurement gaps become change orders, not change-control incidents.
Full Explanation
DD OS capabilities such as encryption at rest and Data Domain Cloud Tier are entitlement-driven: the software is present, but usable only when the matching license is applied, so the checklist treats 'does the order contain what the design requires' as a pre-deployment verification. Confirming entitlements before travel lets procurement fix a gap on ordinary lead times instead of under install-day pressure. Testing activation on site fails by concept: discovery lands after racking and bring-up, when every delay is visible to the customer, and a console refusal cannot even tell a lost key from an un-ordered one. Waiting until backups run fails because tiering and encryption shape the storage unit design, retention and replication from day one—adding them after a live system exists is a reconfiguration project, not a checkbox. Declaring entitlement verification 'sales work the checklist must not duplicate' fails where handoffs always fail: without deployment-side verification, a sales omission surfaces at the worst moment. Exam caveat: the checklist step confirms entitlements exist; applying license keys to the specific system is a configuration-phase action. Operational check: reconcile the design's feature list against order line items, record license key references on the checklist, and confirm key delivery before scheduling bring-up.