DVA-C02 Security 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.

• ✗

  Use SSE-KMS encryption on the bucket.

  Why it's wrong here

  Server-Side Encryption with KMS (SSE-KMS) protects data at rest by encrypting objects before saving them to disk and decrypting them when downloaded. While crucial for data security, encryption is a data protection mechanism, not an access control mechanism. It does not restrict *who* or *what* can request access to the objects in the bucket, only that the requester must have permission to use the KMS key to decrypt the data *after* being granted access to the object itself. Therefore, it doesn't prevent unauthorized access attempts.

• ✗

  Enable S3 Block Public Access on the bucket.

  Why it's wrong here

  Enabling S3 Block Public Access (BPA) is a critical security control designed to prevent accidental or intentional public exposure of S3 buckets and objects. However, BPA primarily targets anonymous access and access from authenticated AWS users outside the account, or cross-account access not explicitly allowed by a bucket policy. It does not inherently restrict access from other AWS services or EC2 instances within the same AWS account, which might still be able to access the bucket if their IAM roles or policies permit it.

• ✓

  Add a bucket policy that allows access only from the VPC endpoint or specific IP addresses of the EC2 instances.

  Why this is correct

  A well-crafted S3 bucket policy can precisely define which principals, from which network locations, can perform specific actions on the bucket and its objects. By incorporating conditions that check for a VPC endpoint ID (using `aws:sourceVpce`) or specific source IP addresses (using `aws:SourceIp` for public IPs or `aws:VpcSourceIp` for private IPs within a VPC), access can be strictly limited to the intended EC2 instances or services operating within a controlled network environment. This granular control directly addresses the requirement to restrict access to authorized resources.

• ✗

  Move the sensitive data to a different S3 bucket and update the application.

  Why it's wrong here

  Moving sensitive data to a different S3 bucket, even if the application is updated to reflect the new location, does not inherently improve the security posture regarding access control. The new bucket would still require proper access policies to prevent unauthorized access. Without implementing specific restrictions on the new bucket, it would be just as vulnerable to unauthorized access as the original bucket, merely shifting the problem rather than solving the underlying access control challenge.