An application that is running on Amazon EC2 instances stores data in an Amazon S3...

“Encryption in transit” means the connection between the client (EC2 instances) and Amazon S3 must use TLS/HTTPS, not plain HTTP. The most direct way to enforce this at the bucket level is an S3 bucket policy that denies any request that is not using secure transport. AWS provides the global condition key aws:SecureTransport, which evaluates to true when a request is made over HTTPS and false when made over HTTP.

By adding an explicit Deny statement conditioned on aws:SecureTransport = false, the bucket rejects any insecure requests regardless of who makes them. This ensures that even if an application is misconfigured (or a user tries to access the bucket over HTTP), S3 will refuse the request. This is a strong enforcement mechanism because explicit denies in IAM policies override allows.

Option C (SSE-KMS) provides encryption at rest, not in transit. It protects objects while stored in S3 but does not force clients to use TLS for transport. Option B (VPC endpoint) can keep traffic on the AWS network path and can be combined with endpoint policies, but it does not inherently guarantee TLS usage unless you also enforce HTTPS. Option A (installing certificates) is not the mechanism for controlling whether the application uses HTTPS to S3; the S3 client uses AWS-managed TLS endpoints, and enforcement should happen through policy.

Therefore, the correct solution is D: create an S3 bucket policy that denies requests when aws:SecureTransport is false, ensuring all access uses encrypted transport (HTTPS/TLS).