Testing and Deployment practice questions

ECR tag immutability makes every tag in a repository point at one image for good.

In a mutable repository a push with an existing tag silently moves the tag to the new image. Turning on tag immutability makes ECR reject such a push with ImageTagAlreadyExistsException, so a version tag always identifies the same image. Lifecycle rules and scanning manage or inspect images after they arrive, and denying PutImage stops all pushes.

1. Identify the problem: a tag was overwritten by a later push.
2. Look for a repository setting that rejects reused tags.
3. Recall that tag immutability returns ImageTagAlreadyExistsException.
4. Turn it on for the release repository.

Exam tip: Want a tag to mean one image forever? Turn on ECR tag immutability.

ECR tag immutability can be applied to most tags while excluding a named set of moving tags.

ECR supports exclusion filters on tag mutability. IMMUTABLE_WITH_EXCLUSION makes all tags immutable except those matching the wildcard filters, so version tags cannot be reused while latest and dev-* still move. Plain IMMUTABLE affects every tag, so moving latest fails; deleting tags before each push or splitting repositories would work but break the stated constraints (no new pipeline steps, same repository for existing task definitions). Lifecycle expiry is asynchronous and cannot free a tag in time.

1. List the requirements: version tags protected, latest and dev-* movable.
2. Note the constraints: one repository, no new pipeline steps.
3. Recall that plain IMMUTABLE applies to every tag in the repository.
4. Recall that exclusion filters exempt matching tags from immutability.
5. Choose IMMUTABLE_WITH_EXCLUSION with filters for the moving tags.

Exam tip: Immutable versions plus a moving latest in one repository: IMMUTABLE_WITH_EXCLUSION.

Unique, revision-based image tags give traceability and cheap rollback; moving tags give neither.

CodeBuild exposes the source revision in CODEBUILD_RESOLVED_SOURCE_VERSION (the commit ID for Git sources). Tagging images with it means the task definition revision names the exact commit, and every earlier image stays addressable, so rollback is a redeploy. Moving tags (latest, environment names) are fine as convenience pointers but cannot be the deployment reference. Pairing commit tags with tag immutability keeps them trustworthy.

1. Note both needs: trace a running task to a commit, roll back without rebuilding.
2. Reject tags that move between images, such as latest or an environment name.
3. Pick a tag that is unique per source revision.
4. Reference that tag in the task definition for each deployment.

Exam tip: Deploy by an immutable commit-ID tag; use moving tags only as pointers.

ECR lifecycle policies expire images automatically by tag status and by age or count.

A lifecycle policy rule selects images by tagStatus (untagged, tagged with a prefix or pattern, or any) and counts them by imageCountMoreThan or by age (sinceImagePushed with countUnit days). Untagged images older than 14 days are exactly what tagStatus untagged with sinceImagePushed 14 selects. ECR acts on matching images within 24 hours. Repository policies govern access, and replication copies images.

1. Identify the images: untagged ones.
2. Identify the condition: older than 14 days.
3. Map them to tagStatus untagged and countType sinceImagePushed.
4. Preview the rule, then apply it as the repository's lifecycle policy.

Exam tip: Clean up old images in ECR with a lifecycle policy: pick the tag status, then age or count.

ECR lifecycle rules are evaluated together but applied in priority order, and an image matched by a higher-priority rule's tag filter is protected from lower-priority rules.

ECR evaluates all rules, then applies them by priority (a lower number wins). An image that matches the tagging requirements of a rule cannot be expired by a lower-priority rule. So a priority 1 rule for prefix prod with imageCountMoreThan 10 expires only prod images beyond the newest 10, and the priority 2 any rule with sinceImagePushed 14 cannot touch prod images at all. A tagStatus any rule must have the lowest priority. Policies that rank the age rule first, leave feature tags unselected, or swap the count types fail the requirement.

1. Write down both requirements: keep the 10 newest prod images, age out the rest after 14 days.
2. Recall that a lower priority number wins and protects images its tag filter matches.
3. Put the prod prefix rule with imageCountMoreThan 10 first.
4. Add a final tagStatus any rule with sinceImagePushed 14 days.
5. Run the lifecycle policy preview before applying.

Exam tip: In ECR lifecycle policies, put specific tag rules first and the catch-all any rule last.

Multi-stage builds separate build-time dependencies from the runtime image.

A Dockerfile can define several FROM stages. The build stage installs compilers and produces the artifact, and the final stage starts from a minimal base and uses COPY --from=<stage> to take only the artifact. Layers from earlier stages are not part of the final image, so it is smaller and has fewer vulnerable packages. Deleting tools in a later RUN leaves them in earlier layers, and .dockerignore filters the build context, not installed packages.

1. Note what the runtime needs: only the compiled binary.
2. Recall that image layers are additive, so later deletes do not shrink earlier layers.
3. Split the Dockerfile into a build stage and a minimal runtime stage.
4. Copy the binary across with COPY --from.

Exam tip: Build in one stage, ship from another: multi-stage builds keep build tools out of the image.