AWS Certification Solutions Architect Associate 2025 past questions and answers

1. Enable SSE-S3 as the bucket's default encryption and use S3 server access logs to audit key usage.
2. Configure default SSE-KMS encryption with a customer managed AWS KMS key and review the key's CloudTrail events.
3. Encrypt every object in application code with a single hard-coded data key before uploading it.
4. Place the bucket in a private subnet and rely on the subnet to encrypt stored objects.

Answer: B. Configure default SSE-KMS encryption with a customer managed AWS KMS key and review the key's CloudTrail events.

Default SSE-KMS encryption uses a company-controlled KMS key without requiring each application upload to implement encryption, and KMS activity is auditable through CloudTrail. SSE-S3 does not provide the same customer control over the encryption key, while network placement does not encrypt stored S3 objects.

1. Attach an IAM role to the instance with permission to assume a read-only role in Account B, and configure that role's trust policy and the bucket policy to allow the access.
2. Create an IAM user in Account B, put its access keys in the instance user data, and grant it S3 read access.
3. Make the bucket public for reads and use an instance profile to sign requests.
4. Add Account A's root user as an S3 bucket owner and share the root credentials with the application.

Answer: A. Attach an IAM role to the instance with permission to assume a read-only role in Account B, and configure that role's trust policy and the bucket policy to allow the access.

An instance profile supplies temporary credentials, while a trusted role in Account B and a bucket policy grant only the required cross-account read access. Static IAM user keys and root credentials are unnecessary and create excessive credential risk; public access is not least privilege.

1. Store the password in an encrypted file on each application instance and rotate it manually.
2. Place the password in an environment variable and rely on instance replacement for rotation.
3. Store the password in an S3 object and restrict access with a bucket policy.
4. Store the credential in AWS Secrets Manager, enable supported automatic rotation, and have the application retrieve it using an IAM role.

Answer: D. Store the credential in AWS Secrets Manager, enable supported automatic rotation, and have the application retrieve it using an IAM role.

Secrets Manager supports managed secret storage and automatic rotation for supported RDS configurations; an instance role avoids static retrieval credentials. Environment variables and files do not provide coordinated rotation, and S3 is not a purpose-built secrets lifecycle service.

1. Terminate TLS on each EC2 instance using manually renewed certificates, and block suspicious clients with network ACLs.
2. Use a self-managed certificate on the load balancer and install antivirus software on the EC2 instances.
3. Associate an AWS Certificate Manager certificate with the ALB listener and associate an AWS WAF web ACL with the ALB.
4. Use an S3 bucket policy to terminate TLS and filter SQL injection requests before traffic reaches the ALB.

Answer: C. Associate an AWS Certificate Manager certificate with the ALB listener and associate an AWS WAF web ACL with the ALB.

ACM certificates on an ALB provide managed certificate provisioning and renewal, while AWS WAF applies managed or custom web request rules at the application layer. Network ACLs are not a substitute for HTTP-layer filtering, and S3 bucket policies neither terminate ALB traffic nor inspect web requests.

1. Run one large EC2 instance in a single public subnet and create an AMI for manual recovery.
2. Place an EC2 Auto Scaling group across private subnets in at least two Availability Zones behind an Application Load Balancer.
3. Place two EC2 instances in one Availability Zone behind a Network Load Balancer.
4. Use an Auto Scaling group in one Availability Zone and store session state on instance disks.

Answer: B. Place an EC2 Auto Scaling group across private subnets in at least two Availability Zones behind an Application Load Balancer.

An Auto Scaling group spanning multiple Availability Zones can replace unhealthy instances and retain capacity after an AZ failure, while the ALB distributes requests. Two instances in one AZ share that AZ's failure risk, and local session state prevents transparent replacement.