Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Site Reliability Engineer (SRE).
For SOA-C02 candidates, the confusion often lies in cross-account encrypted AMI sharing and KMS key permissions. In production, this is about knowing exactly how AWS KMS key policies and CloudFormation interplay across accounts to enable encrypted AMI use. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
ContosoTech is expanding its cloud infrastructure by deploying resources using AWS CloudFormation in multiple AWS accounts under their organization. A Site Reliability Engineer has created an AWS CloudFormation template that launches an Amazon EC2 instance from an encrypted Amazon Machine Image (AMI) in their primary account. To automate deployments in a secondary AWS account, this encrypted AMI is copied there. However, when the engineer attempts to launch the CloudFormation stack in the secondary account utilizing the copied encrypted AMI, the stack creation fails.
The Requirement: #
Identify the correct approach to ensure the CloudFormation stack can successfully launch an EC2 instance using the encrypted AMI in the secondary account.
The Options #
- A) Modify the AMI’s launch permissions to make the AMI public.
- B) Deregister the AMI in the primary account.
- C) Re-encrypt the copied AMI in the secondary account using a KMS key from the secondary account.
- D) Update the CloudFormation template to use the AMI ID from the secondary account.
Google adsense #
leave a comment:
Correct Answer #
D
Quick Insight: The SysOps Imperative #
- CloudFormation stacks must refer to the correct AMI ID valid in their target account. Cross-account AMIs must be referenced explicitly by the target account’s AMI ID after copy.
- Encrypted AMIs with KMS keys require proper key access and correct AMI ID references per account for successful launches.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option D
The Winning Logic #
When an encrypted AMI is copied from one AWS account to another, it obtains a new AMI ID in the destination account. Launching an EC2 instance via CloudFormation requires referencing this new AMI ID valid in the target account. If the original AMI ID from the source account is used, stack creation will fail because that AMI ID does not exist in the secondary account.
Additionally, encrypted AMIs use customer-managed KMS keys which do not automatically grant access across accounts. However, the question scenario focuses on launch failure due to reference mismatch. Updating the CloudFormation template to use the correct, copied AMI ID in the secondary account addresses the fundamental cause.
- From a SysOps perspective, this manifests as a
Client.InvalidAMIID.NotFounderror or similar during stack creation.
The Trap (Distractor Analysis): #
-
Why not A?
Making an AMI public removes encryption access control but is a bad practice for sensitive data and often not feasible for encrypted AMIs. Also, being public does not solve cross-account KMS access or AMI ID mismatch. -
Why not B?
Deregistering the AMI in the source account doesn’t help in the secondary account and can cause disruption if still in use. -
Why not C?
Re-encrypting the AMI with the destination account’s KMS key is a valid step for some processes, but it typically requires creating a new AMI (via copy with new key) and updating references accordingly. The question highlights the fix for launch failure which is referencing the correct AMI ID. Simply re-encrypting without updating the template won’t fix the launch error.
The Technical Blueprint #
# Example AWS CLI command to identify the copied AMI's ID in the target account:
aws ec2 describe-images --owners self --filters "Name=name,Values=encrypted-ami-copy" --query "Images[0].ImageId" --region us-east-1
# Update CloudFormation stack parameter or template with the new ImageId:
# Example snippet in a CloudFormation template parameter:
"ImageId": "ami-0abcd1234efgh5678" # Copied AMI ID in destination account
The Comparative Analysis #
| Option | Operational Overhead | Automation Level | Impact |
|---|---|---|---|
| A | Low (single toggle, but risky) | Low (manual permission change) | High risk of data exposure, fails encrypted AMI best practices |
| B | High (deregistering AMI) | Low (manual operation) | Potential service disruption; no benefit for cross-account launch |
| C | Medium (copy & re-encrypt AMI) | Medium (requires image workflow automation) | May fix permissions but needs updated references; incomplete alone |
| D | Low (update template parameter) | High (CI/CD-friendly best practice) | Resolves launch error; correct account scoping |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always use the destination account’s AMI ID when launching a copied AMI, especially encrypted ones.”
Real World #
“In real deployments, you must coordinate with Security to ensure the destination account’s KMS key grants decrypt permissions to users/roles launching the EC2 instance. Sometimes automation scripts are used to copy AMIs and output the new AMI ID automatically into CloudFormation pipelines.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS SOA-C02 exam.