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 AWS Config rules with automatic remediation to detect and fix non-compliant buckets.

  Why this is correct

  AWS Config rules continuously evaluate S3 buckets against predefined or custom compliance standards, such as requiring server-side encryption or blocking public access. When a non-compliant bucket is detected, Config can automatically trigger remediation actions, like applying a default encryption policy or enabling S3 Block Public Access, ensuring ongoing adherence to security policies across all accounts where the rule is deployed. This proactive approach ensures that any newly created or modified non-compliant buckets are swiftly brought into compliance without manual intervention.

• ✗

  Attach an IAM policy to all IAM users in each account that denies unencrypted operations.

  Why it's wrong here

  Attaching IAM policies to individual IAM users within each account is insufficient because it only restricts those specific users and does not apply to service roles, the root user, or other principals. Furthermore, IAM policies primarily control *who can perform an action*, not necessarily *how the action is performed* (e.g., forcing encryption on *all* PutObject requests without explicit bucket policies). This approach would require extensive, decentralized management across numerous accounts and still leave many potential vectors for non-compliant S3 operations.

• ✓

  Use an SCP in the root organizational unit to deny 's3:PutBucketPublicAccessBlock' and enforce encryption settings.

  Why this is correct

  A Service Control Policy (SCP) applied at the root organizational unit provides a powerful, preventative guardrail by explicitly denying actions that could compromise S3 bucket security, such as `s3:PutBucketPublicAccessBlock` if the intent is to enforce it. SCPs define the maximum available permissions for all IAM users and roles in affected accounts, effectively preventing any account administrator from disabling critical security features or creating buckets without required encryption settings, thereby enforcing a baseline security posture across the entire organization. This centralized control ensures consistent compliance.

• ✗

  Enable AWS CloudTrail to log all S3 API calls and send alerts.

  Why it's wrong here

  While AWS CloudTrail is essential for auditing and monitoring API activity, logging S3 API calls and sending alerts is a reactive measure that detects non-compliant actions *after* they have occurred. CloudTrail provides visibility into who did what, when, and from where, but it does not inherently prevent users or services from performing unencrypted operations or creating non-compliant buckets. Therefore, it cannot enforce encryption settings or prevent public access proactively; it only notifies of violations post-facto.

• ✗

  Use AWS Trusted Advisor to check for unencrypted buckets.

  Why it's wrong here

  AWS Trusted Advisor provides recommendations and best practice checks, including identifying unencrypted S3 buckets, but it is a diagnostic tool that offers advice rather than enforcement. It performs periodic checks and highlights potential issues, but it does not have the capability to prevent the creation of non-compliant resources or automatically remediate existing ones. Relying solely on Trusted Advisor would require manual intervention to address each identified issue, making it unsuitable for automated, organization-wide enforcement.

Go deeper

Related to this question