Hardened AMIs and container images (EC2 Image Builder): SCS-C03 study notes and practice questions
What to know about Hardened AMIs and container images (EC2 Image Builder) for the SCS-C03 exam, from the Infrastructure Security domain (18% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe a fleet that drifts from its security baseline, such as instances launched from outdated or unapproved machine images, or servers patched by hand. You choose the pipeline and the enforcement that make the approved image the only one that runs.
Build the image as code
An Image Builder pipeline produces a new image version on a schedule or when a component changes. Scheduled runs keep the base image patched without manual work.
A recipe names a base image and an ordered list of components. A component is a document of build and test steps, such as installing an agent, applying a hardening baseline or running a compliance check.
The infrastructure configuration sets the subnet, security group, instance profile and logging for the build instances. Build in private subnets with controlled egress or VPC endpoints.
The distribution configuration copies the finished AMI to other accounts and Regions, or pushes container images to Amazon ECR.
Lifecycle policies retire old image versions, so an outdated image stops being a launch option.
The allowed AMIs setting limits which images an account can launch. An Organizations declarative policy applies the setting across accounts. See the allowed AMIs guide.
Declarative policies can also require IMDSv2 by default and block public sharing of AMIs and EBS snapshots.
Secrets stay out of the image. Fetch them at boot from Secrets Manager or Systems Manager Parameter Store with the instance role.
How to choose
Scenario wording
Pick
Patch the golden image every month without manual work
Scheduled Image Builder pipeline
Apply a repeatable, tested set of hardening steps
Image Builder components
Only approved AMIs may launch in any account
Allowed AMIs setting through an Organizations declarative policy
Ship a hardened container image to ECR
Image Builder container pipeline, with ECR scanning
Retire images older than a set age
Image Builder lifecycle policy
Update running servers in place
Systems Manager Patch Manager, not a new image
Common traps
A hand-built golden AMI with no pipeline behind it, so it falls behind the next patch.
Baking credentials or keys into the AMI. Every instance launched from it carries them.
Building images in a public subnet with broad inbound access.
Leaving old AMIs shared after a vulnerability fix. Copies stay launchable until you revoke or retire them.
Relying on a runbook to tell teams which AMI to use, when the allowed AMIs setting can enforce it.
A university IT department builds the server images for its teaching and research systems. Each image must be hardened to the CIS benchmark, tested before it is released, and shared only with the university's own AWS accounts. The department has about 40 accounts in one AWS Organizations organization.
The image must be rebuilt every week without anyone running a manual step, and no image may be public. The security team also wants the hardening steps written as code that reviewers can read.
Which TWO actions should the department take to meet these requirements? (Choose two.)
Choose two answers.
AA. Launch an instance each week, run the CIS hardening script by hand, test it by hand, and then create the image from the console.
BB. Create an EC2 Image Builder recipe that starts from the approved base image and applies a hardening component written for the CIS benchmark, then add a test component that checks the hardening.
CC. Set the AMI to public so that every department can launch it without asking the platform team, and rely on the image owner to keep it hardened.
DD. Harden the servers with user data scripts at launch time, so that every instance is configured on first boot and no image needs to be tested.
EE. Set the pipeline distribution settings to share each new image with the organization ARN only, and set the pipeline schedule to run once a week.
Show the answer and explanation
Answers: B, E
A. Wrong: This works once, but it is a manual step every week, which the requirement rules out. Manual runs also make the hardening hard to reproduce or review.
B. Right: Correct. Image Builder components are written as code and run in order, so the hardening and the tests happen during the build. A failed test stops the pipeline, so an unhardened image is never released. Learn more: What is EC2 Image Builder? (opens in a new tab)
C. Wrong: A public image breaks the rule that the images are shared only with the university accounts. Relying on an owner to keep it hardened also gives no test before release.
D. Wrong: Hardening at launch takes time, and the image itself is never tested before release. The requirement is a tested image that is rebuilt weekly, which first-boot scripts do not provide.
E. Right: Correct. Distribution settings can share an AMI with an organization or OU without making it public, and a pipeline schedule runs the build each week with no manual step. Together they meet the release and sharing rules. Learn more: Manage distribution settings (opens in a new tab)
Explanation
An Image Builder pipeline bakes the CIS hardening into an image through versioned components, tests it, and stops on failure. Distribution settings share the result with the organization only, and a schedule rebuilds it weekly. Manual builds, a public AMI and first-boot scripts each fail a stated requirement.
Want more on Hardened AMIs and container images (EC2 Image Builder)? The 5 full-length practice sets have 5 more Hardened AMIs and container images (EC2 Image Builder) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Hardened AMIs and container images (EC2 Image Builder)