Infrastructure Security practice questions

Place all tiers in public subnets and use security groups to restrict traffic.

Why it fails: Placing all tiers in public subnets with internet gateways means every instance—including application and database servers—receives a public IP and a direct route to the internet, defeating network isolation. Security groups act as stateful firewalls, but they are not a substitute for subnet-level privacy; any misconfigured rule or application vulnerability can expose sensitive layers. Defense in depth requires limiting internet reachability to only the web tier while keeping app and data tiers in private subnets.

Place the web and app tiers in public subnets and the database in a private subnet.

Why it fails: Putting both web and application tiers in public subnets is wrong because the app tier does not need to be publicly reachable and should be shielded from direct internet traffic. An internet gateway attached to the app tier's subnet exposes application logic, APIs, and any underlying services to the internet, greatly increasing the attack surface. The correct pattern is to keep the app tier in a private subnet with a security group that only allows inbound traffic from the web tier, and reserve public subnets for the web-facing load balancer or web servers.

Place all tiers in private subnets and use a single security group to allow traffic between them.

Why it fails: If all tiers—including the web tier—are placed in private subnets, there is no internet gateway, so the web tier cannot receive inbound user requests from the internet, breaking the application's accessibility. Additionally, using a single security group for all instances allows broad, unfiltered traffic between every tier, violating the principle of least privilege and enabling lateral movement if one tier is compromised. Each tier should have its own security group with narrowly scoped rules, and only the web tier should reside in a public subnet with an internet gateway.

The policy allows access to all EC2 actions, but the condition only applies to the ec2:* actions, which includes all EC2 actions.

Why it fails: The action element uses a wildcard `ec2:*`, which nominally covers all EC2 API actions, but the attached `aws:SourceIp` condition is evaluated for every request that matches that action set. The condition is not optional or scoped away by the wildcard; rather, it applies to all actions listed in the statement, so a request from outside the allowed IP range is denied by this statement. Thus, merely having a broad action list does not explain why access is granted from outside the network, because the condition still restricts the source IP. The only way this statement alone could allow external access would be if the condition were removed or if another statement supersedes its effect.

The aws:SourceIp condition key does not apply to API calls made through the AWS Management Console; the console uses AWS IP addresses.

Why it fails: It is true that the `aws:SourceIp` condition key has no effect when the request is made through the AWS Management Console, because the console relays the request using AWS service IP addresses rather than the user's source IP. However, in that case the condition would not evaluate true, so the Allow in this statement would not be granted; instead, the request would fail unless there is a separate Allow. Therefore, this option cannot explain why users are successfully performing EC2 actions from outside the network, because it actually predicts a denial for console users. The only way to explain the observed permissions is that an additional, unconditional Allow policy is in effect.

The policy should use a NotIpAddress condition instead of IpAddress.

Why it fails: Using a `NotIpAddress` condition would not resolve the fundamental issue; the condition would still fail for console requests and for requests from outside the network. The observed behavior is better explained by an additional policy.

EBS encryption: Encryption is applied at the application level.

Why it fails: EBS encryption is applied at the block-storage level by the EBS service itself, not at the application level, so the verdict is incorrect. When you launch an encrypted EBS volume, each disk block is transparently encrypted with a data key that is then wrapped by a KMS key, and the instance reads and writes plaintext through the hypervisor without any application involvement. The confusion likely arises because applications on an encrypted volume see normal, unencrypted I/O, making it appear as though encryption happens in the app, when in reality it is fully handled by the underlying AWS storage infrastructure.

Glacier encryption: Encryption is optional for data at rest.

Why it fails: Amazon S3 Glacier automatically encrypts all archived data at rest with AES-256 using S3-managed keys; encryption is not optional and cannot be turned off for Glacier vaults or archives. You can, however, choose to enforce stronger control by using SSE-KMS or SSE-C for archives, but the base encryption provided by AWS is always on. The misconception that Glacier encryption is optional likely stems from older architecture, but modern Glacier encrypts by default, and attempting to disable it would violate AWS data-protection guarantees.

Ensure the NLB is configured with a subnet from each Availability Zone and the targets are in the same subnets

