Infrastructure Security practice questions

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

Why wrong: 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 wrong: 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 wrong: 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 network ACL for the subnet is blocking outbound traffic to the on-premises CIDR.

Why wrong: If the subnet's network ACL were blocking outbound traffic to the on-premises CIDR, the VPC instances would be unable to send any packets toward Direct Connect, and the on-premises side would receive nothing at all. The scenario demonstrates that outbound traffic is reaching the on-premises network, which proves the NACL is permitting the egress flow. NACLs are stateless and require explicit allow rules for both outbound and inbound traffic, but here only the return path is broken.

The virtual private gateway is not attached to the VPC.

Why wrong: A virtual private gateway that is not attached to the VPC would leave the VPC route table without any viable target for Direct Connect traffic, preventing all outbound packets from ever leaving the VPC. Since the observed symptoms show outbound traffic successfully arriving at on-premises, the gateway must be attached and operational. An unattached gateway would be a total connectivity failure, not a one-way connectivity issue.

The security group does not allow inbound traffic from the on-premises server.

Why wrong: Security groups are stateful: if the instance's outbound rule permits traffic to the on-premises server, the security group automatically allows the corresponding inbound response traffic, even without an explicit inbound rule. Therefore, a missing inbound rule for the on-premises CIDR cannot cause the return packets to be dropped. The issue lies in an external router lacking a return route, not in the security group configuration.

Create an S3 bucket policy in each account to deny access to unencrypted buckets.

Why wrong: S3 bucket policies are resource-based policies attached to an already existing bucket; they can only limit access to that specific bucket and cannot intercept or deny the s3:CreateBucket API call. Since the bucket must exist before the policy is attached, any unencrypted bucket created by a user would be created without ever being subject to the policy, and the approach would not scale as a preventive control across many accounts and future buckets.

Use AWS Config rules to detect buckets without encryption and send alerts.

Why wrong: AWS Config rules continuously evaluate the configuration of tracked resources, such as S3 buckets, against compliance rules and can trigger alerts or remediation actions via EventBridge or Systems Manager. However, they run as a detective control after a resource has already been created, so the unencrypted bucket exists before the rule can flag it as noncompliant. This makes the approach reactive, not a guardrail that prevents the creation of unencrypted buckets in the first place.

Create an IAM role in each account that requires encryption when creating buckets.

Why wrong: An IAM role defines a set of permissions that a principal can assume, but it cannot impose requirements on other IAM identities or service actions; a user with s3:CreateBucket permission can create an unencrypted bucket without ever assuming that role. Roles are per-account identity entities, so configuring them in each account does not create a centralized guardrail and offers no enforcement if a principal does not use the role. The role's policy would only restrict what the role itself can do, not the actual creation event.

Create a security group for the database servers that allows inbound traffic on port 3306 from the web subnet CIDR.

Why wrong: Although this inbound rule would technically permit web servers on that subnet to reach port 3306, referencing the web subnet’s CIDR is far broader than necessary—it also allows any other instance placed in that subnet, such as a bastion host or a management server, to connect to the database. More importantly, the rule is static: if the web tier’s IP address space changes (e.g., new subnets are added or the subnet is replaced), the rule must be manually updated, whereas a security group reference automatically follows the members. Additionally, using a CIDR source does not leverage the stateful nature of security groups in the same clean way, and it is considered a less secure, less dynamic pattern than referencing the web security group’s ID.

Place the database servers in a public subnet for easier connectivity.

Why wrong: Placing the database servers in a public subnet would make them reachable from the internet, as public subnets route 0.0.0.0/0 through an Internet Gateway, exposing the database externally. This directly contradicts the security best practice of keeping database tiers in private subnets without internet routes, because a public subnet typically assigns public IP addresses and broadens the attack surface significantly. Even if the intention is 'easier connectivity' from the web servers, the web servers can reach private databases through private IP routing inside the VPC, so there is no technical benefit to making the database public.

Configure the network ACL for the database subnet to allow inbound traffic on port 3306 from the web subnet CIDR.

