AWS DVA-C02 Drill: Enforcing Encryption in Transit - Secure Transport Condition in S3 Access

Jeff’s Note

#

Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.

For DVA-C02 candidates, the confusion often lies in how to enforce encryption in transit using policy conditions without accidentally allowing non-secure access. In production, this is about knowing exactly how to leverage IAM and resource-based policies with the aws:SecureTransport condition key on cross-account S3 access. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

DevCo, a software company, stores highly sensitive configuration files in an Amazon S3 bucket. The bucket data is encrypted at rest using an AWS KMS customer managed key (CMK). Several partner organizations, each in separate AWS accounts, need to retrieve these files programmatically by calling the S3 GetObject API. Security requirements mandate that these requests must always use encrypted connections to safeguard data in transit.

The Requirement:

#

How can a developer ensure that all cross-account requests to retrieve objects enforce encryption in transit (i.e., only allow requests using HTTPS)?

The Options

#

• A) Define a resource-based bucket policy on the S3 bucket that explicitly denies access when the request condition aws:SecureTransport is false.
• B) Define a resource-based bucket policy on the S3 bucket that allows access only when the request condition aws:SecureTransport is false.
• C) Define an IAM role policy in the other accounts that denies access when the request condition aws:SecureTransport is false.
• D) Define a resource-based policy on the KMS key that denies access when the request condition aws:SecureTransport is false.

Google adsense

#

leave a comment:

Correct Answer

#

A

Quick Insight: The Developer Imperative

#

To enforce encryption in transit, S3 bucket policies using the aws:SecureTransport condition key are the best practice. This denies any HTTP (not HTTPS) requests at the S3 resource layer, protecting the sensitive data retrieval regardless of the calling account’s permissions. KMS key policies do not validate transport security, and denying based on role policies in other accounts is ineffective for protecting the central resource.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option A

The Winning Logic

#

Option A is correct because the secure way to enforce encryption in transit for S3 is by applying a resource-based bucket policy that denies any request where aws:SecureTransport is false (meaning HTTP rather than HTTPS). This condition key is specifically supported by S3 and checks the transport security of the request.

This guarantees that even if the requesting AWS account has permission, connections without TLS (i.e., over HTTP) will be blocked at the bucket level, effectively enforcing the security requirement.

• From a developer perspective, this means you can share your resources cross-account securely by centrally applying this guardrail on the S3 bucket.
• Using a KMS key policy (Option D) won’t work here because KMS does not control transport layer security — it governs decryption permissions only.
• Option C suggests denying based on roles in other accounts, but resource-based policies on the bucket are the reliable enforcement mechanism for transport conditions.
• Option B incorrectly allows access on non-secure transport, which is the opposite of what’s needed.

The Trap (Distractor Analysis)

#

• Why not Option B?
  Allows access only when aws:SecureTransport is false, which means insecure HTTP requests are allowed — exactly opposite of the requirement.

• Why not Option C?
  Denying on role policies in other accounts does not reliably enforce encryption in transit because S3 bucket policies act as a gatekeeper. Moreover, aws:SecureTransport is a condition key checked at resource policy level, not on IAM role policies in client accounts.

• Why not Option D?
  The KMS key policy governs cryptographic permissions but does not check or enforce TLS connections. It will not block HTTP calls to S3.

The Technical Blueprint

#

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyInsecureTransport",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::devco-sensitive-configs/*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

This bucket policy snippet denies any GetObject request where the connection is not encrypted (i.e., non-HTTPS).

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always pick S3 bucket policies with aws:SecureTransport condition when the question is about enforcing encryption in transit for S3 access.

Real World

#

In production, enforcing on the bucket policy ensures security is intrinsic to the resource and cannot be circumvented by misconfigured client roles or other AWS accounts.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam.