SAA-C03 Design Secure Architectures Practice Question

A IoT ingestion API must ensure that only encrypted EBS volumes can be created in the account. What is the strongest preventive control?

⚠ Common exam trap

Test-takers frequently confuse preventive controls (like SCPs that block the action) with detective or corrective controls (like Lambda scripts or tagging), leading candidates to choose a reactive solution instead of the strongest preventive one.

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

✓

Use an SCP that denies ec2:CreateVolume when the encrypted condition is false

An SCP (Service Control Policy) is the strongest preventive control because it can deny the ec2:CreateVolume API call when the encrypted condition is false, effectively blocking the creation of any unencrypted EBS volume at the account level before it happens. This is a preventive control that enforces encryption as a mandatory requirement, unlike detective or corrective measures that act after the fact.

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 an SCP that denies ec2:CreateVolume when the encrypted condition is false
Why this is correct
A service control policy (SCP) is the correct preventive control because it operates at the AWS Organizations root, OU, or account level and can block the ec2:CreateVolume API call when the ec2:Encrypted condition key evaluates to false. This means unauthorized or unencrypted volume creation is denied before the resource exists, across all principals in the account, regardless of their IAM permissions. SCPs do not modify resources, but they enforce policy at request time, making them an effective guardrail for encryption compliance.
✗
Run a daily Lambda function to encrypt unencrypted volumes
Why it's wrong here
A daily Lambda function is a reactive, detective-and-remediate mechanism, not a preventive one. Unencrypted volumes remain live and visible for up to 24 hours, leaving a window of noncompliance and potential data exposure. Additionally, encrypting an existing EBS volume requires an encrypted snapshot copy and a new volume creation, which temporarily detaches or modifies the running instance and may cause downtime. The Lambda approach also depends on proper IAM roles, schedules, and event triggers, and it silently fails if those components misbehave, so it cannot guarantee compliance.
✗
Enable VPC Flow Logs
Why it's wrong here
VPC Flow Logs capture metadata about network traffic, such as source/destination IPs, ports, and protocol, but they do not record API calls or resource configuration changes. They are completely orthogonal to EBS volume encryption because they never inspect volume properties or block creation requests. Enabling Flow Logs would provide no data that indicates whether a volume is encrypted, nor any enforcement mechanism to prevent unencrypted volumes from being created. Thus, this option is irrelevant to the stated requirement.
✗
Tag encrypted volumes after creation
Why it's wrong here
Tagging encrypted volumes after creation is a tagging/taxonomy practice that only attaches key-value metadata to resources for identification or cost allocation. It does not alter the volume's underlying attributes, so any unencrypted volume remains unencrypted and fully usable. Tags can be added to any resource regardless of compliance status, and the absence of a tag does not block API calls. This approach offers no enforcement and no automated detection of unencrypted volumes; it merely labels resources, making it an ineffective control for this requirement.

Go deeper

SAA-C03 Design Secure Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question