How to Launch a Cross-Account Encrypted AMI from CloudFormation?

SOA-C03 By islever Editorial Last updated Oct 20, 2026

Provision and maintain cloud resources. Implement strategies to protect data and infrastructure.

Short answer

A Update the CloudFormation template with the destination account's AMI ID and allow the second account to use the KMS key in its key policy.

Question

A CloudOps engineer has an AWS CloudFormation template that deploys an encrypted Amazon Machine Image (AMI). The AMI is encrypted with an AWS KMS asymmetric key.
The CloudFormation template needs to be used in a second account. The CloudOps engineer copies the encrypted AMI to the second account. The new CloudFormation stack in the second account fails to launch.
Which action should the CloudOps engineer take to resolve this issue?

Update the CloudFormation template with the ID of the AMI in the second account. In the KMS key policy, allow the second account to access the KMS key. Correct Answer
Convert the KMS key to a symmetric key. Copy the AMI to the second account. Deregister the AMI in the initial account. Register the AMI in the second account.
Export the KMS key from the initial account. Import the KMS key into the second account. Update the CloudFormation template with the KMS key's new Amazon Resource Name (ARN).
Export the KMS key from the initial account. Change the AMI permissions to mark the AMI as public. Import the KMS key into the second account.

Key Takeaways

The exam tests cross-account encrypted AMI sharing and KMS key policy permissions; the trap is assuming a KMS key can be converted, exported, or imported between accounts.

Copying an encrypted AMI into a second account requires updating CloudFormation to the destination AMI ID and granting that account KMS key access; this page confirms option A resolves the launch failure.

Common mistake: Many learners choose B because the stem mentions an asymmetric key, but AWS KMS key spec is immutable and converting the key is not an available operation.

Expert Analysis

Why the Answer Is Correct

A copied AMI is a new object in the destination account, so CloudFormation must reference the destination AMI ID rather than the source-account ID. The second account also needs permission to use the KMS key that protects the AMI snapshots, because EC2 must decrypt those snapshots when the stack launches an instance. Updating the template and adding the second account to the KMS key policy fixes both the identifier and authorization gaps. Although the stem calls the key asymmetric, the only option that follows AWS's cross-account sharing model is A; the other choices rely on KMS operations that are not supported.

Why the Other Options Are Wrong

Option B proposes converting an asymmetric KMS key to a symmetric key, but a KMS key's spec is fixed at creation and cannot be changed; deregistering and re-registering the AMI also does not fix cross-account KMS authorization. Option C requires exporting the KMS key from one account and importing it into another, which AWS KMS does not allow for standard customer managed keys. Option D combines the impossible key export/import step with making an encrypted AMI public, and encrypted AMIs cannot be made public. None of these options grants the destination account the KMS permission needed to launch from the copied AMI.

Community Comment Notes

Bad_Mat's comment endorses option A and describes the same two-part remediation: update CloudFormation with the destination AMI ID and grant the second account KMS key access. The comment explicitly says to "Update the CloudFormation template with the ID of the AMI in the second account" and allow the second account to use the KMS key. No learner in the thread argues for converting, exporting, or making the AMI public, so the visible discussion is consistent with the analysis above.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

For cross-account encrypted AMI questions, separate the destination AMI ID from the KMS authorization requirement. Eliminate any answer that converts, exports, imports, or publicly shares an encrypted AMI, because those are not valid KMS or EC2 operations.

Frequently Asked Questions

Why is exporting the KMS key to the second account not the fix?

AWS KMS does not let you export standard customer managed key material for import into another account; cross-account use is granted through the key policy, not by moving the key.

Why can't the engineer make the encrypted AMI public instead?

Encrypted AMIs cannot be made public, and public sharing would not give the second account the KMS decrypt permissions required to launch an instance.

More SOA-C03 FAQ →

Discussion 1 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 1

Bad_Mat 👍 1 Answered A

The correct action is A. Update the CloudFormation template with the ID of the AMI in the second account, and update the KMS key policy to allow the second account access to use the KMS key

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Practice All SOA-C03 Questions

Access 100 questions with complete answers and detailed explanations.

View Full SOA-C03 Practice Test →

← Back to SOA-C03 Study Guide