Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For AWS DVA-C02 candidates, confusion often arises around container image versioning and application configuration management during migrations. In production, this is about tightly coupling your CI/CD pipeline, Docker image tagging, and Kubernetes manifest updates so your application points to the right backend. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
NebulaApps Inc., a startup specializing in analytics software, is migrating their microservices application to Amazon Elastic Kubernetes Service (EKS). As part of the migration, the development team moves their Docker images to Amazon Elastic Container Registry (ECR) in a newly created AWS account dedicated to production workloads.
The developers update the application’s backend configuration to point to new services within this new account and push the updated code and Docker images through their CI/CD pipeline. Pipeline runs complete successfully, and Docker image builds have no errors.
However, after deploying the new manifests to the EKS cluster, the live application still interacts with old backend resources instead of the new ones in the separate AWS account.
The Requirement: #
Identify why the application is still connecting to old backend resources despite successful deployment and updated Docker image builds.
The Options #
- A) The developers failed to create the new AWS account properly.
- B) The developers added a new tag to the Docker image.
- C) The developers did not update the Docker image tag to a new version.
- D) The developers pushed the changes to a new Docker image tag.
Google adsense #
leave a comment:
Correct Answer #
C
Quick Insight: The Developer Imperative #
When working with containerized applications on EKS, the key is ensuring your Kubernetes manifests reference the exact new Docker image tag you intend to deploy. Neglecting to update the image tag causes the cluster to pull the old image, which still contains references to the legacy backend.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option C
The Winning Logic #
The crux of this scenario centers on Docker image versioning combined with Kubernetes deployment semantics. While the new AWS account exists, and new backend resources have been created, the deployed application pods are still pulling an outdated Docker image. This happens because the Kubernetes deployment manifests or Helm charts were not updated to reference the new image tag.
- Kubernetes uses the image tag to determine which container image version to pull.
- If the deployment YAML still points to
:latestor an old tag (e.g.,v1.0), EKS continues running the old application container referencing the legacy backend. - Even if a new image with backend configuration changes was pushed, without updating the manifest to use that new tag (e.g.,
v1.1), the cluster won’t pull or run it.
This is a very common pitfall in EKS/ECR migration workflows: forgetting to update manifest references after pushing new container images.
The Trap (Distractor Analysis): #
-
Why not A?
The new AWS account creation is a prerequisite, but the scenario states the account exists and pipeline/builds succeed, so this is not the cause. -
Why not B?
Adding a new tag to the Docker image is expected behavior—it does not break connectivity but enables version control. -
Why not D?
Pushing changes with a new tag is correct procedure. The issue lies in the app still referencing the old tag, not just tagging itself.
The Technical Blueprint #
# Typical kubectl command to update deployment image tag
kubectl set image deployment/nebula-service nebula-container=123456789012.dkr.ecr.us-east-1.amazonaws.com/nebula-service:v1.1
# To verify pods are running with expected image
kubectl get pods -o=jsonpath="{.items[*].spec.containers[*].image}"
The Comparative Analysis #
| Option | API/Manifest Impact | Deployment Outcome | Use Case |
|---|---|---|---|
| A | No effect on deployment | Account exists; deployments succeed | N/A |
| B | Tags image; no breaking | Tag addition alone does not cause fail | Standard Docker best practice |
| C | Incorrect image tag reference in manifest | Deploys old image; retains legacy config | Common mistake, causes stale deployment |
| D | Correct image push | Supports new deployment lifecycle | Recommended practice |
Real-World Application (Practitioner Insight) #
Exam Rule #
“On the exam, always verify that your Kubernetes manifest image tag references the exact Docker image version pushed to ECR.”
Real World #
“In production, teams often automate updating image tags using CI/CD tools (e.g., CodePipeline with CodeBuild) to avoid this common error and ensure immutable deployments.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.