Six months after go-live, legal revises a retention rule, and ops proposes to 'just flip the setting' on retention-locked stores whose data was locked under the old terms. What governing constraint must the conversation respect?
Select an answer to reveal the explanation.
Short Explanation
A retention lock is like a contract clause on things already signed. Data locked under the old terms keeps those terms - flipping a switch doesn't rewrite what's already written, and pretending otherwise breaks compliance. Set the terms before your data arrives; after that, you migrate, you don't toggle.
Full Explanation
Immutability is trustworthy because lock terms materialize into stored objects at lock time - the system refuses to reinterpret yesterday's lock under today's settings, and that refusal is the feature. A legal revision splits the estate into cohorts: locked data keeps its recorded mode and period, new terms apply to objects locked after the change, and moving old data needs a deliberate re-lock exercise with its own plan and audit trail. A switch that retroactively re-evaluated locks would let whoever held it change yesterday's compliance state today - exactly what compliance mode denies - and the same objection defeats the metadata-pointer view: locks are persisted terms, not live views, or the non-erasability claim evaporates with every edit. Dismissing legal inverts the architecture's purpose: platform lock exists because application-layer retention is alterable from the application, and regulators examine the copies themselves. Exam caveat: extending a period is the gentle direction; shortening periods or converting modes over existing data is the drastic path - model the old-versus-new cohorts and document before touching settings. Operational check: map every locked store's current terms against the revised requirement, split the estate into old-term and new-term data, and produce the migration plan for the gap before changing anything.