Why it fails: Incorrect. While placing targets in the same subnets as the NLB can help preserve source IP without proxy protocol, it is not a requirement. The condition stated in this option is not necessary for source IP preservation.

Enable target group stickiness

Why it fails: Target group stickiness controls session persistence by directing all connections from a given client to the same target for a configured duration. It does not alter the packet header or insert any header with the original client IP; the backend still sees only the NLB node's private IP unless another mechanism like proxy protocol is used. Therefore, enabling stickiness addresses routing consistency, not source-IP visibility.

Enable cross-zone load balancing on the NLB

Why it fails: Cross-zone load balancing changes how NLB nodes distribute traffic across Availability Zones, allowing each node to reach targets in any AZ. It only affects load distribution and failover behavior; it leaves the source IP address unchanged from the backend's perspective, which is the NLB node's IP. Since the question asks about preserving the client's IP, enabling this feature cannot solve the problem.

S3 Interface Endpoint in the VPC

Why it fails: S3 does not support Interface Endpoints; only Gateway Endpoints are used.

VPC Peering to a shared services VPC

Why it fails: Not required for S3 access.

Internet Gateway attached to the VPC

Why it fails: Would allow inbound from internet, which is not desired.

The network ACL for the private subnet is blocking outbound traffic

Why it fails: Default NACL allows all outbound; custom NACL would need explicit allow.

The private subnet route table does not have a route to the NAT Gateway

Why it fails: It has a default route to the NAT Gateway.

The security group attached to the EC2 instance is blocking inbound traffic

Why it fails: Security group is stateful; outbound rule allows return traffic.

Place the RDS instance in the same subnet as the application tier and use security groups

Why it fails: Placing the RDS instance in the same subnet as the application tier would make it directly routable, violating the requirement that the database not be directly routable from the application tier.

Use ClassicLink to connect the application tier to the RDS instance

Why it fails: ClassicLink is a deprecated feature for EC2-Classic and cannot be used to connect to RDS instances in a VPC.

Use a NAT Gateway in the application subnet to route traffic to the RDS instance

Why it fails: A NAT Gateway enables outbound internet traffic from private subnets, but does not provide a direct internal network path to an RDS instance in another subnet or VPC.

Attach an Internet Gateway to the VPC

Why it fails: Would route to internet.

Create an S3 Interface Endpoint in the VPC

Why it fails: S3 does not support Interface Endpoints.

Use a NAT Gateway to route the traffic to the internet

Why it fails: Would use internet, not private.

Enable CloudTrail log file validation

Why it fails: CloudTrail log file validation provides integrity by generating a SHA-256 hash and digitally signing each log file, allowing you to detect tampering after delivery. However, it does not encrypt the log contents at rest, nor does it restrict which IAM principals can read the objects in the S3 bucket. Unless you separately enable S3 encryption and a restrictive bucket policy, the log files remain in plaintext and accessible to anyone with GetObject permission, so this option fails to address the confidentiality requirement.

Use AWS KMS to encrypt the CloudTrail log files

Why it fails: AWS CloudTrail does not support encrypting its delivered log files directly with AWS KMS keys; KMS is not an option in the trail's S3 delivery configuration. To use KMS for CloudTrail logs, you must enable S3 default encryption with SSE-KMS on the destination bucket, at which point KMS is invoked by S3, not by CloudTrail itself. This option is incorrect because it implies a nonexistent direct integration and would leave logs unencrypted if someone relies on it without configuring bucket-level encryption.

Store logs in Amazon CloudWatch Logs with encryption enabled

Why it fails: While CloudTrail can stream events to Amazon CloudWatch Logs and that service supports encryption using KMS customer-managed keys, this does not address the S3 bucket where CloudTrail natively stores the log files. CloudTrail always writes logs to S3 first, and the delivery to CloudWatch Logs is an optional supplementary destination; enabling encryption there does not encrypt the S3 objects or control access to them. Therefore, this action is a secondary measure and does not achieve the requirement to encrypt and secure the primary S3-based log store.

Enable VPC Flow Logs on the NAT gateway to detect unauthorized usage.

