SCS-C02 Data Protection Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Export the snapshot as an unencrypted snapshot and share it.

  Why it's wrong here

  Exporting an encrypted snapshot directly to an unencrypted format is not supported by the AWS snapshot export API; you cannot simply change the encryption attribute during export. To get an unencrypted snapshot, you would need to copy it, but AWS explicitly forbids creating an unencrypted copy of an encrypted snapshot. Even if you managed to produce one, exporting a raw file does not create a shareable AMI that the target account can directly launch from. Therefore, this approach fails both at the encryption boundary and at the AMI delivery mechanism.

• ✗

  Share the AMI and have the target account create a new KMS key to encrypt the snapshot.

  Why it's wrong here

  Having the target account create a new KMS key is futile because the snapshot's encryption is tied to the source account's KMS key, not any key created later in the target account. The target cannot 're-encrypt' the snapshot into its own key without first possessing a plaintext copy, which requires decrypting with the original key. Access to the original key must be granted via a cross-account key policy before the target can use the snapshot at all. A brand-new key offers no decryption capability for the incoming encrypted data.

• ✗

  Share only the AMI; the snapshot permissions are inherited from the AMI.

  Why it's wrong here

  Sharing an AMI does not automatically share the underlying EBS snapshots; snapshot permissions are managed separately through ModifySnapshotAttribute and are not inherited. Even if the AMI were shared, the target account would still receive 'Not authorized' when launching because it cannot read the snapshots backing the AMI's block device mappings. For encrypted snapshots, the situation is worse—even snapshot sharing alone is insufficient because the target must also be granted kms:Decrypt on the KMS key. Thus, relying on implicit inheritance is a fundamental misunderstanding of the resource-sharing model.

• ✓

  Share the AMI, share the snapshot, and grant the target account decrypt permissions on the KMS key.

  Why this is correct

  This is correct because launching a cross-account encrypted AMI requires three separate sharing actions: the AMI itself via ModifyImageAttribute, each backing snapshot via ModifySnapshotAttribute, and the KMS key via a key policy update that grants the target account decrypt permissions. The target account's IAM roles or users must be able to call kms:Decrypt (and kms:CreateGrant for the launch to create a grant) on the source CMK. After these steps, the target can launch the instance and optionally re-encrypt the resulting volumes with its own KMS key. This layered authorization is the standard, supported pattern for sharing encrypted AMIs across accounts.

Go deeper

Related to this question