DVA-C02 · Question #272
A developer is migrating an application to Amazon Elastic Kubernetes Service (Amazon EKS). The developer migrates the application to Amazon Elastic Container Registry (Amazon ECR) with an EKS…
The correct answer is C. The developer did not update the Docker image tag to a new version. When a Kubernetes deployment pulls a Docker image, it uses the image tag specified in the pod spec. If the tag (e.g., latest) was not changed to a new version, the cluster continues running or pulling the previously cached image, ignoring the updated image pushed to ECR.
Question
A developer is migrating an application to Amazon Elastic Kubernetes Service (Amazon EKS). The developer migrates the application to Amazon Elastic Container Registry (Amazon ECR) with an EKS cluster. As part of the application migration to a new backend, the developer creates a new AWS account. The developer makes configuration changes to the application to point the application to the new AWS account and to use new backend resources. The developer successfully tests the changes within the application by deploying the pipeline. The Docker image build and the pipeline deployment are successful, but the application is still connecting to the old backend. The developer finds that the application's configuration is still referencing the original EKS cluster and not referencing the new backend resources. Which reason can explain why the application is not connecting to the new resources?
Options
- AThe developer did not successfully create the new AWS account.
- BThe developer added a new tag to the Docker image.
- CThe developer did not update the Docker image tag to a new version.
- DThe developer pushed the changes to a new Docker image tag.
How the community answered
(60 responses)- A23% (14)
- B7% (4)
- C55% (33)
- D15% (9)
Why each option
When a Kubernetes deployment pulls a Docker image, it uses the image tag specified in the pod spec. If the tag (e.g., `latest`) was not changed to a new version, the cluster continues running or pulling the previously cached image, ignoring the updated image pushed to ECR.
The question states the developer successfully created the new AWS account and the pipeline deployment succeeded, ruling out account creation failure as the cause.
Adding a new tag to a Docker image does not cause a running deployment to stop using a previously deployed image; it would only matter if the deployment manifest was updated to reference that new tag.
Kubernetes determines which image to run based on the image tag in the deployment manifest and the `imagePullPolicy`. If the developer pushed updated code under the same tag without incrementing the tag (e.g., keeping `latest` with a `IfNotPresent` pull policy), the existing nodes continue using the already-pulled old image, so the application keeps connecting to the old backend.
Pushing changes to a new tag would actually be the correct remediation, not the cause of the problem; the issue is that a new tag was not used, not that it was.
Concept tested: Docker image tag versioning and Kubernetes image pull behavior
Source: https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy
Community Discussion
No community discussion yet for this question.