Why it fails: VPC Flow Logs are a monitoring feature that capture metadata about IP traffic traversing the NAT gateway, including source/destination addresses and ports, but they do not enforce any allow/deny decisions. They are purely passive and useful only for auditing or post-incident analysis. To actually block unauthorized outbound traffic, you need a network-level control like a network ACL or security group that filters packets in real time.

Create an IAM policy that allows only the application instances to use the NAT gateway.

Why it fails: IAM policies govern permissions for AWS API operations and are attached to IAM principals such as users, roles, or groups. A NAT gateway is a fully managed network device that does not have an IAM identity, so IAM policies cannot be attached to it or used to control data-plane traffic through it. Internet-bound traffic from private instances is controlled by network constructs—route tables, security groups, and network ACLs—not by IAM, making this option technically invalid.

Configure a security group for the NAT gateway that allows only the application instances' security group as source.

Why it fails: While you can attach a security group to the NAT gateway's elastic network interface, that security group filters inbound traffic arriving at the NAT gateway from instances, not the outbound traffic that the instances themselves generate. Even if you allow the application instances' security group as the source, that only permits those instances to send traffic to the NAT gateway; it does not restrict the destination addresses that those instances can request to reach. To constrain outbound destinations, you must apply an outbound rule to the instances' own security group or use a network ACL on the private subnet.

Use a private virtual interface (VIF) and enable IPsec encryption for the traffic.

Why it fails: A private VIF connects your on-premises network directly to your VPCs through AWS Direct Connect, providing a private, low-latency path that does not traverse the public internet. Enabling IPsec encryption on the traffic adds confidentiality and integrity between your edge devices and AWS, protecting the data even while it crosses the physical Direct Connect infrastructure. This combination is the recommended and standard way to secure data in transit over a private VIF.

Use a public VIF to access all AWS services including VPC resources.

Why it fails: A public virtual interface (VIF) only routes traffic to AWS public services such as S3 and DynamoDB using public IP addresses, so it cannot reach VPC resources that use private IPs. Traffic over a public VIF is not inherently private or encrypted, making it inappropriate when the requirement is private, secure access to VPC workloads. Public VIFs are not a substitute for private VIF connectivity to VPCs.

Use a private VIF and enable MACsec encryption at the physical layer.

Why it fails: MACsec encryption operates at the Ethernet physical layer, protecting only the point-to-point link between your on-premises router and the AWS Direct Connect location; it does not provide end-to-end encryption for packets traveling through the VPC or across the Direct Connect network. While MACsec can be enabled on supported dedicated connections, it requires specific hardware and is not a substitute for IPsec, which encrypts the IP payload and is widely compatible with existing network equipment. For securing traffic over a private VIF, IPsec is the preferred and portable encryption choice, so MACsec alone would not meet the stated security requirement.

The EC2 instance's security group is blocking outbound traffic.

Why it fails: The instance security group controls traffic to and from the EC2 instance itself; if its outbound rules denied internet traffic, the packets would never reach the NAT gateway in the first place. In this scenario the instance is able to send traffic into the VPC, and the fault is after that hop, in the NAT gateway's lack of an EIP. Therefore a misconfigured instance security group is a plausible but incorrect alternative explanation.

The NAT gateway's security group is blocking outbound traffic.

Why it fails: NAT gateways are a fully managed AWS service and cannot have security groups attached to them; security groups are applied to resources such as EC2 instances and ENIs, not to NAT gateway infrastructure. The only network access controls that can affect a NAT gateway are VPC route tables and network ACLs on the subnets through which traffic flows. Thus, 'NAT gateway security group' is not a valid troubleshooting area.

The NAT gateway does not have a route to the internet gateway in its route table.

Why it fails: Route tables are associated with subnets, not with a NAT gateway itself; the NAT gateway must be placed in a public subnet whose route table has a 0.0.0.0/0 route to an internet gateway. If that route were missing, the NAT gateway could not connect to the IGW, but the reported problem would instead be a missing subnet route rather than an EIP association. Since the scenario specifies a route-table misconfiguration is not at issue, this option is incorrect.

