How to Automate CloudFront Cache Invalidation After S3 Deploy in CodePipeline
A company uses AWS CodePipeline to deploy a static website to Amazon S3. The pipeline has a source stage from CodeCommit, a build stage using CodeBuild, and a deploy stage that uses S3 deployment action. The website is served via Amazon CloudFront. After a successful pipeline run, the updated files are in S3, but CloudFront still serves old content. What is the MOST efficient solution?
Quick Answer
The answer is to add a post-deploy invalidation step in CodePipeline to create a CloudFront invalidation after the S3 deploy. This is the most efficient solution because CloudFront caches content at edge locations based on the original object’s TTL; updating the S3 bucket alone does not purge the cached copies, so stale files persist until they expire or are explicitly invalidated. By inserting a Lambda or CodeBuild action in the pipeline that calls the CreateInvalidation API, you automate the cache refresh immediately after each deployment, ensuring users always see the latest content. On the AWS Certified Developer Associate DVA-C02 exam, this scenario tests your understanding of CloudFront caching behavior and pipeline automation—a common trap is assuming that reducing the TTL is sufficient, but that still introduces a delay and may serve stale data during the transition. A useful memory tip: “Deploy to S3, then invalidate the CDN—automate it in the pipeline, never do it by hand again.”
⚠ Common exam trap
Many candidates think reducing TTL to 0 is a valid solution, but this ignores the fact that TTL controls how long objects are cached, not how to purge already-cached content, and it would severely degrade CDN performance.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Add a post-deploy invalidation step in CodePipeline to create a CloudFront invalidation.
It automates the creation of a CloudFront invalidation as part of the CodePipeline post-deploy stage. This ensures that after new files are uploaded to S3, CloudFront's edge caches are purged of the old content, forcing it to fetch the updated files from the origin. This is the most efficient solution as it requires no manual intervention and does not compromise caching performance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Manually create a CloudFront invalidation after each deployment.
Why it's wrong here
Manual invalidation requires human intervention after every pipeline run, so it is not automated within CodePipeline. It is tempting because it does clear cached objects. The efficient fix adds an invalidation action into the pipeline itself, removing manual steps.
- ✗
Reduce the CloudFront distribution's default TTL to 0.
Why it's wrong here
Setting default TTL to 0 forces CloudFront to revalidate every object with S3 on each request, adding latency and origin load. It is tempting because it eliminates staleness. The efficient fix invalidates changed objects during deployment instead.
- ✓
Add a post-deploy invalidation step in CodePipeline to create a CloudFront invalidation.
Why this is correct
CloudFront caches objects at edge locations until the TTL expires, so new S3 objects are not served immediately. Creating an invalidation for the changed paths forces edge caches to refetch from the origin, satisfying the requirement for fresh content efficiently.
- ✗
Update the S3 bucket policy to allow public read access.
Why it's wrong here
Bucket policy governs who may read objects from S3; it has no effect on objects CloudFront has already cached at edge locations. It is tempting because public read access is needed for website delivery. The stale content stems from cache TTL, not permissions.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This DVA-C02 question is part of Courseiva's 1,135-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on DVA-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company uses AWS CodePipeline to deploy a static website to Amazon S3. The pipeline has a build stage that compiles the website and a deploy stage that syncs the build output to an S3 bucket. After a recent change, the pipeline succeeds but the website does not show the updated content. What is the most likely cause?
medium- ✓ A.Amazon CloudFront is caching the old content and needs an invalidation.
- B.The build output is empty because the build failed silently.
- C.The deploy action is configured to skip if the source content has not changed.
- D.The S3 bucket policy does not allow public read access.
Why A: The correct answer is A: Amazon CloudFront is caching the old content and needs an invalidation. Since the pipeline succeeds and the deploy stage syncs the build output to S3, the updated files are likely in the bucket, but CloudFront continues serving cached objects from edge locations until the cache expires or an invalidation is created (e.g., aws cloudfront create-invalidation --distribution-id <ID> --paths "/*"). Option B is unlikely because a silent build failure would typically cause the build stage to fail or produce missing artifacts, and the pipeline reports success. Option C is not a standard CodePipeline deploy behavior for S3 sync actions, which deploy the specified artifacts rather than conditionally skipping unchanged content. Option D would cause access denied errors for website visitors, not stale content, and the pipeline could still succeed.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.