Design Secure Architectures practice questions

Access is allowed because the first statement grants GetObject permissions for the whole bucket.

Why it fails: The allow statement for the app-logs bucket specifically covers the GetObject action for all objects within that resource. Without a corresponding deny, this would grant access to every file, but the presence of the second statement creates a more restrictive environment for the specified sub-path.

Access is denied because the policy does not include the s3:PutObject permission.

Why it fails: IAM policies prioritize permissions based on the most restrictive rule found across all applicable identity-based and resource-based policies. The lack of PutObject permission is irrelevant to this scenario, as the user is only attempting to download a file, which is governed by the GetObject action.

Access is allowed because the ListBucket action permits viewing all objects in the bucket.

Why it fails: The ListBucket action is separate from the GetObject action and only allows the user to see the names of the files within the bucket. It does not grant the ability to read the content of the files, which is governed by the specific object-level permissions defined.

Create an IAM policy for the administrator that explicitly denies all kms:Decrypt actions.

Why it fails: IAM policies can grant access to KMS keys, but they only work if the key policy explicitly allows the account to use IAM. If the key policy is restricted to specific users and excludes the root account access statement, IAM policies alone cannot grant access to those who are not listed.

Grant the administrator 'kms:*' permissions in the key policy but use a condition to restrict access to their IP address.

Why it fails: Granting access to the root user is a common practice to prevent becoming locked out of a key, but it violates the principle of least privilege in high-security environments. If the administrator has root access, they can perform any action, including decrypting sensitive data, which bypasses the intended separation of duties.

Use a KMS key alias and only grant the application permission to access the alias.

Why it fails: Using an alias for the KMS key simplifies key management by allowing applications to refer to a friendly name instead of a key ID. However, aliases do not provide any security or access control benefits; they still rely on the underlying key policy and IAM permissions to govern access.

Configure Amazon S3 default encryption using Amazon S3 managed encryption keys (SSE-S3).

Why it fails: Amazon S3 managed encryption keys utilize master keys managed entirely within the S3 service boundary rather than AWS Key Management Service, which prevents administrative auditing through AWS CloudTrail and fails customer requirements for explicit key control.

Implement client-side encryption using custom keys stored locally on the user's workstation.

Why it fails: Client-side encryption with locally stored keys places the burden of key lifecycle management, backup, and rotation on the end-user, introducing severe operational risks of permanent data loss if keys are misplaced or compromised.

Enable S3 Bucket Versioning and enforce multi-factor authentication delete operations.

Why it fails: While S3 Bucket Versioning and MFA Delete protect data integrity and prevent accidental or malicious object deletions, they do not provide encryption at rest or cryptographic key management capabilities mandated by security policies.

The S3 bucket policy lacks explicit permission for the AWS Lambda service principal in the Principal element.

Why it fails: While the Principal element specifies a wildcard, the policy evaluates evaluation logic correctly for requests. The root cause is the mismatch between the source IP condition and the private IP address utilized by VPC endpoints.

The Action element uses a wild-card s3:* which is prohibited by AWS security guardrails for production storage buckets.

Why it fails: Wildcards in the Action element are fully valid syntax in IAM and bucket policies. Although broad, they do not cause access denials specifically related to IP address evaluations originating from inside virtual private clouds.

Amazon S3 bucket policies do not support IP-based conditional evaluations for compute resources such as Lambda functions.

Why it fails: S3 bucket policies fully support aws:SourceIp conditional evaluations. However, they evaluate the IP address presented by the immediate connection source, which for VPC traffic is the endpoint IP rather than the originating client IP.

Internet Gateway

Why it fails: An Internet Gateway is used to allow communication between resources in your VPC and the public internet. Since the requirement specifically states that the connection must not traverse the public internet, an Internet Gateway is not appropriate for this secure, private connectivity solution.

NAT Gateway

Why it fails: A NAT Gateway allows instances in a private subnet to connect to the internet or other AWS services but prevents the internet from initiating connections with those instances. It is an internet-facing component and does not facilitate private, high-bandwidth connectivity to an on-premises data center.

AWS Client VPN

Why it fails: AWS Client VPN is a managed client-based VPN service that enables users to securely access AWS resources and their on-premises network. It is designed for individual remote workers rather than a high-bandwidth, consistent site-to-site connection between a data center and a VPC.

AWS CloudWatch Logs in each account.

Why it fails: While CloudWatch Logs is useful for monitoring, it is not centralized by default. Manually configuring it in every account is inefficient and prone to configuration drift. A central logging account using Organization-level trails is the standard architecture for centralized security management across a large AWS environment.

