Troubleshoot a cross-subnet connection failure by inspecting Network ACL DENY rules

SCS-C02 By islever Editorial Last updated

Troubleshoot network security.

Short answer

B Check Network ACL inbound/outbound DENY rules; security groups cannot deny, so the explicit block must be at the subnet-level NACL.

Question

Two Amazon EC2 instances in different subnets should be able to connect to each other but cannot. It has been confirmed that other hosts in the same subnets are able to communicate successfully, and that security groups have valid ALLOW rules in place to permit this traffic. Which of the following troubleshooting steps should be performed?
  1. Check inbound and outbound security groups, looking for DENY rules
  2. Check inbound and outbound Network ACL rules, looking for DENY rules Correct Answer
  3. Review the rejected packet reason codes in the VPC Flow Logs
  4. Use AWS X-Ray to trace the end-to-end application flow

Key Takeaways

Security groups have no deny capability, only allow. Network ACLs are the only VPC component in this scenario that can explicitly deny traffic, and they are evaluated at the subnet level, so a DENY rule between the two subnet CIDRs would block exactly the cross-subnet traffic described while leaving intra-subnet communication intact.

Two EC2 instances in different subnets cannot connect, though other hosts in the same subnets communicate and security groups already have valid ALLOW rules. Security groups are stateful and support only ALLOW rules, so they cannot contain a DENY. Network ACLs are stateless, subnet-attached, and can contain explicit DENY rules, making them the next place to look for a blocking rule between the two subnets.

Common mistake: Re-checking security groups for DENY rules, which do not exist, or jumping straight to VPC Flow Logs before considering that NACLs are the only component capable of an explicit DENY in this topology.

Expert Analysis

Why the Answer Is Correct

Security groups are stateful and can only allow traffic; they cannot deny. Because the scenario states the SGs already have valid ALLOW rules, the block is not there. Network ACLs, attached to subnets and stateless, can contain explicit DENY rules. Since other hosts in the same subnets communicate successfully, the failure is specific to traffic between these subnets, and a NACL DENY rule scoped to that subnet-to-subnet traffic is the most direct cause to verify.

Why the Other Options Are Wrong

A is wrong because security groups have no DENY rules, so looking for one there is futile. C is a valid deeper step but secondary: Flow Logs show rejected-packet reasons only after you suspect a rule is dropping traffic; checking the NACL DENY rules is the more direct first action given SGs are already confirmed. D is wrong because X-Ray traces application requests, not network-layer allow/deny decisions, and would not reveal an NACL block.

Community Comment Notes

Community was split between B and C. The leading B argument: "SG don't have deny rules," so NACLs are the only place a DENY can exist. The C argument noted that other hosts in the same subnets communicating seemingly rules out an NACL issue. The stronger reasoning supports checking NACL DENY rules first.

Official Reference

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html

This link opens the official vendor documentation in a new tab.

Community Votes

B
62%
C
38%

62% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 7 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 7

  1. DeadDropLabs 👍 4 Answered B
    For C - While VPC Flow Logs can provide insights into why packets are being rejected, this is a more detailed troubleshooting step. Checking the NACL rules is a more direct approach to identifying potential network layer issues.
  2. aescudero51 👍 2 Answered C
    C is more relevant due to "It has been confirmed that other hosts in the same subnets are able to communicate successfully" where it says "other hosts in the same subnets" excluding NACL issue..
  3. Zek 👍 2
    Will go with B a public discussion thread on this question
  4. navid1365 👍 1 Answered B
    The answer is B. Here is the reason: 1) A cannot be correct since the questions explicitly mentions that SG are configured with correct rules 2) B is correct. NACLs are attached to a subnet and can have both ALLOW and DENY rules. Given that the other hosts in the two subnets can communicate successfully, there has to be an explicit DENY rule that denies access between the two hosts in question.
  5. yismail 👍 1
    Correct answer is C, other Instances in the same subnet can communicate, this eliminate the issue of NACL, if the deny role is attached the NACL on the same subnet, other Instances will not be able to communicate, only VPC flow logs can determine the error msg
Show 2 more comments
  1. Certified101 👍 3
    B - SG dont have deny rules
  2. Bachhu 👍 1 Answered C
    It should be C.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Preserve EC2 forensic evidence by isolating first, then capturing memory before stopping the instance

S-grade

Grant the report Lambda Security Hub read-only access because findings are already in Security Hub

S-grade

Deny inbound MySQL 3306 and allow outbound TLS 443 with ephemeral return in a custom NACL

S-grade

Prepare a PHI/public-bucket audit with Macie, Audit Manager, and Security Hub FSBP

S-grade

← Back to SCS-C02 Study Guide