Keep container releases in a trusted registry — ECR and Container images

Your goal

Plan how a container image is stored, identified, and checked before use.

Why this matters

A team wants to deploy the exact container it tested. You will publish it to a registry, identify the release reliably, and decide what to do when an image scan reports a problem.

Words you will use

An image packages a container app. A registry stores images. A tag is a name attached to an image. A digest identifies the image content.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Store the built package

The app’s container image exists only on a developer’s machine. Deployment workers need a controlled place to retrieve it.

What role does ECR serve?

An image registry with access controls.

ECR stores and distributes container images. Configure appropriate push and pull permissions. Storing an image is separate from running it; a compute service still needs to deploy and execute the workload.

The image has a controlled distribution point.

Build image → authorized push → repository

2. Identify what was tested

A tag called latest can point to a different image tomorrow. The team wants a release record that identifies the tested contents.

What provides an exact content identity?

The image digest, with a clear release tagging policy.

A digest identifies image content. Use a deliberate tag immutability and release policy where appropriate, and record the digest deployed. Clear identity helps reproduce a release and understand a rollback.

The deployed image can be matched to the tested image.

Tested image digest → release record → deployment reference

3. Act on scan findings

An image scan reports a vulnerable package. The team needs to decide how to fix and verify it rather than assuming a scan repaired the package.

What should the workflow do?

Assess the finding, rebuild with fixes, retest, and deploy the new image.

Scanning reports possible issues; it does not automatically rewrite an image or update a running service. Review impact, update the source or dependencies, and produce a new verified release with a traceable identity.

The finding leads to a new checked image when needed.

Finding → fix → rebuild and test → new digest → deploy

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.