Proposed flow for this scenario
- Exact object or version
- S3 action result
- Stored encryption/key metadata
- Key Region and lifecycle
- Required key-use authorization
- Result or separate repair
This flow describes a design to evaluate. Follow the supported console workflow below to practice with local resources. Its scope appears with the controls; no cloud resources are provisioned.
Decision checkpoints
| Choice | Fits when | Watch for |
|---|---|---|
| S3 permission repair | The requested object/version action is denied. | Adding only KMS use permission to bypass S3 access. |
| Key-use repair | S3 passes but the selected customer-managed key decision fails. | Changing bucket defaults and assuming old versions use the new key. |
Treat the version as the encryption reference
A synthetic LetX bucket stores a version configured with one customer-managed key, then changes its default to another. A later read of the old revision still refers to its stored key metadata. The default is a write choice, not a rewrite of retained history.
Record bucket location, exact version and key ARN before editing policies. A successful new-object read under the new key cannot prove that the recovery version under the old key is readable.
S3 and KMS ask different authorization questions
The caller needs the appropriate S3 object or version action and the required key use. For a modeled read this includes Decrypt; a selected write needs its data-key permission. Copy can involve source reading and destination writing under different key decisions.
Inspect the key policy, identity permission and key state separately. An explicit deny, disabled key or pending deletion can explain failure despite S3 access. A policy grant does not make a disabled key usable. Match the key to the bucket’s actual Region rather than the global bucket-list view.
Reproduce the selected local denial
Create a synthetic customer-managed key and a bucket encryption configuration using it. Upload a fixed synthetic text revision, then test a read under an identity with the selected S3 action but without its key permission. Inspect which boundary fails.
Repair the narrow key-use authorization and repeat the exact version read. Disable the key and compare that outcome with a permission denial. This model evaluates metadata and selected policy/lifecycle decisions; browser payloads remain plaintext synthetic learning data.
Changed scenario and recovery consequence
Question: the old key is unavailable but the bucket now defaults to a working new key. Does that restore reads of every old version? No. Recover access to the relevant key or use an appropriate already readable recovery source. The bucket default alone cannot create missing decryption capability.
The local model excludes actual cryptography, AWS-managed S3 keys and Bucket Key behavior. Use the S3 and KMS console links below to compare stored key references and selected key-use decisions, not to test encryption. In a real account, review service context, cross-account requirements and applicable key policies before changing access.
Practice the supported console workflow
Sources and scope
Reviewed against these official references. The model’s supported scope appears alongside its controls.
How we review explanations