Why wrong: A network ACL is stateless, so allowing inbound traffic on port 3306 from the web subnet CIDR does not automatically permit the return traffic from the database servers to the web servers. The application requires two-way communication, and a stateless ACL would also need an outbound rule for ephemeral ports, which the security team would have to configure explicitly. This option is tempting because network ACLs provide subnet-level filtering and are often used to block traffic at the VPC boundary, but they lack the stateful tracking that security groups offer, making them unsuitable for this bidirectional requirement without additional rules.

The policy does not specify a principal, so it will not work.

Why wrong: This claim is incorrect because the policy does include a Principal element; in a typical SQS access policy, both statements specify 'Principal': '*', which is valid when paired with conditions such as aws:SourceArn or aws:SourceIp. A policy without any Principal would not attach correctly, but that is not the case here. The wildcard principal does not prevent the policy from functioning; it merely expands the set of subjects, and it is acceptable only because the conditions constrain the request.

The aws:SourceArn condition uses ArnLike which is deprecated.

Why wrong: ArnLike is a standard condition operator for comparing ARNs with wildcard characters, and it is not deprecated in IAM or SQS policy evaluation. Queue policies commonly use aws:SourceArn with ArnLike, for example 'ArnLike': {'aws:SourceArn': 'arn:aws:sns:us-east-1:123456789012:topic'}. Confusion about deprecation may stem from older documentation, but ArnLike remains fully supported and is the appropriate operator for ARN pattern matching.

The aws:SourceIp condition cannot be used with SQS queue policies.

Why wrong: aws:SourceIp is a global condition key that is valid in SQS queue policies; it lets you restrict source IP addresses, such as with 'IpAddress': {'aws:SourceIp': '10.0.0.0/8'}. It is not SQS-specific, but global condition keys are available in all services that support IAM resource policies. A subtle nuance is that if requests arrive through a VPC endpoint, aws:SourceIp may not be evaluated as expected, so it is not a substitute for restricting the principal.

Enable VPC Flow Logs to monitor traffic to S3.

Why wrong: VPC Flow Logs capture network traffic metadata at the elastic network interface level, including source and destination IPs, ports, and protocols, but they do not log S3 API actions such as GetObject, PutObject, or ListBucket. They also provide no enforcement mechanism; they are strictly a detective control that records traffic after it occurs. Even if you monitor Flow Logs for anomalies, an exfiltration event would already have happened before you can act, so this does not prevent data exfiltration from EC2 to S3.

Deploy AWS WAF in front of the S3 bucket.

Why wrong: AWS WAF is a web application firewall designed to inspect and filter HTTP/S traffic destined for resources like CloudFront, Application Load Balancers, or API Gateways; it does not inspect or control S3 API calls made by EC2 instances. S3 access is governed by IAM policies, bucket policies, and access points, not by WAF rules, so deploying WAF in front of an S3 bucket cannot block direct S3 operations. Furthermore, WAF cannot authenticate or authorize principals, making it ineffective at preventing data exfiltration from an instance that already has legitimate access to the bucket.

Create an AWS Config rule to detect S3 access from EC2 instances.

Why wrong: An AWS Config rule can evaluate whether S3 buckets have certain configuration attributes, such as requiring encryption or checking for public access, but it is an after-the-fact audit tool that does not intercept or deny API requests. Config rules operate by recording resource configurations and assessing compliance against them, and they cannot enforce an allow-list of source VPC endpoints or block a GetObject call in real time. While detecting S3 access patterns from EC2 instances might be possible via CloudTrail, Config alone cannot provide the preventive control needed to stop data exfiltration before it occurs.

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

Why wrong: 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 wrong: 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 wrong: 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.

Modify the inbound rule of 'app-sg' to allow HTTP traffic from the private IP addresses of the ALB nodes.

