Abort the Glacier vault lock, fix the policy, and initiate the lock again
Short answer
A Abort the vault lock, fix the policy, and initiate the lock again during the waiting period.
Question
Key Takeaways
During the Vault Lock waiting period the policy is not yet locked, so abort-vault-lock cancels it cheaply; you then fix and re-initiate. Copying 10 TB to a new S3 bucket and recreating the vault (B) is far more expensive and slow. Options C/D that just 'update the policy' while a lock is pending do not apply the corrected policy correctly. A is the cost-effective path.
A Glacier Vault Lock was initiated 12 hours ago but has a typo allowing unintended access. Vault Lock has a lock-in waiting period before the policy becomes immutable; while still in that window, the most cost-effective fix is to call abort-vault-lock, correct the policy, and initiate-vault-lock again—no data copy or new vault needed.
Common mistake: Copying the vault data to a new bucket and recreating the vault (B)—10 TB of egress/copy is costly and slow versus simply aborting the pending lock. Assuming you can edit the policy in place during the waiting period (C/D)—the initiate step must be re-run after correction; A is the proper sequence.
Expert Analysis
Why the Answer Is Correct
S3 Glacier Vault Lock enforces a lock-in waiting period before a policy becomes immutable. Because the lock was initiated only 12 hours ago, it is still within that window, so abort-vault-lock cancels the pending lock at no data cost; you correct the policy and call initiate-vault-lock again. This is the most cost-effective correction.
Why the Other Options Are Wrong
B copies 10 TB of data to a new bucket and recreates the vault, which is expensive and slow compared with aborting the pending lock. C and D try to update the policy while a lock is pending without re-running the proper abort/revise/initiate sequence, so the typo is not cleanly fixed. A is correct.
Community Comment Notes
Community voted A (100). Commenters explained the Vault Lock waiting period lets you abort before lock-in, then update and re-initiate—far cheaper than copying 10 TB to a new vault. A confirmed.
Official Reference
https://docs.aws.amazon.com/amazonglacier/latest/dev/vault-lock.html
This link opens the official vendor documentation in a new tab.
Community Votes
100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 3 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 3
-
IPLogic 👍 1 Answered AThe most cost-effective way to correct the error is: A. Call the abort-vault-lock operation. Update the policy. Call the initiate-vault-lock operation again. Since the vault lock policy is still in the “InProgress” state, you can abort the lock operation, correct the typo in the policy, and then initiate the vault lock operation again. This approach avoids the need to move large amounts of data or create new vaults, making it the most efficient solution.
-
Pat9595 👍 1 Answered AA. Call the abort-vault-lock operation. Update the policy. Call the initiate-vault-lock operation again. ✅ Why? The S3 Glacier Vault Lock feature has a lock-in period before the policy becomes immutable. The "initiate-vault-lock" operation starts a 24-hour window where the policy can still be modified or aborted. Since the vault lock was initiated only 12 hours ago, you can still abort it, correct the policy, and restart the process without extra cost.
-
Bad_Mat 👍 1The answer is A
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.