Select Two (Multi-Select) Questions

Use EBS Snapshots to back up the database every 5 minutes.

Why it fails: While snapshots are important for disaster recovery, they do not provide high availability or low-latency reads. Restoring from a snapshot is a manual process that takes time, and taking snapshots every 5 minutes would create significant performance overhead on the database. It is not a replacement for the automated failover provided by Multi-AZ.

Enable Enhanced Monitoring with a 1-second granularity.

Why it fails: Enhanced Monitoring provides detailed metrics about the OS and processes running on the RDS instance. While helpful for troubleshooting performance issues, it does not contribute to the resilience of the database or provide any mechanisms for surviving an Availability Zone failure. It is a monitoring tool rather than an architectural availability feature.

Implement a Network Load Balancer in front of the RDS instance.

Why it fails: Network Load Balancers are used to distribute traffic to EC2 instances or IP addresses, but they are not typically used in front of Amazon RDS. RDS handles its own DNS-based failover for Multi-AZ. Adding an NLB would introduce unnecessary complexity and is not a standard or recommended practice for managing RDS database connections.

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 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.

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.

Place all EC2 instances in the public subnet to maximize accessibility.

Why it fails: Placing all instances in a public subnet exposes them directly to the internet, increasing the attack surface. Security best practices dictate that only necessary resources, like load balancers, should be public, while application and database tiers should reside in private subnets to isolate them from direct inbound traffic.

Configure Security Groups to allow all traffic (0.0.0.0/0) on all ports.

Why it fails: Allowing all traffic on all ports is a severe security risk that violates the principle of least privilege. Security groups should be configured with specific protocols and port ranges only for authorized traffic sources, ensuring that services are not exposed to unnecessary threats or unauthorized connections from the internet.

Disable VPC Flow Logs to reduce the storage costs in S3.

Why it fails: VPC Flow Logs are critical for security auditing and forensic analysis. Disabling them saves costs but obscures visibility into network traffic patterns. Best practices require keeping these logs enabled to monitor for anomalous traffic, troubleshoot security issues, and maintain a historical record of network activity for compliance and security reviews.

Configure Amazon S3 Intelligent-Tiering to automatically move infrequently accessed video assets to lower-cost storage tiers.

Why it fails: S3 Intelligent-Tiering optimizes storage costs by moving objects between access tiers based on access patterns, but it does not provide data protection mechanisms against accidental deletion, malicious overwrites, or complete regional service interruptions.

Attach a resource-based bucket policy that explicitly denies all delete object requests from any IAM user except the root account.

Why it fails: Denying delete requests via bucket policy prevents standard data maintenance and lifecycle operations, and relying solely on root account privileges violates AWS security best practices regarding least privilege access control for daily operational tasks.

Enable S3 Object Lock in governance mode with a fixed retention period of 30 days for all uploaded video files.

Why it fails: S3 Object Lock governance mode prevents users from changing or deleting object versions, but it can be bypassed by users with specific administrative permissions unless compliance mode is used, and it does not provide multi-region disaster recovery capabilities.

Data is preserved when the instance is stopped and started.

Why it fails: Data in an instance store volume is lost when the instance is stopped, terminated, or if the underlying hardware fails. This ephemeral nature is a key distinction from EBS, which persists data independently of the instance's lifecycle, necessitating a different strategy for data durability.

Volumes can be detached and reattached to different instances.

Why it fails: Unlike EBS volumes, which are network-attached and can be moved between instances, instance store volumes are fixed to a specific host. They cannot be detached or moved, which limits their flexibility but contributes to their superior local I/O performance characteristics.

Storage capacity can be increased without stopping the instance.

Why it fails: The size of the instance store is determined by the EC2 instance type and cannot be modified. If more instance store capacity is needed, the application must be migrated to a larger instance type, whereas EBS volumes allow for dynamic resizing via Elastic Volumes.

Use Multi-AZ deployments for all read-only workloads.