Why wrong: Hardcoding the private IPs of ALB nodes as the source in an inbound rule is brittle because the ALB scales automatically and its node IPs are dynamic and unpredictable. Security group rules cannot dynamically track a changing list of IPs, so you would need to continuously monitor and edit the rule manually. Moreover, using raw IPs ties access to specific infrastructure rather than the ALB's logical identity, and those same private IPs may belong to other instances.

Modify the inbound rule of 'app-sg' to allow HTTPS traffic from 0.0.0.0/0 and remove the HTTP rule.

Why wrong: Opening HTTPS to 0.0.0.0/0 defeats the purpose of placing an Application Load Balancer in front of the EC2 instances, because it allows any internet client to reach the web servers directly. It also assumes the ALB will use HTTPS to forward to the backend, which is not the default; if the target group uses HTTP, removing the HTTP rule would break load-balanced traffic. A security group source should restrict traffic to the ALB's security group, not accept all IPv4 addresses.

Modify the inbound rule of 'app-sg' to allow HTTP traffic from the ALB's elastic network interface (ENI).

Why wrong: A security group inbound rule's source must be an IPv4/IPv6 CIDR or another security group ID; you cannot reference an ENI ID as the source. Even if you could, ALB ENIs are dynamically created and removed as the load balancer scales, so pinning to a specific ENI would be fragile and require manual updates. Security group ID references remain valid as the ALB's underlying ENIs change, making that approach the intended AWS-native pattern.

Validate domain ownership via DNS, Request certificate, Issue certificate, Associate certificate with AWS resource

Why wrong: Domain ownership validation cannot precede the certificate request because ACM generates the DNS validation CNAME token only after you submit the request. Without the request, there are no tokens to place in DNS, and ACM has no pending certificate to validate. Therefore the sequence is invalid from the start.

Request certificate, Issue certificate, Validate domain ownership via DNS, Associate certificate with AWS resource

Why wrong: ACM does not issue a certificate while domain ownership is still unproven. A requested certificate remains in Pending validation status until ACM detects the required DNS CNAME record (or you respond to email validation), and only then does the status change to Issued. Placing issuance before validation contradicts ACM's state machine.

Request certificate, Validate domain ownership via DNS, Associate certificate with AWS resource, Issue certificate

Why wrong: A certificate cannot be associated with an AWS resource until ACM has moved it to the Issued state. If you attempt to associate a certificate that is still in Pending validation, ACM returns an error. Once validation succeeds ACM issues the certificate automatically, so placing Associate before Issue inverts the dependency.

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

Why wrong: 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 wrong: 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 wrong: 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.

String match condition

Why wrong: A string match condition in AWS WAF performs exact string or substring matching on a specified request component, such as a header or query parameter. Because it does not support regex metacharacters, it cannot express the set of all valid API key formats; you would have to list every possible key individually, which is impractical and insecure. Therefore, it is unsuitable for validating whether an API key conforms to a pattern and blocking invalid ones.

Rate-based rule

Why wrong: A rate-based rule tracks the number of requests from a given source IP address over a rolling window and blocks traffic that exceeds a configured threshold. It is designed to mitigate DDoS attacks and aggressive bots, but it never inspects the content or format of an API key. Thus, an attacker could send a low volume of requests with invalid keys and still pass through the rate-based rule, so it cannot implement API key validation.

IP set

Why wrong: An IP set is a collection of IP addresses or CIDR ranges that can be referenced in a WAF rule to allow or block traffic based solely on the network source address. It does not have any visibility into application-layer fields like the API key header, and an attacker can easily spoof or rotate IPs to bypass IP-based filtering. This makes it irrelevant for validating the authenticity of API keys presented in request headers.

Configure TLS on the applications

Why wrong: TLS only encrypts the specific application protocols that implement it, such as HTTPS or LDAPS, and does not protect UDP traffic, syslog, NTP, or other IP-based communications crossing the Direct Connect link. Even if every application were individually enabled with TLS, the underlying network path between on-premises and the VPC would remain unencrypted, leaving metadata and non-application traffic exposed. This approach fails the requirement to secure the connection itself, rather than just the payloads of a few higher-layer protocols.