Verify that the security group associated with the VPC endpoint allows inbound traffic.

Why it fails: Security groups are irrelevant for S3 gateway endpoints; they apply only to interface endpoints (PrivateLink). Gateway endpoints are not network interfaces and thus have no security group association. Inbound traffic to S3 is governed by route tables for routing and by IAM, bucket, and endpoint policies for authorization, so checking a security group will not reveal why users cannot access the bucket.

Ensure the VPC endpoint is in the same region as the S3 bucket.

Why it fails: S3 gateway endpoints are region-specific and the VPC and bucket must be in the same region. If they were in different regions, the endpoint simply would not exist or resolve, making the bucket unreachable. Since the users are clearly attempting requests, the endpoint is present, so checking for regional match is a fundamental prerequisite, not a troubleshooting step—it is not the cause of their current access failure.

Allows a role from another account to describe, start, and stop EC2 instances in the current account.

Why it fails: This statement is incorrect because the Principal in the policy is an IAM role ARN within the same account (123456789012), not a role from a different AWS account. A cross-account grant would require the Principal to be the account ID or a role ARN from an external account, and the external role would also need a trust policy. Since the role ARN is in the current account, the policy cannot be interpreted as cross-account access.

Allows all IAM users in the account to view EC2 instances.

Why it fails: This is wrong because the policy's Principal is a single IAM role, not all IAM users in the account. Additionally, the granted actions include StartInstances and StopInstances, which are state-changing operations, not merely viewing. To allow all IAM users to view EC2 instances, the policy would need to target the users group or use a broader Principal and include only describe actions, which is not the case here.

Allows an IAM user to list and manage objects in the S3 bucket.

Why it fails: This is incorrect because the policy's Action elements are EC2 actions (ec2:DescribeInstances, ec2:StartInstances, ec2:StopInstances), not S3 actions such as s3:ListBucket or s3:PutObject. There is no S3 bucket referenced in the Resource element, and the policy does not grant any permissions for S3. Therefore, it cannot allow an IAM user to list or manage objects in an S3 bucket.

Enable S3 Object Lock.

Why it fails: S3 Object Lock prevents object deletion or version overwrites, not encryption.

Enable S3 Transfer Acceleration.

Why it fails: S3 Transfer Acceleration speeds up uploads over long distances, not encryption.

Use S3 server-side encryption with S3-managed keys (SSE-S3).

Why it fails: While SSE-S3 is a valid encryption method, it is not one of the two correct answers for this question; the correct pair is SSE-C and client-side encryption.

Database security group: Allow inbound MySQL from the public subnet CIDR.

Why it fails: This would allow traffic from any instance in the public subnet.

Database security group: Allow inbound MySQL from 0.0.0.0/0.

Why it fails: This would expose the database to the internet.

Bastion security group: Allow inbound SSH from 0.0.0.0/0.

Why it fails: This would allow SSH from any IP.

IAM policies

Why it fails: IAM policies are identity-based or resource-based policies that are scoped to a single AWS account and apply only to specific users, groups, or roles, not to an entire organization. Even if you create identical IAM policies across multiple accounts, you cannot centrally manage or enforce them from a single point, and they cannot restrict the root user or a service role that has been granted broader permissions. Therefore, IAM policies cannot provide the organization-wide, uniform enforcement that a control such as an SCP would.

VPC Flow Logs

Why it fails: VPC Flow Logs capture information about IP traffic to and from network interfaces in a VPC, such as source and destination addresses, ports, and whether traffic was accepted or rejected. They are a telemetry and diagnostic tool designed for network monitoring, troubleshooting, and security analysis, not for enforcing or preventing specific AWS actions. Flow logs can show you that an instance was launched, but they have no ability to deny or restrict instance type selection across accounts.

AWS CloudTrail

Why it fails: AWS CloudTrail is a logging service that records API activity for governance, compliance, operational auditing, and risk auditing. Even when configured as an organization trail to aggregate logs from all member accounts, CloudTrail only captures a record of which principal did what, when, and from where; it does not sit in the request path to allow or deny an action. Thus, CloudTrail can provide evidence of non-compliant instance launches but cannot actively prevent or restrict deployment of specific instance types.