AWS Config with local S3 buckets.

Why it fails: AWS Config is designed for tracking resource configuration changes, not for comprehensive API activity logging like CloudTrail. Storing logs in local buckets across accounts fails to provide the centralized aggregation required for efficient security analysis. This approach creates silos of information that are difficult to manage and monitor.

AWS GuardDuty configured per account.

Why it fails: GuardDuty is a threat detection service, not a log aggregation service. While it can be centrally managed, it does not replace the need for an immutable, centralized log storage solution like CloudTrail in S3. GuardDuty analyzes existing logs but does not perform the primary task of archiving logs securely.

Enable Amazon S3 Managed Keys (SSE-S3).

Why it fails: SSE-S3 uses keys managed entirely by AWS. While it provides encryption at rest, it does not allow the customer to manage or rotate the keys. The requirement explicitly asks for full control over key rotation, which makes this option insufficient for the company's specific security compliance needs.

Configure S3 Bucket Policies to enforce the 'aws:SecureTransport' condition.

Why it fails: This condition enforces encryption in transit, not encryption at rest. While it is a good security practice, it does not address the requirement for key management or data-at-rest encryption. The question specifically asks about controlling key rotation, which is a key management function, not a network security function.

Enable versioning on the S3 bucket to ensure historical key state preservation.

Why it fails: S3 versioning protects against accidental object deletion or overwriting but has no relevance to the encryption of data at rest or the management of KMS keys. It is a data availability feature rather than a security configuration for cryptographic key control and management.

Configure AWS Inspector to perform network reachability assessments on all EC2 instances.

Why it fails: AWS Inspector is an automated vulnerability management service that scans EC2 instances, container images, and Lambda functions for software vulnerabilities and unintended network exposure. While it provides deep insights into host-level security, it does not analyze network flow patterns or DNS logs to detect real-time behavioral anomalies.

Deploy AWS Shield Advanced to protect all public-facing endpoints from DDoS attacks.

Why it fails: AWS Shield Advanced provides expanded DDoS protection for applications running on EC2, ELB, and CloudFront. While it protects against infrastructure and application layer attacks, it does not provide the behavioral analysis of VPC flow logs or DNS queries required to identify compromised internal resources or data exfiltration.

Use AWS Config to monitor changes in security group rules and VPC configurations.

Why it fails: AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. While it is excellent for ensuring compliance with security best practices, it does not perform behavioral analysis or threat detection based on network traffic logs or active DNS queries.

Use Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3) for all buckets.

Why it fails: Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3) uses the AES-256 algorithm to protect data at rest. While this is the simplest method to implement, it does not allow for granular key management or provide the security team with the control needed to audit specific key usage.

Implement client-side encryption using a third-party library before uploading objects.

Why it fails: Client-side encryption ensures data is encrypted before it leaves the application environment, but it places a heavy management burden on the development team. This method is highly secure but significantly increases architectural complexity and makes it difficult for the security team to centrally manage and rotate keys.

Enable Server-Side Encryption with Customer-Provided Keys (SSE-C) for all uploads.

Why it fails: SSE-C requires the customer to manage the encryption keys and provide them with every request to S3. While this offers maximum control, it introduces significant operational overhead and risk, as the customer is entirely responsible for the secure storage and availability of the keys outside of AWS.

Add a deny rule to the web tier Security Group for CIDR 192.0.2.0/24.

Why it fails: Security Groups are stateful and function at the instance level, but they do not support explicit deny rules. They only allow traffic that is explicitly permitted, making them unsuitable for blocking specific IP ranges while maintaining a broad open port for the rest of the public internet.

Configure AWS Shield Standard to automatically block the 192.0.2.0/24 subnet.

Why it fails: AWS Shield Standard provides automatic protection against common infrastructure-level DDoS attacks at no additional cost. However, it does not offer the ability to manually configure custom deny rules for specific IP addresses, as it is designed for automated mitigation of known volumetric and protocol-based threats.

Update the VPC Route Table to blackhole all traffic destined for 192.0.2.0/24.

Why it fails: Route tables determine where network traffic is directed but do not have the capability to filter or block traffic based on security criteria. Using route tables to manage security would lead to complex and unmanageable routing configurations that do not provide actual security enforcement against malicious IPs.

Store IAM user credentials in a configuration file on the EC2 instance.

Why it fails: Storing long-term credentials in configuration files is a significant security risk, as anyone with access to the file system can compromise the account. If the instance is breached or the code is shared, the credentials could be used maliciously to access sensitive data across the AWS environment.

Pass the Access Key and Secret Key as environment variables when starting the application.

