What should the administrator do to prevent anyone from changing the retention settings after validation?
Exhibit
Container properties: Container name: auditlogs Immutable storage: enabled Immutability policy mode: Unlocked Retention period: 30 days Allow protected append writes: Yes Compliance note: the retention period has been tested and approved, and the organization wants the setting to be fixed so it cannot be shortened later.
Trap 1: Move the container to the Cool access tier to preserve the…
Changing the access tier to Cool affects storage costs and data retrieval latency, but it has no bearing on the immutability policy or its lock state. The Cool tier is a performance and pricing optimization for infrequently accessed data, and it does not alter the ability of an administrator to modify or unlock a retention policy. Since the compliance note requires that retention settings cannot be shortened or weakened over time, a tier change is irrelevant to that objective.
Trap 2: Create a blob snapshot every day so the retention settings cannot…
Creating daily blob snapshots preserves point-in-time versions of blob data, which can be useful for recovery, but snapshots do not lock or protect the container's immutable retention policy. An administrator with appropriate permissions can still edit or unlock an unlocked policy, and snapshots do not prevent that. Even if snapshots are immutable themselves, the underlying policy configuration remains mutable, so this action fails to meet the requirement of preventing future changes to retention settings.
Trap 3: Enable container public access so the audit logs are easier to…
Enabling public access on the container does not affect immutability enforcement; it simply removes authentication requirements for reads and writes. This would expose audit logs to anonymous users, increasing the risk of data tampering or deletion, and it does nothing to prevent an authorized user from editing or unlocking the retention policy. Immutability is a container-level setting controlled by policy state, not by network accessibility, so public access cannot satisfy the compliance requirement.
- A
Lock the immutability policy after validation is complete.
An unlocked immutability policy allows authorized changes during setup and testing. Once the retention period is validated, locking the policy prevents shortening or weakening retention settings later, which is exactly what the compliance note requires.
- B
Move the container to the Cool access tier to preserve the retention period.
Why it fails: Changing the access tier to Cool affects storage costs and data retrieval latency, but it has no bearing on the immutability policy or its lock state. The Cool tier is a performance and pricing optimization for infrequently accessed data, and it does not alter the ability of an administrator to modify or unlock a retention policy. Since the compliance note requires that retention settings cannot be shortened or weakened over time, a tier change is irrelevant to that objective.
- C
Create a blob snapshot every day so the retention settings cannot be edited.
Why it fails: Creating daily blob snapshots preserves point-in-time versions of blob data, which can be useful for recovery, but snapshots do not lock or protect the container's immutable retention policy. An administrator with appropriate permissions can still edit or unlock an unlocked policy, and snapshots do not prevent that. Even if snapshots are immutable themselves, the underlying policy configuration remains mutable, so this action fails to meet the requirement of preventing future changes to retention settings.
- D
Enable container public access so the audit logs are easier to verify.
Why it fails: Enabling public access on the container does not affect immutability enforcement; it simply removes authentication requirements for reads and writes. This would expose audit logs to anonymous users, increasing the risk of data tampering or deletion, and it does nothing to prevent an authorized user from editing or unlocking the retention policy. Immutability is a container-level setting controlled by policy state, not by network accessibility, so public access cannot satisfy the compliance requirement.