AWS Solutions Architect Design Secure Architectures: 325 practice questions

12 of the 325 Design Secure Architectures questions in the Certsqill AWS Solutions Architect bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS Solutions Architect? Take the free 5-min readiness check →

1. Create an IAM role with the required S3 permissions: What is the recommended solution?

1. Create an IAM role with the required S3 permissions and attach it to the EC2 instance as an instance profile ✓

   Correct. IAM roles attached to EC2 instances provide temporary, automatically rotated credentials via the instance metadata service. No long-term credentials are stored in code or environment variables.
2. Rotate the embedded access keys every 90 days by enabling automatic rotation in AWS Secrets Manager

   Incorrect. While Secrets Manager can automate credential rotation, it does not eliminate the static keys embedded in the application. The recommended approach for EC2 workloads is an IAM instance role, which supplies automatically rotated temporary credentials with no static keys at all.
3. Encrypt the embedded access keys with an AWS KMS customer managed key and decrypt them at application runtime

   Incorrect. Encrypting the static access keys does not remove the risk, because the application still decrypts them at runtime and the decryption grant itself becomes a secret to protect. IAM roles remove the need for static keys entirely.
4. Move the access keys out of the code and into an environment variable set on the EC2 instance

   Incorrect. Keeping the access keys in an environment variable is still a long-term credential stored on the instance and does not address the fundamental static-credential risk. IAM roles provide automatically rotated temporary credentials instead.

EC2 instances should use IAM instance profiles (roles) to obtain temporary credentials automatically — never embed long-term access keys in code or instances.

2. Create an IAM role in Company A's account with a trust: What is the most secure way to grant this access witho

1. Make the S3 buckets publicly readable and rely on the obscurity of the randomly generated bucket names to deter access

   Incorrect. Making buckets public exposes the data to the entire internet, and relying on hard-to-guess bucket names is security through obscurity, which is not a recognized access control.
2. Create an IAM role in Company A's account with a trust policy allowing Company B's account to assume it, then grant the role S3 read permissions ✓

   Correct. Cross-account IAM role assumption is the AWS-recommended pattern. Company A creates a role with a trust policy specifying Company B's account ID. Company B's users/services call STS AssumeRole to get temporary credentials scoped to that role — no static credentials are shared.
3. Create an IAM user in Company B's account and attach an inline policy referencing the ARNs of Company A's S3 buckets to grant direct cross-account read access

   Incorrect. An IAM policy in one account cannot by itself grant access to resources owned by another account. Cross-account access requires either a role in the resource account or a resource-based bucket policy, not a standalone IAM user in the requesting account.
4. Create an IAM user in Company A's account, generate long-term access keys, and share those keys directly with Company B's team

   Incorrect. Sharing IAM user access keys is a security anti-pattern that creates long-term credentials which are hard to rotate and audit, and it violates the principles of least privilege and account isolation.

Cross-account IAM role assumption provides temporary credentials for Company B without sharing long-term credentials — the AWS-recommended pattern.

3. Attach a Service Control Policy to the organizational unit: Which solution achieves this?

1. Use Amazon GuardDuty to detect when CloudTrail logging is disabled and trigger an AWS Lambda function that automatically re-enables the trail

   Incorrect. GuardDuty detects threats and suspicious activity but does not enforce preventive controls, so the detection-to-remediation gap leaves a window where logging is off. An SCP prevents the disable action in the first place.
2. Attach an IAM policy in each member account that denies the CloudTrail disable actions to every IAM user and role in the account

   Incorrect. IAM policies inside a member account can be removed or altered by the account's administrators, including the root user, so this does not stop root from bypassing the restriction. SCPs are the correct tool for organization-wide, unfalsifiable guardrails.
3. Attach a Service Control Policy (SCP) to the organizational unit (OU) that denies the cloudtrail:DeleteTrail and cloudtrail:StopLogging actions ✓

   Correct. SCPs are applied at the Organization or OU level and restrict what actions all principals (including root users) in member accounts can perform. An SCP denying CloudTrail disable actions cannot be overridden by any IAM policy in the member account, including root.
