Sharing KMS Encrypted AMIs with AWS Organizations OUs

SAA-C03 By islever Editorial Last updated

Design secure access to AWS resources.

Short answer

AC Add the development team's OU ARN to the launch permission list and update the KMS key policy to allow the OU to use the key.

Question

A company uses AWS Organizations for its multi-account AWS setup. The security organizational unit (OU) of the company needs to share approved Amazon Machine Images (AMIs) with the development OU. The AMIs are created by using AWS Key Management Service (AWS KMS) encrypted snapshots. Which solution will meet these requirements? (Choose two.)
  1. Add the development team's OU Amazon Resource Name (ARN) to the launch permission list for the AMIs. Correct Answer
  2. Add the Organizations root Amazon Resource Name (ARN) to the launch permission list for the AMIs.
  3. Update the key policy to allow the development team's OU to use the AWS KMS keys that are used to decrypt the snapshots. Correct Answer
  4. Add the development team’s account Amazon Resource Name (ARN) to the launch permission list for the AMIs.
  5. Recreate the AWS KMS key. Add a key policy to allow the Organizations root Amazon Resource Name (ARN) to use the AWS KMS key.

Key Takeaways

The core trap is ignoring the encryption layer; granting EC2 launch permission alone fails because the target accounts cannot decrypt the underlying snapshots without explicit KMS key policy access.

This question explores the dual requirements for sharing Amazon Machine Images (AMIs) encrypted with AWS KMS across organizational units in AWS Organizations. It establishes that both launch permissions and key policies must be configured to enable access.

Common mistake: Candidates often select D (specific account ARN) instead of A (OU ARN), missing the efficiency of OU-level scoping, or they omit the KMS key policy update (C), resulting in a non-functional solution due to decryption failures.

Expert Analysis

Why the Answer Is Correct

To successfully share an AMI encrypted with AWS KMS to another Organizational Unit (OU), two distinct actions are required. First, you must grant launch permissions at the EC2 level; adding the development team's OU ARN to the launch permission list (Option A) allows any member of that OU to see and launch the image. Second, because the AMI relies on KMS-encrypted snapshots, the target accounts must have permission to use the specific KMS key to decrypt those snapshots. Updating the key policy to allow the development team's OU to use the key (Option C) provides this necessary cryptographic access.

Why the Other Options Are Wrong

Option B suggests adding the Organizations root ARN, which is overly permissive and violates least privilege principles compared to targeting the specific development OU. Option D targets a specific account ARN, which is inefficient if the entire OU needs access and ignores the simpler OU-based permission model supported by AWS. Option E involves recreating the KMS key, which is unnecessary operational overhead when existing keys can simply have their policies updated.

Community Comment Notes

Community consensus strongly supports AC, noting that Option A handles the 'launch' aspect while Option C handles the 'decrypt' aspect. Users highlighted that without C, the launch permission is useless because the instance cannot start without decrypting the volumes. Some initially debated CD but corrected themselves once they realized that sharing at the OU level (A) is more scalable than individual accounts (D).

Official Reference

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/share-amis-with-organizations-and-OUs.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

Always remember that encryption adds a dependency. If an resource is encrypted, check if the answer options address both the application-layer access (e.g., IAM, Launch Permissions) AND the data-layer access (e.g., KMS Key Policy). Missing one layer means the solution fails.

Frequently Asked Questions

Why isn't just adding the OU to launch permissions enough?

Launch permissions only allow the user to initiate the launch process. Since the AMI uses KMS-encrypted snapshots, the launching instance role/account must also have KMS Decrypt permissions to read the snapshot data.

Can I use specific account ARNs instead of OU ARNs?

Yes, but it is less scalable. Using OU ARNs (Options A and C) allows all current and future accounts in that OU to inherit the permissions automatically, whereas account ARNs require manual updates for each new account.

More SAA-C03 FAQ →

Community Votes

AC
100%

100% of anonymous learners picked answer AC. Votes are pick records left by other test-takers — they are not the verified answer.

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

  1. osmk 👍 5
    c=>https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/share-amis-with-organizations-and-OUs.html#allow-org-ou-to-use-key A-->https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/share-amis-with-organizations-and-OUs.html#share-amis-org-ou
  2. Mikado211 👍 4
    A : give users the right to launch C : give users the right to decrypt
  3. Scheldon 👍 2
    AnswerAC Option A will allow to run/lunch AMIs Option C will allow to decript AMIs which is necessery to run AMI.
  4. cjace 👍 1
    CD - Solution C: Update the Key Policy Why: The AMIs are created using KMS-encrypted snapshots, so the KMS keys must allow the development team's accounts to use these keys for decrypting the snapshots. How: Update the key policy of the KMS key to include permissions for the development OU or specific accounts within that OU. This will enable those accounts to use the KMS key for decrypting the snapshots associated with the AMIs. Solution D: Add the Development Team’s Account ARN to the Launch Permission List Why: To share the AMIs with the development accounts, you need to grant launch permissions to those accounts. This allows the specified accounts to use the shared AMIs to launch instances. How: Add the ARNs of the development team's accounts to the launch permission list of the AMIs. This can be done using the modify-image-attribute command in the AWS CLI, specifying the account IDs that should have launch permissions.
  5. LeonSauveterre 👍 1
    A - The security OU is explicitly allowing the development OU to use the AMI. B - OK but too broad, and not secure. C - Now they can use the encrypted snapshots. D - Would be too much trouble if there are many accounts. A is enough. E - Recreate the AWS KMS key? Uhm, why?
Show 2 more comments
  1. Andy_09 👍 13
    Changing to options AC
  2. Andy_09 👍 1
    Option CD

Reader comments & corrections

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

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

S3 Multi-Region Access Point and Replication Strategy

S-grade

Securing NLB with Security Groups for Minimal Change

S-grade

Most Cost-Effective 7-Year Retention for EBS Snapshots?

S-grade

AWS Forecast vs SageMaker for Time-Series Prediction

S-grade

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide