Select Two (Multi-Select) Questions

Network connectivity issues

Why wrong: Network connectivity issues are classified as system status check failures because they typically originate from AWS-side infrastructure, such as loss of power, network link outages, or routing problems. Instance status checks, on the other hand, monitor the health of the guest OS and applications, so a problem that is purely external to the instance would not trigger a failed instance status check. Therefore, while network issues may make the instance unreachable, they would be indicated by a system status check, not the instance status check the administrator is troubleshooting.

Detached EBS root volume

Why wrong: A detached EBS root volume would prevent the instance from booting or accessing the operating system entirely, but this scenario is detected by AWS as a system status check failure because the problem lies in the underlying storage attachment infrastructure. The instance status check cannot even begin to run if the root volume is not available, as the OS never loads enough to respond to health checks. Thus, a detached root volume is not a valid cause of an instance status check failure, which requires the OS to be running but unhealthy internally.

Insufficient memory for applications

Why wrong: Insufficient memory for applications can cause performance degradation, swapping, or application crashes, but the Linux or Windows kernel typically remains responsive enough to answer the health probes used by instance status checks. These checks depend on basic OS functionality, such as the network stack and process scheduler, which do not necessarily require sufficient memory for user applications. Therefore, while low memory is a serious problem, it would not directly cause an instance status check failure unless it leads to a kernel panic, which is not the typical outcome.

Amazon GuardDuty

Why wrong: GuardDuty is a threat detection service, not a logging service.

AWS Config

Why wrong: Config tracks resource configuration changes, not API calls.

VPC Flow Logs

Why wrong: Flow Logs capture IP traffic, not API calls.

Use PutLogEvents directly from the application.

Why wrong: This bypasses the agent's buffering and retry logic, likely making the problem worse.

Reduce the retry count for failed requests.

Why wrong: Reducing retries increases data loss if transient failures occur.

Increase the batch timeout to 30 seconds.

Why wrong: Longer timeouts increase the risk of buffer overflow and data loss if logs are generated rapidly.

Add a DependsOn attribute to the Auto Scaling group resource that lists only the ALB resource.

Why wrong: This would not wait for the RDS database.

Add an UpdatePolicy to the Auto Scaling group resource to wait for a signal.

Why wrong: UpdatePolicy is for updates, not initial creation.

Add a CreationPolicy to the Auto Scaling group resource to wait for a signal from the instances.

Why wrong: This is for instances within the group, not for the group resource itself.

Move all instances to private subnets and use AWS Direct Connect for user access.

Why wrong: Direct Connect is a paid service and may increase costs.

Use an Application Load Balancer to distribute traffic.

Why wrong: ALB does not inherently reduce data transfer costs.

Use a larger NAT Gateway to improve throughput.

Why wrong: Larger NAT Gateway increases costs.

Internet gateway

Why wrong: Not required for VPN; VPN uses the virtual private gateway.

Direct Connect virtual interface

Why wrong: Used for dedicated connection, not VPN.

VPC Peering connection

Why wrong: VPC Peering does not provide internet access.

Private subnet route table with a route to the Internet Gateway

Why wrong: This would make the subnet public.

Internet Gateway attached to the VPC

Why wrong: Internet Gateway alone makes subnets public if routes exist.

Use AWS DataSync to sync the database files to Amazon S3.

Why wrong: AWS DataSync is designed to transfer large volumes of files between on-premises storage and AWS, but it operates as a batch, file-based service rather than a continuous transaction-level replication engine. Copying raw database files to Amazon S3 with DataSync would not produce a transactionally consistent, ready-to-use database, and the sync interval would almost certainly exceed the required 1-hour RPO. Furthermore, restoring from S3 snapshots would add significant manual steps, failing the RTO of under 4 hours.

Configure the RDS instance with Multi-AZ.

Why wrong: Incorrect: Multi-AZ is a high-availability feature that provides automatic failover within a single AWS Region. It does not protect against Region failures or on-premises disasters, and therefore does not meet the disaster recovery requirements for the on-premises database.

Create IAM users and assign them permissions to access the bucket.

Why wrong: Creating IAM users and granting them S3 permissions controls which identities can access the bucket, but it does not restrict the network location from which those identities make requests. A user with valid IAM credentials could still call s3:GetObject from any IP address or VPC, bypassing the intended VPC restriction entirely. To enforce the required network-level isolation, you need a bucket policy with a vpc:SourceVpce condition, which is independent of any IAM user setup.

Attach a security group to the S3 bucket.

Why wrong: Security groups are virtual firewalls that operate at the elastic network interface (ENI) level for EC2 instances and other resources like RDS or Lambda, not for S3 buckets, which are regional services without a VPC CIDR to apply a security group to. Even when using a VPC interface endpoint for S3, the security group attaches to the endpoint's ENI, not to the bucket itself. Therefore, attaching a security group to the S3 bucket is impossible and irrelevant; bucket policies or IAM policies are the correct enforcement mechanisms.

aws:SourceSubnet equals the subnet ID.

Why wrong: Not a valid condition key.

aws:SourceArn equals the IAM role ARN.

Why wrong: Identifies the role.

aws:SourceIp equals the VPC CIDR.

Why wrong: Not recommended for VPC.

Manual DB snapshots.

Why wrong: Manual DB snapshots, while useful for creating a known-good backup at a specific point in time, require an administrator to explicitly initiate the snapshot operation through the console, CLI, or API. They are not automated by default and do not provide the continuous, scheduled backup capability that the scenario demands; relying on them would introduce a manual process that could be skipped or delayed, undermining the reliability of the backup strategy.

Cross-region read replicas.

Why wrong: Cross-region read replicas are primarily designed to offload read traffic and improve application read latency by maintaining an asynchronous copy of the source DB instance in another Region. Although read replicas can be manually promoted to a standalone instance in a disaster, they do not serve as a backup mechanism because they inherit the source's data changes in near-real-time and are subject to replication lag; they lack the versioned, restorable snapshot history that a true backup solution provides.

Amazon S3 lifecycle policies.

Why wrong: Amazon S3 lifecycle policies are designed to manage the lifecycle of objects stored in S3 buckets, such as transitioning data to S3 Standard-IA, Glacier, or deleting objects after a defined period. They do not interact with RDS snapshots because RDS backup data is managed internally by the RDS service and is not directly accessible as S3 objects; applying an S3 lifecycle policy would have no effect on RDS backup retention or cross-Region replication.

Apply network ACLs with deny rules

Why wrong: Network ACLs (NACLs) are stateless firewall rules applied at the subnet level that allow inbound and outbound traffic filtering, but they are fundamentally ill-suited for DDoS mitigation. Because they are stateless, you must explicitly define return traffic rules, and they cannot dynamically adapt to a changing attack pattern or perform rate-based throttling. NACLs also inspect traffic on a per-packet basis without any capacity to absorb or filter high-volume floods, as the attack traffic will saturate the network pipe before NACL rules can effectively block it.

Use restrictive security groups

Why wrong: Security groups act as a stateful, instance-level firewall that can restrict traffic based on source IP, port, and protocol, but they are not designed to mitigate distributed denial-of-service attacks. A DDoS flood typically overwhelms the network infrastructure or application bandwidth before traffic reaches the ENI where the security group is evaluated, so the security group cannot prevent the resource exhaustion. Moreover, security groups lack the ability to perform rate-based monitoring or apply adaptive blocking rules, making them useful for access control but insufficient as standalone DDoS protection.

Enable VPC Flow Logs

Why wrong: VPC Flow Logs capture metadata about IP traffic flowing through your VPC, such as source/destination addresses, ports, and packet counts, but they are a passive observability feature rather than an active security control. They do not block, filter, or modify any traffic in real time; they only generate log records after the traffic has already occurred. While flow logs can help you analyze attack patterns post-incident or fine-tune other defenses, they provide zero mitigation capability against an ongoing DDoS attack.

s3:SourceVpce

Why wrong: s3:SourceVpce is not a recognized condition key; the correct prefix for VPC endpoint conditions is aws:SourceVpce, not s3:. S3-specific condition keys use the s3: prefix (e.g., s3:prefix, s3:max-keys), but SourceVpce is not among them, so this option is invalid and would cause a policy error if used.

aws:SourceIp

Why wrong: aws:SourceIp restricts based on the source IP address, but it cannot guarantee that a request originates from a particular VPC because VPC traffic can traverse public IPs or NAT gateways. This condition key is useful for IP-based access control, but it does not validate the VPC context, so it fails to meet the requirement of restricting to a specific VPC.

ec2:Vpc

Why wrong: ec2:Vpc is not a valid condition key in S3 bucket policies; S3 only recognizes a limited set of condition keys, including those prefixed with s3: and AWS-wide keys like aws:SourceVpc. The ec2 namespace is reserved for EC2-specific conditions, but ec2:Vpc is not a defined key, and even if it were, S3 bucket policies would not evaluate it.

VPC Flow Logs

Why wrong: VPC Flow Logs capture network traffic, not API calls.

Amazon Inspector

Why wrong: Amazon Inspector assesses vulnerabilities, not API calls.

AWS Config

Why wrong: AWS Config records resource configuration changes, not API calls.

Place a CloudFront distribution in front of the instances.

Why wrong: CloudFront caches content but does not provide load balancing or failover across AZs.

Launch all EC2 instances in a single Availability Zone for consistency.

Why wrong: A single AZ is a single point of failure.

Attach an EBS volume to each instance and replicate data in real-time.

Why wrong: EBS volumes are AZ-specific; replication does not provide high availability for the application layer.

Amazon GuardDuty

Why wrong: GuardDuty is for threat detection.

AWS Trusted Advisor

Why wrong: Trusted Advisor provides recommendations, not auditing.

Enable AWS CloudTrail to log all API calls.

Why wrong: CloudTrail logs events but does not enforce encryption.

Configure EC2 security groups to only allow HTTPS traffic.

Why wrong: Security groups apply to EC2 instances, not API calls.

Create an IAM policy that denies access unless the request uses TLS 1.2.

Why wrong: IAM policies do not have a condition for TLS version.

Set the AMI ID in a CloudFormation template and associate it with the environment.

Why wrong: Elastic Beanstalk does not use CloudFormation templates for AMI selection.

Use AWS CodeDeploy to deploy the application to the custom AMI.

Why wrong: CodeDeploy is for application deployment, not for creating custom AMIs.

Use Packer to create the custom AMI from any base image.

Why wrong: Must use the Elastic Beanstalk platform as base to avoid issues.

Use larger EC2 instance types.

Why wrong: Larger instances improve performance, not availability.

Use a single AWS Region for all instances.

Why wrong: Single region does not provide regional fault tolerance.

Place all EC2 instances in a single subnet.

Why wrong: Single subnet is a single point of failure.

NAT Gateway

Why wrong: A NAT Gateway provides outbound internet connectivity for instances in private subnets, translating their traffic to a public IP. It does not handle inbound user traffic, nor does it manage instance health or capacity. While a NAT gateway itself is highly available within its AZ, it does not directly support high availability of the web or application tiers in this deployment.

Amazon S3 bucket

Why wrong: Amazon S3 is a regional object storage service, not a compute resource. It can host static website content or serve as an asset store, but it cannot run the web or application tier, nor does it provide automatic failover or instance replacement. Therefore, it does not contribute to high availability of the compute layers in this architecture.

Amazon Route 53 hosted zone

Why wrong: Incorrect. A Route 53 hosted zone manages DNS records and can be used for routing traffic, but the primary resources for high availability across AZs are the Auto Scaling group and Application Load Balancer. While Route 53 can support DNS-level failover, it is not a direct infrastructure resource within the CloudFormation template for this purpose.