4. Enable an AWS Config managed rule in each member account that detects a disabled CloudTrail trail and automatically re-enables it through an SSM remediation action

   Incorrect. AWS Config detects and can remediate configuration violations, but there is an inherent delay between CloudTrail being disabled and Config detecting and re-enabling it. An SCP prevents the action proactively before it can happen.

SCPs applied at the organization/OU level block actions for ALL principals including root in member accounts — they are the only preventive control that cannot be bypassed by account administrators.

4. Access is denied: When the user tries to read an object from that bucket, what happens?

1. Access is allowed because the more permissive result wins when identity-based and resource-based policies both apply

   Incorrect. AWS does not use 'most permissive wins' logic. The evaluation checks for an explicit Deny first, and an explicit Deny anywhere produces a final Deny decision.
2. Access is allowed because the identity-based Allow attached to the user overrides the bucket policy Deny

   Incorrect. An explicit Deny always overrides any Allow, regardless of which policy contains the Deny or the Allow. The source (identity versus resource policy) does not change the precedence of an explicit Deny.
3. Access is denied only if the bucket policy Deny statement also lists the s3:ListBucket action

   Incorrect. The Deny applies to the actions it lists, which is s3:GetObject here. Adding s3:ListBucket would additionally deny listing, but the GetObject Deny is independently effective.
4. Access is denied — an explicit Deny in any applicable policy always overrides any Allow, regardless of the source ✓

   Correct. AWS IAM policy evaluation gives explicit Deny statements the highest precedence. Even if an identity-based policy Allows an action, an explicit Deny in the resource-based bucket policy always overrides it, so the final decision is Deny.

Explicit Deny always wins in AWS IAM policy evaluation — it overrides any Allow from any policy, regardless of identity-based or resource-based policy source.

5. Security Groups are stateful and operate at the instance: Which statement correctly describes the difference b

1. Security Groups are stateful and operate at the instance or ENI level; NACLs are stateless and operate at the subnet level ✓

   Correct. Security Groups are stateful — return traffic for an allowed connection is automatically permitted. NACLs are stateless — both inbound and outbound rules must explicitly allow return traffic. Security Groups apply to instances/ENIs; NACLs apply to subnets.
2. Both Security Groups and NACLs are stateful, but only NACLs support explicit deny rules while Security Groups support allow rules only

   Incorrect. Security Groups are stateful and support Allow rules only, with an implicit deny for unmatched traffic. NACLs are stateless and support both Allow and Deny rules. The stateful-versus-stateless distinction is the critical difference.
3. Security Groups are stateless at the subnet level, while NACLs are stateful at the instance level

   Incorrect. This reverses the correct behavior. Security Groups are stateful and operate at the instance level; NACLs are stateless and operate at the subnet level.
4. NACLs apply the most specific matching rule in any order, while Security Groups aggregate all rules into one permission set

   Incorrect. NACLs evaluate rules in numerical order (lowest number first) and stop at the first match, not the most specific one. Security Groups do evaluate all rules and aggregate permissions with an implicit deny for no match.

Security Groups = stateful + instance-level + Allow only. NACLs = stateless + subnet-level + Allow and Deny.

6. Web tier in public subnets: Which architecture correctly places each tier for security best practices?

1. All three tiers in private subnets behind a NAT Gateway for internet access

   Incorrect. Placing the web tier in a private subnet with NAT means users cannot access the application from the internet (NAT provides outbound access for instances, not inbound access for users). The web tier must be in a public subnet with an internet-facing load balancer.
2. Web tier in public subnets; application tier and database tier in private subnets ✓

   Correct. Only the web tier (load balancer and/or web servers) needs to be internet-facing and placed in public subnets. Application logic and database servers should be in private subnets with no direct internet access, reachable only from the web tier through internal routing.
3. All three tiers in public subnets with Security Groups restricting traffic between tiers

   Incorrect. Placing the database and application tiers in public subnets exposes them to the internet unnecessarily. Security Groups alone are not sufficient — defense-in-depth requires private subnets for internal components.
4. Web tier and application tier in public subnets; database tier only in a private subnet

   Incorrect. The application tier contains business logic and should not be internet-accessible. Placing the application tier in a public subnet violates the principle of defense-in-depth and unnecessarily expands the attack surface.

Web tier in public subnets for internet access; application and database tiers in private subnets for security — the standard AWS three-tier architecture pattern.

