- A client at 10.20.5.25 cannot connect to the server. Which change preserves the broad deny while enabling the intended exception?
Answer: Place the 10.20.5.0/24 allow rule before the 10.20.0.0/16 deny rule.
When working with Network Access Control Lists (NACLs), the critical concept is rule ordering: cloud platforms evaluate rules from lowest to highest number and stop at the first match. This means a broad deny placed before a more specific allow will always win — the specific allow never gets evaluated.
Here, rule 100 denies all traffic from 10.20.0.0/16. Since 10.20.5.0/24 is a subnet within 10.20.0.0/16, any packet from 10.20.5.25 hits rule 100 first and gets dropped immediately. Rule 110, which would allow that specific subnet, is never reached. The security group's allowance is irrelevant because traffic is blocked at the NACL layer before it even reaches the security group. The fix is straightforward: swap the rule numbers so the specific allow (10.20.5.0/24) carries a lower number than the broad deny (10.20.0.0/16), letting the exception be evaluated first. That's exactly what B does — it preserves the broad deny for the rest of the /16 while creating a working exception.
A is wrong because adding a security group rule doesn't help — the NACL already drops the traffic before the security group is consulted. C is a trap: placing the /16 deny after the final deny-all rule makes it completely unreachable and effectively deletes it, destroying the broad deny rather than preserving it. D is a distractor that modifies the wrong layer (security group) and expands port exposure unnecessarily without solving the NACL ordering problem.
Remember: NACLs are stateless and first-match. Always ask which rule number fires first before assuming a later allow can rescue traffic.
- Which action most directly restores database access for the new instances while retaining security-group-based workload identity?
Answer: Allow inbound TCP 5432 from 10.2.0.0/24 in the database subnet's NACL.
When AWS traffic hits a subnet, it passes through two distinct gatekeepers in sequence: the Network ACL (NACL) first, then the security group. Security groups are stateful (return traffic is automatic), but NACLs are stateless and subnet-scoped, meaning they filter purely by IP range regardless of what security groups say. When you see a question where security group rules are already correct but new instances in a different subnet can't connect, your first instinct should be: the NACL is blocking by CIDR.
Here, the database subnet's NACL explicitly allows inbound TCP 5432 only from 10.1.0.0/24. The new instances live in 10.2.0.0/24, so their traffic is dropped at the NACL before it ever reaches the security group evaluation. Adding 10.2.0.0/24 as an allowed inbound source in the database subnet's NACL — answer D — removes that block while leaving the security-group workload-identity model fully intact.
A is wrong because it replaces the elegant security-group reference model with static IP management. Every new instance would need manual updates, and this doesn't fix the NACL block anyway. B is wrong because associating the database security group with application instances makes no logical sense — security groups define what traffic is accepted by an interface, not sent from it. C is wrong because it targets the application subnet's inbound NACL, which controls traffic entering the application tier, not traffic leaving toward the database — it has no effect on the database subnet's filter.
Your study tip: always trace traffic hop by hop — NACL in → security group in → instance → security group out → NACL out. Identify which layer is blocking before choosing a fix.
- Which statement best explains the expected result?
Answer: The connection fails because internet reachability does not replace the security group's source restriction.
When you see cloud networking questions like this, think in layers: routing gets packets to the machine, but security controls determine whether a connection is actually allowed. These are independent concerns — reachability is not the same as permission.
In this scenario, the virtual machine is fully reachable from the internet: it has a public IP, a default route through an internet gateway, and a NACL that permits inbound and outbound web traffic. However, the security group — the resource-level firewall — explicitly restricts inbound TCP 443 to only the 203.0.113.0/24 prefix. The user at 198.51.100.60 falls outside that range entirely. Security groups enforce allow-list logic, so traffic from an unlisted source is silently dropped. The connection fails, making C the correct answer.
A is wrong because public IP addresses carry no implicit bypass of security controls. A public address enables routing — it doesn't grant any special permissions or override firewall rules. This is a common misconception worth memorizing.
B is wrong because routing specificity and security group rules operate at completely different layers. A default route being "less specific" than a host route is a routing concept; it has no bearing on whether a security group permits a connection. The two systems don't interact that way.
D is wrong because NACLs absolutely can permit traffic to publicly addressed machines — that's precisely what this NACL does. The failure here has nothing to do with NACL limitations.
As a study habit, always separate routing (can packets arrive?) from filtering (are packets allowed?). Exam distractors frequently conflate the two to test whether you understand that both conditions must be satisfied independently.
- Which action best meets the requirement with the smallest network-control blast radius?
Answer: Replace the compromised machine's security group with a quarantine security group that has no outbound allows.
When isolating a compromised host in cloud environments, your goal is surgical precision — contain the threat without touching anything else. The key distinction here is between controls that are host-specific versus controls that are shared, and whether those controls are stateful or stateless.
Security groups in AWS are stateful and attached per-instance, making them the ideal quarantine tool. By swapping the compromised machine's security group for a dedicated quarantine group with no outbound allows (answer B), you isolate exactly one machine. The remaining ten healthy machines keep their own security groups completely untouched, and the shared NACL remains unmodified. This is the smallest possible blast radius — the change affects only the compromised instance.
Answer A is tempting but flawed. NACLs are stateless and subnet-wide. Even though you're targeting the compromised machine's source IP, you're modifying a control plane that governs all eleven machines. Any misconfiguration or rule-ordering mistake could ripple across the healthy production hosts. Answer C makes this problem dramatically worse — stripping all outbound NACL rules from the shared subnet disrupts every machine on it, the opposite of minimal impact. Answer D sounds targeted, but it's a trap: AWS security groups are allow-only — you cannot add explicit deny rules. Outbound traffic is simply blocked if no allow rule matches, so "adding a deny" isn't a valid action in this model.
Study tip: Remember that security groups = stateful, instance-level, allow-only; NACLs = stateless, subnet-level, allow and deny. When a question asks for minimal impact, always favor the most granular control — security groups over NACLs.
- Which control change most directly enforces the requirement across the shared subnet?
Answer: Add a high-priority NACL deny for 198.51.100.0/24 before the broad HTTPS allow.
When you see a question about blocking specific traffic at the network level, the key distinction is understanding where controls live and what capabilities each layer has. In cloud environments, security groups and Network Access Control Lists (NACLs) serve different roles — and knowing that difference is what this question tests.
NACLs are subnet-level firewalls that support ordered rules with explicit deny capability, evaluated top-to-bottom. Security groups, by contrast, are instance-level and support allow rules only — they cannot explicitly deny traffic. Because the hostile network 198.51.100.0/24 must be blocked while all other internet HTTPS traffic remains allowed, you need an explicit deny — something only the NACL can provide.
Answer A is correct because placing a NACL deny for 198.51.100.0/24 before the broad HTTPS allow rule means the hostile traffic matches the deny first and is dropped, while all other traffic falls through to the allow rule. This works subnet-wide, covering all shared application servers in one change.
Answer B is wrong because you cannot enumerate "every public internet source except one" — the internet has billions of addresses, making this operationally impossible. Answer C is wrong for two reasons: security groups have no deny rule capability, and even if they did, you'd need to update every instance individually rather than applying a single subnet-level control. Answer D is a critical ordering trap — placing the deny after the broad allow means the allow rule matches first, the deny is never reached, and hostile traffic gets through anyway.
Your study tip: NACL rule order is everything. A deny placed after a broader allow is functionally invisible — always think "which rule matches first?"
- What happens if an internet client attempts to bypass the load balancer and connect directly to the application's public address on TCP 8443?
Answer: The connection fails because the client is not an interface associated with SG-LB.
When you see a question about security group chaining in cloud environments, focus on how security group references actually work — they evaluate the source of a packet against the network interface's associated security group, not addresses or inherited rules.
In this architecture, SG-App permits inbound TCP 8443 only from interfaces associated with SG-LB. This is a security group reference — it checks whether the packet's source interface is tagged with SG-LB. When the load balancer forwards traffic, it originates a new TCP connection from its own interface, which carries SG-LB. That passes. When an internet client connects directly to the application's public address on port 8443, the source is the client's IP — an interface with no association to SG-LB whatsoever. SG-App evaluates the source, finds no SG-LB membership, and drops the connection. Answer D is correct for exactly this reason.
Choice A is wrong because security groups are not inherited. Each resource enforces only its own attached security groups — SG-LB's rules have no effect on SG-App. Choice B reflects a fundamental misunderstanding: the application's public address is the destination, not the source, and satisfying a security group reference requires the source interface to carry SG-LB — not any property of the destination. Choice C is a tempting distractor, but NACLs are stateless subnet-level filters and have no awareness of whether traffic traversed a load balancer; the passage even states NACLs allow the required traffic.
Study tip: When security groups reference other security groups, always ask "what interface is sending this traffic?" — that's what gets evaluated, not IPs, destinations, or inherited policies.
- What is the effective result for a new SSH connection from 198.51.100.40?
Answer: The connection is allowed because one attached security group permits the source.
When working with cloud security groups, the most important concept to internalize is how multiple security groups are evaluated together: their rules are unioned, not intersected. The platform collects every allow rule from every attached security group and treats the combined set as one effective ruleset. A packet is permitted if any rule across any attached group allows it.
Here, SG-Restricted allows SSH from 192.0.2.0/24, and SG-Operations allows SSH from 0.0.0.0/0 (all addresses). The source IP 198.51.100.40 doesn't match SG-Restricted's range, but it absolutely matches SG-Operations' wildcard rule. Since one attached security group permits it, the connection is allowed — making B the correct answer.
A describes an intersection model, where every security group would need to allow the source. This would make sense for a mandatory access control scheme, but cloud security groups don't work that way. Adding a group can only open access, never silently close it.
C introduces a "more specific rule wins" concept borrowed from firewall ACL logic, where specificity or order determines precedence. Security groups don't rank rules by specificity — there's no tie-breaking needed when the model is purely additive.
D implies that attachment order matters. Security groups are stateless allow-lists evaluated as a flat union; the sequence in which they were attached to the interface is irrelevant to the outcome.
A useful mental model: think of each security group as a separate whitelist. If a source appears on any whitelist, it gets in. Watch for exam questions that describe multiple groups and try to trick you into applying firewall-style precedence logic.
- Which change correctly applies the intended defense-in-depth policy to both protocol families?
Answer: Replace both ::/0 SSH allows with allows from 2001:db8:1200::/48.
When you see a cloud security question involving dual-stack environments, ask yourself: does each security control explicitly address both IPv4 and IPv6? These are treated as completely separate protocol stacks — rules written for one do not automatically apply to the other.
The intended policy is defense-in-depth: restrict SSH to corporate ranges at both layers (security group and NACL) for both protocol families. The corporate IPv6 prefix is 2001:db8:1200::/48, which is the IPv6 equivalent of 192.0.2.0/24. Answer C correctly mirrors the IPv4 approach by replacing the permissive ::/0 SSH rules in both the security group and the NACL with allows scoped to 2001:db8:1200::/48. This closes the open internet exposure while preserving corporate access — exactly what defense-in-depth demands.
Answer A is wrong because IPv6-mapped IPv4 addresses (::ffff:0:0/96) are a host-level socket concept and are not filtered by AWS security groups or NACLs acting on actual IPv6 traffic. There is no automatic cross-protocol filtering. Answer B fails on two counts: NACLs are stateless and evaluated independently per protocol, so an IPv4 NACL rule never covers IPv6 packets, and restricting only one layer abandons the defense-in-depth requirement. Answer D is similarly flawed — removing the security group rule while leaving the NACL wide open (::/0) exposes SSH to the entire internet over IPv6, which directly violates the stated policy.
A useful rule of thumb: in any dual-stack environment, treat IPv4 and IPv6 as two separate doors. Every security control must be explicitly locked for both — assume nothing carries over automatically.
- Clients send SYN packets that reach the server, but they never receive the SYN-ACK. Which change most directly corrects the network-control issue without broadening inbound access?
Answer: Allow outbound TCP ports 49152–65535 in the NACL to the internet.
When you see a question mixing security groups and NACLs, immediately recognize that these two controls have fundamentally different behaviors: security groups are stateful (return traffic is automatically allowed), while NACLs are stateless (every direction of traffic must be explicitly permitted).
Here's the core issue: a client initiates a TCP handshake from an ephemeral port (49152–65535) to the server's port 443. The server's SYN-ACK must travel outbound back to that ephemeral port. The stateful security group handles this automatically — no outbound rule is needed for return traffic. However, the NACL doesn't track connection state. When the server sends its SYN-ACK outbound to the client's ephemeral port, the NACL evaluates that packet independently. Since the current outbound NACL rule only permits destination port 443, the SYN-ACK headed for ports 49152–65535 is silently dropped. Adding an outbound NACL rule allowing TCP to ports 49152–65535 — answer C — directly fixes this without touching inbound rules.
A is wrong because adding inbound ephemeral ports to the security group is irrelevant; the problem is outbound SYN-ACKs being blocked, not inbound traffic. B is wrong because the security group is stateful — it already permits outbound return traffic implicitly, so adding an explicit outbound rule changes nothing functionally. D is wrong because it opens inbound NACL access on ephemeral ports, which broadens inbound access unnecessarily and doesn't resolve the outbound blocking problem.
Your study tip: always ask yourself "stateful or stateless?" first. Security groups = stateful (return traffic free). NACLs = stateless (you must manually allow both directions).
- Which single change is sufficient to permit the partner connection while retaining the existing network path?
Answer: Add an inbound TCP 8443 security group rule for the partner CIDR.
When troubleshooting cloud network access problems, always work through the two distinct filtering layers separately: Network ACLs (NACLs) and Security Groups. NACLs are stateless, subnet-level filters; Security Groups are stateful, instance-level filters. Traffic must pass both to reach its destination.
In this scenario, the NACL already permits inbound TCP 8443 from the partner CIDR and handles return traffic — so that layer is clear. The bottleneck is the Security Group on the application instance, which only allows TCP 8443 from the corporate CIDR. The partner CIDR is never whitelisted at the instance level, so packets are dropped before reaching the application. The fix is straightforward: A — add an inbound TCP 8443 Security Group rule for the partner CIDR. That single change opens the instance-level gate without touching anything else.
B is wrong because the NACL already permits the partner's traffic on TCP 8443. Adding a duplicate NACL rule changes nothing about the actual blocking point. C is a classic trap — Security Groups are stateful, meaning return traffic is automatically allowed once an inbound rule permits the session. An outbound rule is unnecessary and wouldn't fix inbound access anyway. D is wrong because the passage explicitly states routing is already operational; adding a route solves a layer-3 reachability problem, not a layer-4/security-policy problem.
Study tip: On security architecture questions, always identify which layer is blocking traffic before choosing a fix. A common trap is confusing NACL rules (stateless, need both directions) with Security Group rules (stateful, inbound rule is sufficient).