Use a site-to-site VPN over the internet instead of Direct Connect

Why wrong: Replacing Direct Connect with an internet-based site-to-site VPN forfeits the dedicated connection's benefits, including consistent throughput, lower latency, and greater reliability, because traffic now crosses the public internet where performance is variable and packet paths are uncontrolled. Although IPsec does encrypt the traffic, the public path introduces additional attack surface and potential for ISP outages or throttling. This option also sidesteps the requirement to secure the existing Direct Connect link rather than solving it; the goal is to encrypt the private connection, not to abandon it for a less deterministic network.

Enable encryption on the Direct Connect private VIF

Why wrong: AWS Direct Connect private VIFs are carried over an unencrypted physical link and do not have a console or API setting to enable encryption on the VIF itself. Even though MACsec (IEEE 802.1AE) can be enabled on a dedicated Direct Connect connection to encrypt traffic at Layer 2, it applies to the entire physical link and is not a private-VIF feature; it also requires dedicated connections with compatible hardware. Attempting to 'enable encryption on the private VIF' is not a supported operation, so the correct approach is to overlay IPsec over the VIF or use MACsec on the underlying dedicated connection.

aws:VpcSourceIp

Why wrong: aws:VpcSourceIp is not a recognized IAM condition key in any AWS service, including S3. AWS global condition keys use aws:SourceIp for client IP addresses, and VPC-specific keys are aws:SourceVpc or aws:SourceVpce. Since this key does not exist, it cannot evaluate to true in a policy, so it would fail to allow any access.

aws:SourceVpc

Why wrong: aws:SourceVpc restricts access to requests that originate from any interface or flow within a specified VPC, matching the VPC ID in the condition. This is broader than the requirement because it includes traffic that reaches S3 through NAT, VPN, or Direct Connect from resources in that VPC, not just through a specific VPC endpoint. To limit access to a single VPC endpoint, you need a condition key that identifies that endpoint rather than the entire VPC.

aws:SourceIp

Why wrong: aws:SourceIp restricts based on the source IP address of the requester, which is often the public IP address for internet traffic or the private IP address for traffic within a VPC. For requests sent through a VPC endpoint, the S3 service sees the source IP as a private IP from the VPC, but that does not indicate which endpoint was used. Moreover, the source IP can change or be shared by multiple resources, so it cannot identify a unique VPC endpoint for the required access restriction.

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

Why wrong: 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 wrong: 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 wrong: 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.

AWS Network Firewall

Why wrong: AWS Network Firewall is a managed stateful firewall that inspects traffic at the network and transport layers (IP, ports, protocols) across a VPC. It lacks the ability to parse HTTP/HTTPS application headers or URI patterns, so it cannot distinguish benign web traffic from layer 7 DDoS flood. While it can enforce network ACL-like rules, it does not provide the application-layer visibility required for mitigating attacks targeting web applications.

Amazon GuardDuty

Why wrong: Amazon GuardDuty is a continuous security monitoring service that analyzes VPC Flow Logs, DNS logs, and CloudTrail events to identify suspicious behavior using machine learning and threat intelligence. It functions as a detection mechanism, alerting on anomalies like port scans or compromised instances, but it does not sit inline to filter or absorb malicious traffic. As a result, it cannot actively block or reduce DDoS attack volume.

AWS Firewall Manager

Why wrong: AWS Firewall Manager is a central policy management service that lets you centrally configure and govern AWS WAF rules, Shield Advanced protections, and security groups across accounts in an organization. It automates the deployment and enforcement of security policies, but it does not directly process or inspect live traffic. Therefore, while it could help deploy WAF rules, it is not itself the service that mitigates application-layer DDoS attacks.

Use AWS CloudFront with a custom header that enforces HSTS

Why wrong: CloudFront's custom headers are added to the forwarded request sent to the origin, not to the response delivered to the viewer. Strict-Transport-Security is a response header that must be emitted by the backend or edge logic (e.g., Lambda@Edge), and simply attaching a custom header does not enforce HSTS or tell the browser to only use HTTPS. Even if CloudFront also redirects HTTP to HTTPS, the HSTS policy itself would be missing, so this approach fails the requirement.

