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

Answer Correct answer: B — check Network ACL inbound/outbound DENY rules; security groups cannot deny, so the explicit block must be at the subnet-level NACL.

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

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.

Community Insight

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.

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.

Community Discussion (7 comments)

Bachhu 👍 1 Selected: C
It should be C.
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
navid1365 👍 1 Selected: 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.
DeadDropLabs 👍 4 Selected: 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.
aescudero51 👍 2 Selected: 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..
Certified101 👍 3
B - SG dont have deny rules
Zek 👍 2
Will go with B https://www.examtopics.com/discussions/amazon/view/30042-exam-aws-certified-security-specialty-topic-1-question-176/

Comments & Corrections

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

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

Related Analysis

← Back to SCS-C02 Study Guide