7. AWS WAF to block SQL injection and XSS at Layer 7: Which combination of AWS services addresses both requiremen

1. AWS Shield Standard to inspect and block SQL injection and XSS, and AWS WAF to mitigate large-scale volumetric DDoS attacks

   Incorrect. AWS Shield Standard only mitigates DDoS attacks and does not inspect application-layer traffic for SQL injection or XSS. AWS WAF handles Layer 7 threats but is not a volumetric DDoS mitigation service, so the roles are reversed here.
2. Amazon GuardDuty to block SQL injection and XSS in real time, and AWS Shield Standard for volumetric DDoS protection

   Incorrect. Amazon GuardDuty is a detection service that generates findings about suspicious activity and does not block traffic inline, so it cannot stop SQL injection or XSS requests as they arrive.
3. AWS WAF to block SQL injection and XSS at Layer 7, and AWS Shield Advanced for enhanced volumetric DDoS protection ✓

   Correct. AWS WAF inspects HTTP/HTTPS traffic at Layer 7 and can block SQL injection and XSS with managed or custom rules. AWS Shield Advanced provides enhanced DDoS protection including volumetric mitigation, 24/7 DDoS response team access, and cost protection.
4. AWS Network Firewall to handle both the SQL injection and XSS filtering and the volumetric DDoS attack mitigation

   Incorrect. AWS Network Firewall provides network-level (VPC) filtering and is not purpose-built for HTTP-layer web attacks like SQL injection and XSS, nor for absorbing large volumetric DDoS floods. WAF and Shield are the correct pairing.

AWS WAF blocks Layer 7 web attacks (SQL injection, XSS); AWS Shield Advanced provides DDoS volumetric attack protection — both are needed for comprehensive protection.

8. AWS Secrets Manager: Which AWS service best meets these requirements?

1. Amazon S3 with server-side encryption

   Incorrect. S3 is object storage and is not appropriate for storing and serving application secrets at runtime. S3 lacks built-in secret rotation capabilities, fine-grained secret-level access controls, and the runtime secret retrieval patterns that Secrets Manager provides.
2. AWS KMS (Key Management Service)

   Incorrect. AWS KMS manages encryption keys, not application secrets or database credentials. KMS is used to encrypt secrets stored elsewhere (including in Secrets Manager and Parameter Store), but it is not a secret storage service itself.
3. AWS Systems Manager Parameter Store

   Incorrect. While Parameter Store can store secrets (using SecureString parameters with KMS encryption), it does NOT natively support automatic secret rotation. Secrets Manager is the correct service when automatic rotation is required.
4. AWS Secrets Manager ✓

   Correct. AWS Secrets Manager is designed specifically for storing, rotating, and managing secrets including database credentials. It natively integrates with Amazon RDS to automatically rotate credentials on a schedule, and applications can retrieve secrets at runtime via the Secrets Manager API.

AWS Secrets Manager provides native automatic rotation for RDS credentials — Parameter Store can store secrets but does not natively auto-rotate them.

9. SSE-S3 , where S3 generates and manages the keys: Which S3 server-side encryption option should they use?

1. SSE-S3 (Server-Side Encryption with Amazon S3 managed keys), where S3 generates and manages the keys automatically ✓

   Correct. SSE-S3 uses AES-256 encryption where Amazon S3 manages all encryption keys on behalf of the customer. There is no key management overhead — S3 automatically generates, manages, and rotates the keys.
2. SSE-KMS (Server-Side Encryption with AWS KMS keys), where you create and manage the KMS keys and their access policies

   Incorrect. SSE-KMS uses AWS KMS to manage keys and adds an audit trail via CloudTrail, but it requires the customer to create, manage, and set policies for the KMS keys, which adds key management overhead.
3. SSE-C (Server-Side Encryption with Customer-Provided keys), where you supply the encryption key on every S3 request

   Incorrect. SSE-C requires the customer to provide the encryption key with every request. This is a high-overhead option because the customer is fully responsible for key storage and rotation.
4. Client-Side Encryption with the AWS SDK, where you encrypt objects before upload and manage all of the keys yourself

   Incorrect. Client-side encryption means the customer encrypts data before uploading to S3 and manages all keys. This is the maximum key management overhead and the opposite of what the requirement asks for.