Configure the ALB listener to use HTTPS only and set a custom header via a listener rule

Why wrong: ALB listener rules are for conditional routing—they match incoming request attributes and then forward, redirect, or return a fixed response, but they cannot add, remove, or rewrite response headers on behalf of the origin. A listener rule that sets a custom header is not a supported action; HSTS must be present in the HTTP response header from the backend application. Configuring the listener to HTTPS only prevents plaintext access but leaves the browser without the HSTS policy, so it does not meet the stated security goal.

Enable HSTS on the ALB via the AWS Management Console

Why wrong: The AWS Management Console provides no HSTS toggle or configuration for Application Load Balancers; ALB offers TLS termination and security policies but HSTS is not a load-balancer feature. HSTS is an HTTP response header (Strict-Transport-Security) that is defined by the application or web server, not by the gateway or proxy layer. Since the console cannot inject that header into responses, choosing this option means the browser would never receive the HSTS instruction, and the requirement would remain unmet.

Enable CloudTrail log file validation

Why wrong: 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 wrong: 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 wrong: 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.

Resource

Why wrong: The Resource element in a KMS key policy specifies the AWS KMS key itself, usually by its key ARN, and defines what object the statement applies to. KMS key policies are resource-based policies attached to a single key, so the Resource can only be that key's ARN or a wildcard, never the caller. This element tells KMS which key is affected, not which identity is allowed, so it is incorrect.

Action

Why wrong: The Action element enumerates the specific KMS API operations that the policy permits, such as kms:Encrypt, kms:Decrypt, kms:ReEncrypt, or kms:GenerateDataKey. It governs what operations can be performed, not who can perform them, and it only takes effect when paired with a Principal. Because this statement is about the identity using the key, Action cannot be the correct answer.

Effect

Why wrong: The Effect element is the allow-or-deny decision in a policy statement, written as Allow or Deny. It sets the outcome when a request matches the Principal, Action, Resource, and Condition, but it says nothing about which identities are permitted to use the key. Because it does not identify the user or role, Effect is not the correct answer.

Configure the ALB to be internal and place it in a VPC with a CloudFront VPC origin.

Why wrong: Making the ALB internal and using a CloudFront VPC origin is technically plausible only when the ALB is deployed as an internet-facing endpoint; CloudFront's edge infrastructure cannot route to a private, internal ALB because a VPC origin still requires a public DNS target with a public IP. An internal ALB has only private IP addresses in the VPC, which CloudFront cannot reach, so this configuration breaks origin connectivity entirely. Even if you used an internet-facing ALB inside a VPC, the safety comes from the ALB's security group, not from the VPC itself, so this option does not meet the requirement.

Configure the ALB to require a specific header 'X-CloudFront-Origin' and reject requests without it.

Why wrong: There is no standard 'X-CloudFront-Origin' header added by CloudFront; you can only configure CloudFront to add arbitrary custom headers per origin, which any direct client can trivially spoof by sending the same header value. Relying on a header as an access-control mechanism provides no cryptographic proof the request originated from CloudFront, so an attacker can bypass the ALB security by manually including that header in their HTTP request. Correct origin protection combines security group restrictions with a shared secret header or AWS WAF, never a header alone.

Configure the ALB to use an IAM role that allows only CloudFront to invoke the ALB.

Why wrong: IAM roles govern how AWS principals authenticate to AWS APIs and services; an Application Load Balancer does not assume an IAM role to accept or reject inbound network connections. The ALB operates as a Layer 7 service that processes traffic based on listener rules, target groups, and security group policies, not on IAM principals. CloudFront also does not perform IAM-based authentication when forwarding requests to an ALB; it simply resolves the origin DNS and connects over the network, so this option misunderstands the boundary between AWS authorization and network traffic control.

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

Why wrong: 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 wrong: 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 wrong: 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.