Why it fails: Multi-AZ deployments are primarily used for high availability and failover, not for cost optimization. In fact, Multi-AZ doubles the cost of the database because it provisions a standby instance in a different Availability Zone. For read-only workloads, Read Replicas are a better performance choice, though they also increase costs.

Switch to an Amazon RDS Custom for MySQL instance.

Why it fails: RDS Custom is designed for applications that require access to the underlying operating system or specific database settings not available in standard RDS. It does not provide cost savings and may actually increase operational overhead and licensing costs, making it a poor choice for a purely cost-focused optimization task.

Enable Provisioned IOPS (PIOPS) for all storage volumes.

Why it fails: Provisioned IOPS storage is more expensive than General Purpose SSD (gp3) storage. While PIOPS provides consistent, high-performance I/O, it should only be used when specific performance requirements cannot be met by gp3. Enabling it across all volumes would increase the monthly storage bill without necessarily providing a cost-benefit.

Amazon Macie enabled by default on all S3 buckets in member accounts.

Why it fails: While Amazon Macie is a valuable security service, it is not a standard component automatically enabled or managed by AWS Control Tower's core landing zone setup. Macie must be configured separately, although it can be integrated into a broader security strategy for a multi-account environment.

Amazon GuardDuty for automated threat detection across all accounts.

Why it fails: Amazon GuardDuty provides critical threat detection, but it is not one of the primary mechanisms used by Control Tower to enforce guardrails. GuardDuty is often managed at the AWS Organizations level, but it is considered a separate service from the core landing zone and guardrail features of Control Tower.

Amazon S3 with S3 Select.

Why it fails: S3 Select allows applications to retrieve only a subset of data from an object, which can improve performance for certain queries. However, S3 is not a POSIX-compliant file system and cannot provide the sub-millisecond local latency required for high-performance computing clusters.

Amazon FSx for Windows File Server.

Why it fails: While FSx for Windows provides a managed file system, it is optimized for Windows-based workloads and SMB protocols. It does not offer the same level of extreme parallel performance or the Linux-native POSIX optimization that Lustre provides for HPC applications.

Amazon EFS in General Purpose mode.

Why it fails: EFS is a versatile POSIX file system, but it is generally designed for content management and web serving. Even in Max I/O mode, it cannot match the specialized performance of FSx for Lustre or local Instance Store for high-performance computing workloads.

Place all microservices in a single public subnet to simplify routing.

Why it fails: Placing microservices in a public subnet exposes them to the internet, which is the opposite of zero-trust and secure architecture principles. Services should be in private subnets, and access should be strictly controlled through gateways and load balancers to minimize the available attack surface.

Disable VPC Flow Logs to reduce latency between microservices.

Why it fails: VPC Flow Logs have no impact on network latency as they are captured out-of-band. Disabling them would remove critical visibility and auditing capabilities needed to detect and investigate security incidents, which is essential for maintaining a secure and compliant zero-trust environment over time.

Allow all users in the organization to have full access.

Why it fails: Granting universal full access violates the principle of least privilege. Highly sensitive data must be protected with narrow, scoped permissions. Only users with an explicit business need should be allowed access, and this access should be strictly defined using IAM policies and resource-based policies.

Store data in a public bucket for easier access.

Why it fails: Storing sensitive data in a public bucket is a catastrophic security failure that exposes the data to the entire world. Sensitive information should never be public. This practice would immediately fail any security audit and result in a high risk of data exfiltration and severe regulatory consequences.

AWS Trusted Advisor.

Why it fails: Trusted Advisor provides high-level recommendations based on best practices, but it is not a tool for enforcing strict configuration compliance or automated remediation of software versions. It cannot be used to trigger termination actions on instances that fail to meet specific software version checks as requested by the auditor.

AWS CloudFront.