IAM policies

Why it fails: IAM policies govern authorization for the ec2:RunInstances API action, but they do not support a condition key that references a specific AMI ID. You can restrict by instance type, subnet, or resource tag, but there is no ec2:ImageId condition for launch requests, and the AMI is not a valid resource ARN for RunInstances. Consequently, any user with RunInstances permission could launch any AMI available to the account, so IAM policies cannot enforce that only approved AMIs are used. Even a strong deny-everything-else approach cannot allow-list an AMI.

AWS Config

Why it fails: AWS Config is a detective control that records EC2 instance configurations and evaluates them against rules, such as checking the AMI ID that an instance was launched from. It can flag noncompliant instances and even trigger auto-remediation via Systems Manager Automation, but only after the instance already exists. Because remediation is post-launch, a short-lived instance could still pose a risk, and Config never blocks the original RunInstances call. Therefore, it supports detection and reporting but cannot ensure that an EC2 instance can only be launched from an approved AMI.

AWS Image Builder

Why it fails: AWS Image Builder automates the building, patching, and testing of VM images and AMIs, so you can maintain a pipeline that produces approved, up-to-date AMIs. However, Image Builder's scope ends at publishing the finished AMI; it has no enforcement mechanism that prevents an IAM user from bypassing the pipeline and launching an unapproved, older, or custom AMI directly. It also does not sit in the API call path for RunInstances. Thus, while it helps create approved images, it does not guarantee that those are the only images used in the environment.

Create IAM roles in each account to enforce encryption.

Why it fails: IAM roles define which API actions a principal is allowed to invoke, but they cannot require that those actions include encryption parameters or that bucket-level default encryption be enabled. Even if a role has s3:PutObject, it can write unencrypted objects unless a bucket policy or SCP explicitly denies requests lacking encryption headers. Additionally, creating IAM roles individually in each account is a decentralized, manual process that offers no central guardrail against a user creating an unencrypted bucket or altering its encryption configuration.

Apply an S3 bucket policy to each bucket requiring encryption.

Why it fails: Bucket policies can enforce encryption by inspecting request conditions like s3:x-amz-server-side-encryption, but attaching such a policy to every bucket in every account is a manual, non-centralized approach that leaves the policies themselves mutable. Account administrators with s3:PutBucketPolicy permission can modify or detach a bucket policy, silently removing the encryption requirement. Unlike an SCP, which is evaluated before all IAM and resource-based policies, a per-bucket policy does not create an unbreakable governance boundary across the organization.

Use AWS Config rules to detect unencrypted buckets.

Why it fails: AWS Config rules, such as s3-bucket-server-side-encryption-enabled, are detective controls that evaluate resources after a change has already been applied. They can identify unencrypted buckets and even trigger remediation via Systems Manager, but the noncompliant bucket has already been created or altered, creating a temporary window of noncompliance. Config does not intercept the original API call and therefore cannot prevent malicious or accidental removal of bucket encryption, making it a reactive rather than preventive mechanism.

10.0.0.0/24

Why it fails: A /24 subnet provides only 256 total IPv4 addresses (251 usable after AWS reserves the VPC router, DNS, network, broadcast, and future-use addresses), which is far too small for a workload requiring thousands of instances. This option would exhaust address space almost immediately and trigger instance launch failures, so it cannot satisfy the required capacity.

10.0.0.0/22

Why it fails: A /22 subnet yields only 1024 total addresses (1019 usable in AWS), which is still below the required capacity of more than 2,000 hosts; attempting to use it would force a future, disruptive reconfiguration or a migration to a larger subnet. While it is more spacious than a /24, it remains insufficient and is therefore not the correct answer.

10.0.0.0/19

Why it fails: A /19 subnet supplies 8192 total addresses (8187 usable), which is twice as large as necessary and wastes over 4,000 addresses from the VPC's total allocation. This over-provisioning reduces the number of additional subnets you can create later and enlarges the broadcast domain for no benefit, so while it is functional, it is not the optimal choice.