Why doesn't CloudFront show updated S3 files after a CodeBuild deployment?

A developer hosts a static website on Amazon S3 and connects the website to an Amazon CloudFront distribution. The website uses a custom domain name that points to the CloudFront URL. The developer has set up a continuous integration and continuous delivery (CI/CD) pipeline. The pipeline automatically runs when changes occur in an AWS CodeCommit repository. The pipeline has a source stage and then a build stage. The build stage invokes an AWS CodeBuild project that references a buildspec.yml file. The buildspec.yml file builds the code and deploys the static files to the S3 bucket. The pipeline runs successfully, and the latest website files are visible in the S3 bucket and at the S3 website URL. However, when the developer accesses the website through the CloudFront domain, the updates are not reflected on the website. What should the developer configure the buildspec.yml file to do to resolve this issue?

  1. Properly synchronize the objects in the S3 bucket with new files from the source stage.
  2. Delete the previous website files in the S3 bucket and redeploy the website files.
  3. Invalidate the file caches for the primary CloudFront distribution. Source Reference Answer
  4. Modify the cross-origin resource sharing (CORS) policy of the S3 bucket and redeploy the website files.

Community Votes

C
100%

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

Community Insight

The exam tests whether you recognize that stale content at CloudFront edge locations requires a cache invalidation, not changes to the S3 deployment process or bucket policies.

CloudFront serves cached S3 objects at edge locations until their TTL expires, so a successful CI/CD deployment to S3 does not immediately appear at the CloudFront domain. The community unanimously agrees the buildspec.yml should invalidate the CloudFront distribution cache using the AWS CLI.

Many candidates pick A (properly synchronizing S3 objects) because the deployment stage seems suspect, but the question explicitly states the latest files are already visible in the bucket and at the S3 website URL—only the CloudFront cache is stale.

Community Discussion (3 comments)

examuserss 👍 1 Selected: C
Invalidate the CloudFront cache: To ensure that CloudFront serves the most up-to-date content, you can trigger a cache invalidation in your buildspec.yml file. This will force CloudFront to fetch the latest files from the S3 bucket rather than serving cached content. You can do this by using the AWS CLI to invalidate the CloudFront distribution cache.
4d716d6 👍 1 Selected: C
Invalidate the caches to enable the new code deployed to reflect
albert_kuo 👍 1 Selected: C
aws cloudfront create-invalidation --distribution-id EXAMPLE123 --paths "/*"

Comments & Corrections

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

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

CloudFront caches objects at edge locations for the TTL defined in the cache behavior (24 hours by default), so newly deployed S3 files are not served until the cache expires. Adding a cache invalidation step to buildspec.yml—e.g., aws cloudfront create-invalidation --distribution-id <ID> --paths "/*"—forces CloudFront to fetch the fresh objects from S3 immediately. Comment [1] explicitly describes triggering invalidation in buildspec.yml via the AWS CLI to force CloudFront to fetch the latest files, and comment [3] provides the exact CLI command. This is the standard, documented pattern for static-site CI/CD pipelines deployed through CloudFront.

Why the Other Options Are Wrong

A is incorrect because the question confirms the latest website files are already visible in the S3 bucket and at the S3 website URL, so synchronization is working. B (deleting and redeploying files) changes nothing because the stale copies live in CloudFront edge caches, not in S3. D is irrelevant since CORS governs cross-origin browser requests, not stale content delivery—the site loads fine, just with old content. Only an invalidation addresses the actual caching layer sitting between the user and the bucket.

Community Comment Notes

All comments unanimously vote C, representing 100% of the vote distribution. Comment [1] gives the fullest rationale: invalidating the cache forces CloudFront to fetch the latest files from the S3 bucket rather than serving cached content. Comment [2] concisely confirms the goal is to enable the newly deployed code to be reflected, and comment [3] supplies the practical CLI syntax developers can embed in buildspec.yml, reinforcing that the fix belongs in the build stage of the pipeline.

Official Reference

Exam Strategy

When a question says files are correct in S3 but stale through CloudFront, jump straight to cache invalidation. Memorize the command aws cloudfront create-invalidation --distribution-id <ID> --paths "/*" and remember it belongs in buildspec.yml for CI/CD scenarios. Eliminate options that only touch S3—stale content at the edge is never an S3 problem.

Related Analysis

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