Why it fails: CloudFront is a content delivery network used to serve static and dynamic content globally. It has no role in managing EC2 instance software versions or enforcing compliance policies. Using CloudFront to attempt to manage instance state is technically irrelevant and will not fulfill the audit requirements described in the scenario.

Scale up the primary RDS instance to a larger instance class with more RAM.

Why it fails: Scaling up the primary instance is a vertical scaling strategy that increases the cost of the entire database 24/7. Since the write activity is low, paying for a larger instance just to handle peak read traffic is inefficient compared to using Read Replicas, which can be scaled more granularly.

Switch the database to Amazon RDS for SQL Server to take advantage of License Inclusion.

Why it fails: Switching to SQL Server from MySQL would likely increase costs due to licensing fees and architectural changes. MySQL is an open-source engine with no licensing costs. Moving to a commercial engine would be counterproductive for a project specifically focused on reducing the overall cost of the database layer.

Enable Multi-AZ for all Read Replicas to ensure high availability.

Why it fails: Enabling Multi-AZ on Read Replicas doubles the cost of each replica because AWS provisions a standby instance. While this improves availability, it is often unnecessary for read-only traffic that can be rerouted if a replica fails, making it a poor choice for a strategy focused strictly on cost reduction.

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.

Support for multi-threaded execution.

Why it fails: Redis is primarily a single-threaded engine for command execution, although recent versions have introduced some background threading for I/O. Memcached is typically the choice for multi-threaded performance, but it lacks the complex data structures and high availability features like Multi-AZ and replication required in this scenario.

Automatic data compression at the cache level.

Why it fails: Amazon ElastiCache does not provide native automatic data compression at the service level. Compression is typically handled by the application code before the data is sent to the cache. Relying on the cache for compression would introduce unnecessary latency and CPU overhead on the cache nodes.

Use of UDP protocol for low-latency writes.

Why it fails: Redis uses the TCP protocol to ensure reliable delivery of data and commands. While UDP can be faster in some networking contexts, it is not supported by ElastiCache for Redis because reliability and data integrity are paramount for a persistent data store and caching engine.

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.

AWS CloudTrail.

Why it fails: CloudTrail is a service that records API calls and account activity for security, auditing, and compliance. While it tells you who created a resource, it does not provide analysis of resource utilization or cost-saving recommendations, making it the wrong tool for identifying idle resource waste.

Amazon Inspector.

Why it fails: Amazon Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS. It focuses on finding vulnerabilities and deviations from best practices in security, not on cost optimization or identifying idle infrastructure resources.

Use a single large EC2 instance instead of multiple smaller ones.

Why it fails: Relying on a single large instance creates a single point of failure. If that instance fails, the application goes down immediately. Using multiple smaller instances in a load-balanced configuration is significantly more resilient because the failure of one instance does not result in total service downtime for the application's users.

Place all instances in a single Auto Scaling group with a fixed capacity.

Why it fails: Fixed capacity does not allow the application to adapt to changes in traffic demand or recover from unexpected instance termination as effectively as dynamic scaling policies. While it provides basic capacity, it lacks the elasticity needed to maintain resilience during high-demand events or when multiple instances fail simultaneously due to issues.

AWS Systems Manager Parameter Store

Why it fails: Parameter Store can store encrypted strings and is often used for configuration data. While it is cost-effective, it does not have native, built-in rotation logic for databases like Secrets Manager does. Implementing rotation in Parameter Store would require significantly more custom code and management effort.

AWS Key Management Service (KMS)

Why it fails: KMS is used to provide the underlying encryption keys for Secrets Manager, but it does not handle the storage of the secret values themselves or the rotation logic. It is a supporting service rather than the primary solution for managing database credential lifecycles.

Amazon DynamoDB

Why it fails: DynamoDB is a NoSQL database service and is not intended for secure credential management or automated secret rotation. While it could theoretically store encrypted data, it lacks the specialized features for secret lifecycle management, versioning, and integration with rotation functions that Secrets Manager provides.