Why it fails: Using environment variables to store credentials is slightly better than configuration files but still leaves the keys vulnerable to exposure through process monitoring tools or logs. This method still relies on long-term credentials that must be manually rotated, which increases the operational burden and risk.

Embed the credentials directly into the application source code.

Why it fails: Hardcoding credentials into source code is one of the most dangerous security practices. If the code is pushed to a version control system like GitHub, the credentials can be easily discovered by unauthorized parties, leading to full account compromise and potential data theft from the DynamoDB table.

IAM Policies attached to each administrative user in every member account.

Why it fails: IAM policies are used to grant permissions to users and roles within a single account but cannot be used to enforce global restrictions across an entire organization. Relying on individual account policies is unscalable and prone to configuration drift, making it difficult to maintain a consistent security posture.

AWS Resource Access Manager (RAM) to share authorized services across accounts.

Why it fails: AWS Resource Access Manager (RAM) is designed to simplify the sharing of resources like subnets or License Manager configurations across accounts. While it facilitates resource sharing, it does not provide the governance or restrictive capabilities needed to block unauthorized services or regions across an organization.

AWS Config rules to automatically terminate resources in unauthorized regions.

Why it fails: AWS Config can detect non-compliant resources and trigger automated remediation, but it is a reactive measure rather than a proactive restriction. Using SCPs is a more robust approach because they prevent the creation of unauthorized resources in the first place, rather than cleaning them up after they exist.

Configure S3 Object Lock in compliance mode on the centralized logging bucket.

Why it fails: S3 Object Lock prevents objects from being deleted or overwritten for a fixed period or indefinitely, but it does not provide cryptographic hashing or digital signatures to verify if the file contents were altered during transit or storage.

Use AWS KMS customer managed keys with automatic key rotation enabled for S3 bucket encryption.

Why it fails: AWS KMS encryption protects data at rest in Amazon S3 against unauthorized physical access or disclosure, but it does not generate digest files or cryptographic signatures to prove log file integrity or detect post-delivery tampering.

Enable Amazon S3 Versioning on the centralized logging bucket to preserve previous object iterations.

Why it fails: Versioning preserves prior object iterations but provides no cryptographic integrity proof; it cannot detect tampering of a delivered log. It is tempting because versioning aids recovery from accidental overwrites or deletions, which is its actual purpose, but the mandate requires digest validation, not object history.

Apply an IAM policy to every developer user in each account that denies s3:CreateBucket in restricted regions.

Why it fails: IAM policies attached to users only restrict those specific identities within a single account. They cannot override permissions granted to other users or the root user, nor can they enforce a consistent security posture across multiple accounts in an AWS Organization effectively without significant management overhead and risk.

Configure an S3 bucket policy on all existing buckets to prevent the creation of new buckets in other regions.

Why it fails: Resource-based policies, such as S3 bucket policies, are specific to individual resources and do not provide a mechanism for broad service restrictions across an account. While they can deny access to a specific bucket, they cannot prevent a user from creating new resources in unauthorized AWS regions.

Enable AWS Config in all accounts and create a custom rule to delete any bucket created in a restricted region.

Why it fails: AWS Config rules are used to monitor and evaluate the configuration of your AWS resources for compliance. While they can trigger automated remediation via Lambda or Systems Manager, they do not prevent the initial creation of resources, making them a detective control rather than a preventative security measure.

Enable S3 Versioning on the bucket to keep a history of all changes made to the logs.

Why it fails: S3 Versioning is a prerequisite for Object Lock but does not inherently prevent the deletion of objects. A user with sufficient permissions can still delete specific versions or the entire object. Versioning provides a way to recover from accidental changes but does not enforce a strict, immutable retention period.

Use S3 Glacier Deep Archive as the storage class for the logs with a vault lock policy.

Why it fails: S3 Glacier Deep Archive is a cost-effective storage class for long-term data retention, but it does not provide immutability on its own. While it supports vault lock policies, it is primarily designed for data that is rarely accessed and requires several hours for retrieval, which may not fit all use cases.

Configure AWS Backup to take daily snapshots of the S3 bucket and store them in a secure vault.

Why it fails: AWS Backup provides centralized backup management and can protect S3 data, but it operates as a separate service rather than a native bucket-level immutability feature. While it offers recovery points, it does not prevent the original data from being modified or deleted before the next scheduled backup occurs.

Configure the EC2 security group to allow inbound traffic from 0.0.0.0/0 on port 80 to handle web traffic.

Why it fails: Opening the EC2 security group to the entire internet (0.0.0.0/0) is a security risk and unnecessary when using an ALB. The ALB handles public traffic and forwards it to the instances. The instances are in a private subnet and should only accept traffic from the ALB itself.

