ECR for container image registry in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

ECR Image Pull Behavior

You have an Amazon ECR repository with an image tagged as latest. If you pull the image using the latest tag multiple times without pushing a new image, what will happen?

A Each pull downloads the image again, increasing data transfer costs.

B ECR automatically updates the image tag to a new version on each pull.

C Pulling the image with the same tag multiple times causes the image to be deleted from the repository.

D The image is cached locally after the first pull, so subsequent pulls use the cached image unless forced to refresh.

💡 Hint

Think about how Docker clients handle image tags and caching.

Docker clients cache images locally after the first pull. Pulling the same tag again uses the cached image unless you explicitly force a refresh. This behavior reduces data transfer and speeds up deployments.

❓ security

intermediate

ECR Repository Access Control

You want to restrict access to an ECR repository so that only a specific IAM user can push images, but multiple users can pull images. Which IAM policy setup achieves this?

A Attach a policy denying all actions to all users except the specific user.

B Attach a policy allowing <code>ecr:PutImage</code> to all users and <code>ecr:GetDownloadUrlForLayer</code> only to the specific user.

C Attach a policy to the repository allowing <code>ecr:BatchCheckLayerAvailability</code> and <code>ecr:GetDownloadUrlForLayer</code> to all users, and <code>ecr:PutImage</code> only to the specific user.

D Attach a policy allowing <code>ecr:* </code> to all users.

💡 Hint

Consider which actions are needed for pushing versus pulling images.

Pushing images requires ecr:PutImage permission, while pulling requires read permissions like ecr:BatchCheckLayerAvailability and ecr:GetDownloadUrlForLayer. Restricting PutImage to one user and allowing read actions to others enforces the desired access control.

❓ Architecture

advanced

ECR Cross-Region Replication Setup

You want to replicate container images automatically from an ECR repository in us-east-1 to another repository in eu-west-1. Which configuration is required to enable this cross-region replication?

A Enable cross-region replication in the source repository and specify the destination region and repository ARN. Ensure the replication role has permissions in both regions.

B Manually push images to the destination repository after pulling from the source repository.

C Create a Lambda function that copies images between regions on a schedule.

D Enable versioning on the source repository to automatically replicate images.

💡 Hint

Think about built-in ECR features for replication.

ECR supports cross-region replication by enabling it on the source repository and specifying destination repositories. A replication IAM role with permissions in both regions is required to allow ECR to replicate images automatically.

✅ Best Practice

advanced

ECR Image Tagging Strategy

Which image tagging strategy helps avoid overwriting important images and supports easy rollback in ECR?

A Use random tags generated at push time without versioning.

B Use immutable tags and include version numbers or commit hashes in tags.

C Always use the <code>latest</code> tag and overwrite it with each new image push.

D Delete old images immediately after pushing new ones to save space.

💡 Hint

Consider how to keep track of image versions safely.

Using immutable tags with version numbers or commit hashes prevents accidental overwrites and allows you to roll back to previous versions easily. Overwriting latest can cause confusion and deployment issues.

🧠 Conceptual

expert

ECR Lifecycle Policy Behavior

An ECR lifecycle policy is configured to expire untagged images older than 30 days and images tagged with dev older than 7 days. After 40 days, which images will be deleted?

A All untagged images older than 30 days and all images tagged <code>dev</code> older than 7 days will be deleted.

B Only images tagged <code>dev</code> older than 7 days will be deleted; untagged images are kept indefinitely.

C Only untagged images older than 30 days will be deleted; tagged images are never deleted.

D No images will be deleted because lifecycle policies do not apply automatically.

💡 Hint

Think about how lifecycle policies apply to different tag filters and image ages.

ECR lifecycle policies apply rules independently. Untagged images older than 30 days and images tagged dev older than 7 days both match their respective rules and will be deleted after 40 days.