Why does an EKS application not connect to new backend resources after migration?

DVA-C02 By islever Editorial Last updated Aug 6, 2026

Short answer

C The developer did not update the Docker image tag to a new version.

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?

The developer did not successfully create the new AWS account.
The developer added a new tag to the Docker image.
The developer did not update the Docker image tag to a new version. Correct Answer
The developer pushed the changes to a new Docker image tag.

Key Takeaways

This question tests understanding of how Kubernetes resolves container image tags — using a mutable tag like 'latest' without bumping the version causes K8s to reuse the old cached image instead of pulling the updated configuration.

When migrating an application to a new AWS account and EKS cluster, failing to update the Docker image tag to a new version causes Kubernetes to pull the cached old image, leaving the app connected to the old backend.

Common mistake: Candidates often choose B ('added a new tag to the Docker image') because it sounds related to tagging, but adding a tag does not force Kubernetes to pull a new image — only pushing a new versioned tag and updating the deployment manifest ensures a fresh pull.

Expert Analysis

Understanding the Core Issue

When a developer migrates an application to a new AWS account and a new Amazon EKS cluster, the application's configuration (e.g., backend endpoints, credentials) is typically baked into the Docker image or injected via environment variables at build time. If the developer rebuilds the image but does not update the image tag to a new version, Kubernetes will continue to use the previously cached image associated with the old tag.

Why Option C is Correct

Option C states: "The developer did not update the Docker image tag to a new version."

In Kubernetes, when a pod is deployed using an image tag (especially latest or any static tag), the kubelet on the node checks whether it already has an image with that tag locally. If it does, it does not pull a new image unless the imagePullPolicy is explicitly set to Always. This means the old image — still containing references to the old backend resources — continues to be used.

By not updating the tag to a new version, the developer effectively deployed the same image reference, and Kubernetes had no reason to pull the updated image containing the new backend configuration.

Why the Other Options Are Wrong

Option A: "The developer did not successfully create the new AWS account." — This is contradicted by the scenario, which states the developer successfully tested changes and deployed the pipeline.
Option B: "The developer added a new tag to the Docker image." — Adding a new tag to an existing image does not change the image content. Moreover, this option is vague and does not explain why the old backend is still referenced.
Option D: "The developer pushed the changes to a new Docker image tag." — If the developer had pushed to a new tag and updated the deployment manifest to reference that new tag, the application would have connected to the new backend. The problem described is that the app is still pointing to the old backend, which means the new tag was not properly referenced in the deployment.

Community Consensus

The community overwhelmingly agrees with Option C (100% vote). Commenters emphasize that in ECR and EKS workflows, image tag versioning is critical to ensuring Kubernetes pulls the correct, updated image. Without a new tag, the old cached image persists.

Official Reference

https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

When you see a scenario where a deployment succeeds but the application behavior hasn't changed, immediately think about image caching and tag immutability in Kubernetes. Always verify whether the image tag was updated and whether the deployment manifest references the new tag.

Community Votes

100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

KarBiswa 👍 3 Answered C

https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html#:~:text=You%20can%20identify%20an%20image%20with%20the%20repository%3Atag%20value%20or%20the%20image%20ID%20in%20the%20resulting%20command%20output
CrescentShared 👍 3 Answered C

B probably intended to say 'a wrong tag' but not as clear as C.
65703c1 👍 1 Answered C

C is the correct answer.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide