1.3 - Data security: encryption, secrets and S3 protection
AWS Solutions Architect Associate objective 1.3 covers securing data. When a company keeps accidentally making S3 buckets public through bucket policies or ACLs, turning on S3 Block Public Access at the account level overrides those settings and reliably prevents public exposure. To store a small plaintext configuration value, Systems Manager Parameter Store using a String parameter works, and SecureString parameters encrypt secrets with KMS - while Secrets Manager adds automatic rotation for credentials. When an application needs temporary, scoped permission to use one specific KMS key, a KMS grant delegates that limited use without changing the key policy. You should also know encryption at rest and in transit, and key policies. Expect scenario questions that describe preventing public buckets, storing configuration or secrets, or delegating scoped key use, and ask which data-security control - Block Public Access, Parameter Store or a KMS grant - applies.
Stop accidental public buckets = S3 Block Public Access (account level). Small config value = Parameter Store (SecureString for secrets; Secrets Manager rotates). Temporary scoped use of one KMS key = a KMS grant.
Practice questions
1. How can EC2 instances in a private subnet reach Amazon S3 without traversing the public internet?
- Attach an internet gateway to the subnet
- Assign each instance an Elastic IP address
- Route traffic through a bastion host
- Use an S3 gateway VPC endpoint (correct answer)
A gateway VPC endpoint for S3 adds a route so traffic stays on the AWS private network, no IGW/NAT needed. It is free and improves security.
2. Which option encrypts data at rest in an S3 bucket using keys that AWS manages entirely for you at no extra cost?
- SSE-S3 (Amazon S3 managed keys) (correct answer)
- SSE-KMS with a customer managed key
- SSE-C (customer provided keys)
- Client-side encryption with a custom KMS key
SSE-S3 uses AES-256 keys that S3 fully manages, enabled by default, at no additional cost. SSE-KMS adds auditability and key control but incurs KMS charges.
3. Who ultimately controls which principals may use a customer managed KMS key to encrypt and decrypt data?
- The IAM policy of the caller alone, independent of any key configuration
- AWS support, which must approve each principal added to a key
- The security group attached to the KMS key's networking endpoint
- The KMS key policy, which is the primary access control for the key (correct answer)
Every KMS key has a key policy that is the root of access control. Access can be delegated to IAM policies, but the key policy must allow it; a key with no key policy statement is unusable even by admins.
4. A company keeps accidentally making S3 buckets public via bucket policies. Which account-level control prevents any bucket from becoming public?
- Enabling default SSE-KMS encryption on every bucket in the account
- Turning on S3 Block Public Access at the account level (correct answer)
- Attaching an IAM permission boundary to the S3 service role
- Enabling S3 Versioning together with MFA delete on each bucket
S3 Block Public Access at the account level overrides any bucket ACL or policy that would grant public access, providing a strong global guardrail against accidental exposure.
5. A private-subnet app must call Amazon SQS privately, without any route to the internet and without a NAT gateway. Which construct provides this?
- A gateway VPC endpoint, since SQS is supported like S3 and DynamoDB
- A public NAT gateway restricted by a narrow security group to SQS only
- A VPC peering connection from the private subnet to the SQS service VPC
- An interface VPC endpoint (PrivateLink) that exposes SQS via a private ENI (correct answer)
Most AWS services (including SQS) are reached privately via an interface VPC endpoint (PrivateLink), which puts a private ENI in your subnet. Only S3 and DynamoDB use gateway endpoints.
6. An application must let a user download one private S3 object for a limited time, without making the bucket public or creating IAM users. What is the standard approach?
- Generate a time-limited presigned URL granting temporary object access (correct answer)
- Attach a bucket policy allowing anonymous GetObject on that key prefix
- Enable public access on just that object using an object-level ACL
- Email the object using SES so the recipient never touches the bucket
A presigned URL embeds the requester's temporary credentials and an expiry, granting time-limited access to a specific object without changing bucket permissions or creating IAM users.