Courseiva
SecurityhardMultiple ChoiceObjective-mapped

DVA-C02 Security Practice Question

A company has a multi-account AWS environment using AWS Organizations. The security team wants to enforce that all S3 buckets across all accounts are encrypted with AES-256 using SSE-S3. They also want to automatically remediate any bucket that is created without encryption. The team currently uses AWS CloudFormation StackSets to deploy resources. They need a solution that does not require manual intervention. Which approach should be taken?

⚠ Common exam trap

A common mix-up: candidates confuse preventive controls (SCPs) with detective and corrective controls (Config + Automation), failing to realize that SCPs alone cannot remediate already non-compliant resources or enforce encryption on buckets created without encryption settings.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Configure an AWS Config rule to detect buckets without SSE-S3 and use AWS Systems Manager Automation to apply SSE-S3 encryption automatically.

AWS Config can continuously evaluate S3 buckets against a custom rule that checks for SSE-S3 encryption. When a non-compliant bucket is detected, AWS Systems Manager Automation can automatically remediate it by applying the required encryption, meeting the requirement for automatic remediation without manual intervention.

Answer analysis

Option-by-option breakdown

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

  • Create an SCP that denies s3:PutBucketEncryption with a condition that the encryption is not SSE-S3.

    Why it's wrong here

    SCPs (Service Control Policies) operate at the API action level and can restrict actions based on conditions related to the principal, resource ARN, or request tags. However, SCPs cannot inspect the specific content of an API request payload, such as the detailed configuration parameters passed to s3:PutBucketEncryption that specify the exact encryption type (e.g., SSE-S3 versus SSE-KMS). Therefore, an SCP cannot be conditioned to specifically deny encryption unless it is SSE-S3, making it ineffective for enforcing a particular server-side encryption standard.

  • Configure an AWS Config rule to detect buckets without SSE-S3 and use AWS Systems Manager Automation to apply SSE-S3 encryption automatically.

    Why this is correct

    AWS Config provides continuous monitoring of resource configurations against desired states. A managed Config rule, such as s3-bucket-server-side-encryption-enabled, can detect S3 buckets that do not have server-side encryption enabled or do not meet the specified SSE-S3 requirement. Upon detection of non-compliance, AWS Config can trigger an AWS Systems Manager Automation document, which can then execute the necessary API calls (e.g., PutBucketEncryption) to automatically apply SSE-S3 encryption to the non-compliant buckets, ensuring ongoing compliance and remediation.

  • Create a CloudFormation template that includes a bucket with SSE-S3 enabled and deploy it via StackSets to all accounts.

    Why it's wrong here

    Deploying a CloudFormation template via StackSets is an effective Infrastructure as Code (IaC) method for provisioning new S3 buckets with SSE-S3 enabled consistently across multiple accounts. However, this approach is inherently limited to resources managed by CloudFormation. It will not identify or remediate existing S3 buckets that were created manually, through other scripts, or prior to the StackSet deployment, nor will it prevent users from creating non-compliant buckets outside of the CloudFormation pipeline in the future.

  • Enable S3 Block Public Access at the organization level.

    Why it's wrong here

    S3 Block Public Access is a crucial security feature designed to prevent public access to S3 buckets and objects, mitigating risks associated with unintended data exposure. It enforces restrictions like blocking new public ACLs, public policies, and cross-account access. While vital for overall data security, enabling S3 Block Public Access at the organization level addresses public accessibility concerns and has no direct impact on enforcing or verifying the use of server-side encryption, such as SSE-S3, for data at rest.

Quick reference

Symmetric Encryption Algorithm Comparison

AlgorithmKey SizeBlock SizeStatusNotes
AES-128128-bit128-bitCurrent standardNIST approved; WPA3, TLS
AES-256256-bit128-bitCurrent standardPreferred for sensitive / govt data
3DES112-bit effective64-bitDeprecated (2023)Replaced by AES
DES56-bit64-bitBrokenCracked in < 24 h; never deploy
ChaCha20256-bitStream cipherCurrentTLS 1.3, WireGuard

About these practice questions

Courseiva writes every DVA-C02 question from scratch — 724 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.