Security Default Assumption — AWS Developer (DVA-C02)
You assumed a default security configuration that doesn't exist. Services often start permissive — know what you need to configure.
Cognito Authenticates Users. You Still Authorize Their Access.
A Cognito user pool answers 'is this person who they claim to be'. It does not answer 'is this person allowed to write to DynamoDB'. That second step requires a Cognito identity pool to exchange the user pool token for AWS credentials, an IAM role attached to the identity pool, and a policy on the role that grants the specific API calls. The identity pool calls STS AssumeRoleWithWebIdentity on behalf of the authenticated user, producing short-lived credentials scoped to the role's policy. A user pool alone leaves the authorization gap open.
The Scenario
The question asks how to ensure an existing S3 bucket does not allow public access. You answer "S3 Block Public Access is enabled by default, so no action is needed." True for buckets created after April 2023. But the scenario describes a bucket created in 2019 with existing bucket policies. Pre-2023 buckets may have public access enabled, and existing bucket policies that grant public read are not retroactively blocked. The correct answer is to explicitly enable S3 Block Public Access at the account level and review existing bucket policies for public access grants. The exam tests whether you know that new defaults do not apply retroactively to existing resources.
How to Spot It
- •AWS security defaults have changed over time. EBS volumes are now encrypted by default in new accounts (since 2024), but existing accounts need to enable the "EBS encryption by default" setting. New Security Groups allow all outbound traffic by default. Default VPC subnets auto-assign public IPs. Know what "default" actually means for each service.
- •Lambda functions have no VPC attachment by default — they run in AWS-managed VPCs with internet access. When you attach Lambda to your VPC, it loses internet access unless you add a NAT Gateway. The exam tests whether you know this default changes behavior when you add VPC configuration.
- •When the question says "existing" infrastructure, assume nothing about current configuration. Legacy resources have legacy defaults. The answer always involves explicit verification and configuration, not reliance on defaults.
Decision Rules
Whether to attach an ECR repository policy in Account A explicitly granting the Account B task execution role principal pull permissions — versus relying solely on IAM identity-based permissions attached to the task execution role in Account B — given that cross-account ECR pulls require both the consuming-account IAM role permissions and a resource-based repository policy on the source registry.
Select SSE-KMS with a customer-managed key over SSE-S3 because only SSE-KMS with a CMK produces per-request CloudTrail key-usage events and grants the organization direct key-rotation authority; SSE-S3 satisfies encryption at rest but fails the auditability and key-ownership constraints.
Whether the instance role's IAM policy scopes secretsmanager:GetSecretValue to the exact named secret ARN or uses a wildcard resource — both options eliminate hardcoded credentials via an instance profile, but only resource-level scoping to the specific ARN satisfies the no-wildcard-resource-in-secrets-policy constraint.
Whether account-level separation via AWS Organizations (hard platform-enforced boundary) or intra-account isolation via separate VPCs plus restrictive IAM/SCP controls satisfies the 'unreachable under any misconfiguration' constraint.
Domain Coverage
Difficulty Breakdown
Related Patterns