Configure the RDS security group to allow outbound traffic to the EC2 instances on all ports.

Why it fails: Security groups are stateful, meaning if an inbound request is allowed, the outbound response is automatically permitted regardless of outbound rules. Therefore, explicitly configuring outbound traffic from the RDS to the EC2 instances is redundant and does not follow the best practice of restricting outbound traffic to known destinations.

Configure the ALB security group to allow inbound traffic from the EC2 security group on port 80.

Why it fails: The traffic flow is from the ALB to the EC2 instances, not the other way around. The ALB security group needs to allow inbound traffic from the internet or clients, while its outbound rules should permit traffic to the EC2 instances. This suggestion reverses the required logic for the architecture.

Access is allowed because the policy grants s3:GetObject permissions to the bucket.

Why it fails: While the policy does grant s3:GetObject permissions, the condition block must also be satisfied for the permission to take effect. Since the user's IP address (198.51.100.5) is not within the specified 203.0.113.0/24 range, the Allow statement is not applicable to this specific request.

Access is allowed because there is no explicit Deny statement in the policy.

Why it fails: AWS IAM uses an implicit deny by default, meaning that if no policy explicitly allows an action, the action is denied. Although there is no explicit Deny statement, the Allow statement only functions when the condition is met. Since the condition is failed, the request is not authorized.

Access is denied because the policy does not include permissions for the s3:ListBucket action.

Why it fails: The s3:ListBucket permission is required to see the contents of a bucket, but s3:GetObject is the specific permission needed to download or read an individual object. The lack of ListBucket does not inherently prevent GetObject if the full path to the object is already known by the user.

AWS Systems Manager Parameter Store with SecureString parameters.

Why it fails: Parameter Store is a valid choice for storing configuration data and secrets, but it does not offer built-in, automated rotation for database credentials. Secrets Manager is the specialized service for this requirement, providing a more robust and native integration for rotation logic compared to the manual processes needed with Parameter Store.

AWS Key Management Service (KMS) to encrypt the environment variables.

Why it fails: AWS KMS is used to create and manage cryptographic keys to encrypt data, but it is not a secret storage service. While it can be used to encrypt credentials stored in environment variables, it does not handle the lifecycle management or the automatic rotation of the underlying secrets themselves.

AWS Identity and Access Management (IAM) roles for the Lambda function.

Why it fails: IAM roles provide temporary security credentials for AWS service requests but do not store third-party or database-specific credentials like MySQL passwords. While IAM should be used to give Lambda permission to access Secrets Manager, it cannot replace the need for a dedicated secret management and rotation service.

Amazon GuardDuty to identify and block malicious traffic at the VPC level.

Why it fails: Amazon GuardDuty is a threat detection service that monitors for malicious activity and unauthorized behavior within your AWS accounts. While it can identify that an attack is occurring, it is a detective service rather than a real-time mitigation tool designed to block high-volume DDoS traffic at the edge.

Amazon Inspector to scan EC2 instances for vulnerabilities during the attack.

Why it fails: Amazon Inspector is an automated vulnerability management service that scans EC2 instances and container images for software vulnerabilities and unintended network exposure. It is a proactive security tool used for assessment, but it does not provide active protection or mitigation capabilities against an ongoing DDoS attack.

AWS PrivateLink to hide the application from the public internet.

Why it fails: AWS PrivateLink provides private connectivity between VPCs, AWS services, and on-premises networks without exposing traffic to the public internet. While it improves privacy, it is not a solution for a public-facing application that must remain accessible to general users over the internet during a DDoS attack.

Amazon GuardDuty to monitor S3 data plane events for suspicious activity.

Why it fails: Amazon GuardDuty is excellent for detecting threats like compromised credentials or unusual data access patterns in S3. However, it does not scan the actual content of the files to identify PII or sensitive data. Macie is specifically designed for content discovery, whereas GuardDuty focuses on behavior.

AWS Glue to crawl S3 buckets and catalog the data types found in the files.

Why it fails: AWS Glue is an ETL and data cataloging service used for preparing data for analytics. While it can crawl S3 buckets to determine schema and metadata, it is not a security tool and does not have the specialized machine learning models required to identify sensitive PII for security auditing purposes.

Amazon Inspector to perform deep packet inspection on data uploaded to S3.

Why it fails: Amazon Inspector focuses on scanning EC2 instances, Lambda functions, and ECR images for vulnerabilities and network exposure. It does not have the capability to scan S3 buckets or analyze the content of objects for sensitive information like credit card numbers, which is the primary function of Macie.