SSE-S3 lets Amazon S3 manage all encryption keys transparently — zero key management overhead for the customer.

10. Use Amazon Cognito with a user pool for authentication: What is the recommended AWS solution?

1. Use AWS IAM Identity Center so millions of customers can sign in with their Google or Facebook credentials and receive scoped access to their S3 files

   Incorrect. AWS IAM Identity Center is built for workforce identity (employees accessing AWS accounts and enterprise apps). It is not designed to handle millions of external customer identities authenticating through consumer social providers.
2. Use AWS Directory Service to federate the Google and Facebook social logins with IAM and map them to S3 permissions

   Incorrect. AWS Directory Service is for enterprise Active Directory integration, not consumer social identity federation. Amazon Cognito is the correct service for customer-facing social sign-in.
3. Create an individual IAM user for every customer and embed that user's access keys in the distributed mobile application

   Incorrect. Creating IAM users for millions of external customers is not scalable and is a security anti-pattern (static credentials distributed in an app). IAM is meant for AWS account identities, not end-user authentication.
4. Use Amazon Cognito with a user pool for authentication and an identity pool that exchanges tokens for temporary AWS credentials ✓

   Correct. Amazon Cognito user pools handle user authentication including social identity federation with Google/Facebook. Cognito identity pools exchange the authenticated tokens for temporary AWS credentials via STS, letting users access their S3 files with appropriate permissions.

Amazon Cognito user pools authenticate customers (including social identity providers); identity pools exchange tokens for temporary AWS credentials to access S3.

11. S3 Object Lock in Compliance mode with a retention period: Which S3 Object Lock configuration meets this requi

1. S3 Object Lock in Governance mode with a retention period of 7 years

   Incorrect. In Governance mode, users with the s3:BypassGovernanceRetention permission can override the retention setting and delete objects before the retention period expires. This does not satisfy the 'no one including root' immutability requirement.
2. S3 Object Lock in Compliance mode with a retention period of 7 years ✓

   Correct. In Compliance mode, once an object's retention period is set, no user — including the root user or AWS — can overwrite or delete the protected object until the retention period expires. This is the strictest form of WORM (write-once-read-many) protection and satisfies regulatory immutability requirements.
3. S3 MFA Delete with a 7-year retention lifecycle policy

   Incorrect. S3 MFA Delete requires multi-factor authentication to delete objects or change versioning state, but it can still be overridden by the root user and does not provide the same level of regulatory compliance as Object Lock in Compliance mode.
4. S3 Versioning with lifecycle policies that prevent deletion for 7 years

   Incorrect. S3 Versioning allows administrators to restore deleted objects but does not prevent deletion. An account administrator with sufficient permissions can delete all versions of an object. Object Lock is required for true immutability.

S3 Object Lock in Compliance mode prevents deletion by ANY user including root — the only S3 feature that satisfies strict regulatory WORM requirements.

12. AWS Certificate Manager: Which AWS service simplifies the provisioning and management of the SSL/TLS certifica

1. AWS Certificate Manager (ACM) ✓

   Correct. ACM provisions, manages, and automatically renews SSL/TLS certificates for use with AWS services including ALB, CloudFront, and API Gateway. It eliminates the manual overhead of purchasing, uploading, and renewing certificates.
2. Amazon Inspector

   Incorrect. Amazon Inspector is a vulnerability assessment service that scans EC2 instances and container images for security vulnerabilities. It does not manage SSL/TLS certificates.
3. AWS KMS (Key Management Service)

   Incorrect. AWS KMS manages encryption keys for data at rest, not SSL/TLS certificates for in-transit encryption. ACM is the correct service for certificate management.
4. AWS Secrets Manager

   Incorrect. AWS Secrets Manager stores and rotates application secrets like database credentials. It can store custom certificates as secrets, but it is not designed for provisioning or managing public TLS certificates for load balancers.

AWS Certificate Manager (ACM) provisions and auto-renews SSL/TLS certificates for ALB, CloudFront, and other AWS services — eliminating certificate management overhead.

Other AWS Solutions Architect domains

• Design Resilient Architectures — 272 questions →
• Design High-Performing Architectures — 256 questions →
• Design Cost-Optimized Architectures — 208 questions →
• All 1061 AWS Solutions Architect questions →