DVA-C02 Deployment Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Enable server access logging.

  Why it's wrong here

  Enabling server access logging is an optional operational feature that records bucket-level request logs to a target bucket for auditing or analytics. It does not influence whether a bucket can serve a public static website, nor does it configure any web-facing behavior. Because the developer's goal is simply to deploy and serve a static site, this step is not required and would not make the site reachable.

• ✓

  Enable static website hosting on the S3 bucket.

  Why this is correct

  Enabling static website hosting on the S3 bucket is the essential configuration that activates the bucket's website endpoint (e.g., bucket-name.s3-website-region.amazonaws.com), which serves the site over HTTP and automatically resolves requests to an index document (like index.html) and a custom error document. Without this setting, the bucket only exposes its REST API endpoints, which require Signature Version 4 authentication and cannot render a browser-facing website. Therefore, this is a mandatory step for hosting any static site on Amazon S3.

• ✗

  Set a bucket policy that restricts access to a specific IP.

  Why it's wrong here

  Setting a bucket policy that restricts access to a specific IP address would deny requests from all other visitors, which directly contradicts the requirement for a publicly accessible website. While bucket policies can control access on S3, a public static site needs an allow-all or open policy (or no policy with a public ACL) to let anonymous browsers retrieve objects. This step would actively block most users and is therefore incorrect.

• ✗

  Configure Amazon CloudFront as a CDN.

  Why it's wrong here

  Configuring Amazon CloudFront as a CDN is an optional enhancement that adds edge caching, HTTPS termination, and custom domain support, but it is not a prerequisite for serving a static website from S3. The bucket itself, once static hosting is enabled and objects are public, can be accessed directly via its website endpoint without CloudFront. Since the developer must simply deploy the site, this step is unnecessary for the core functionality.

• ✓

  Set the bucket objects to publicly readable.

  Why this is correct

  Setting the bucket objects to publicly readable is necessary because a static website on S3 relies on anonymous GET requests from any browser, and every object (HTML, CSS, JavaScript, images) must be accessible without authentication. This can be accomplished by attaching a bucket policy that grants s3:GetObject to 'Principal: *' or by configuring a public ACL on the bucket (though the latter is deprecated for new buckets). Without public read access, the website's files would return HTTP 403 Forbidden errors, making the site unusable.