Cyber Security Quiz: Cloud Network Controls
10 questions · exam conditions
0:00
Cloud Network ControlsQuestion 1 of 10

A cloud web server accepts TCP connections on port 443. Its stateful security group allows inbound TCP 443 from the internet and has no outbound allow rule. The subnet's stateless NACL allows inbound TCP 443 from the internet but allows outbound traffic only when the destination port is 443. Internet clients use ephemeral ports 49152–65535.

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?

Allow inbound TCP ports 49152–65535 in the security group from the internet.
Allow outbound TCP port 443 in the security group to the internet.
Allow outbound TCP ports 49152–65535 in the NACL to the internet.
Allow inbound TCP ports 49152–65535 in the NACL from the internet.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Cloud Network Controls

Practice Cloud Network Controls in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Cloud Network Controls, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A cloud web server accepts TCP connections on port 443. Its stateful security group allows inbound TCP 443 from the internet and has no outbound allow rule. The subnet's stateless NACL allows inbound TCP 443 from the internet but allows outbound traffic only when the destination port is 443. Internet clients use ephemeral ports 49152–65535.

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?

  1. Allow inbound TCP ports 49152–65535 in the security group from the internet.
  2. Allow outbound TCP port 443 in the security group to the internet.
  3. Allow outbound TCP ports 49152–65535 in the NACL to the internet. (correct answer)
  4. Allow inbound TCP ports 49152–65535 in the NACL from the internet.
Explanation: 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).

Question 2

A partner network must reach an application on TCP 8443. The subnet NACL permits inbound TCP 8443 from the partner CIDR and permits all required return traffic. The application's security group permits TCP 8443 only from the corporate CIDR. Routing between the partner and the cloud network is already operational.

Which single change is sufficient to permit the partner connection while retaining the existing network path?

  1. Add an inbound TCP 8443 security group rule for the partner CIDR. (correct answer)
  2. Add another inbound TCP 8443 NACL rule for the partner CIDR.
  3. Add an outbound TCP 8443 security group rule for the partner CIDR.
  4. Add a more specific route for the partner CIDR to the subnet route table.
Explanation: 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).

Question 3

A virtual machine has two security groups attached. SG-Restricted allows inbound SSH only from 192.0.2.0/24. SG-Operations temporarily allows inbound SSH from 0.0.0.0/0. The subnet NACL and routing permit the traffic. The cloud platform combines the allow rules of all security groups attached to an interface.

What is the effective result for a new SSH connection from 198.51.100.40?

  1. The connection is denied because every attached security group must allow the source.
  2. The connection is allowed because one attached security group permits the source. (correct answer)
  3. The connection is denied because the more specific security group rule takes precedence.
  4. The connection is allowed only if SG-Operations was attached before SG-Restricted.
Explanation: 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.

Question 4

An administrative server is dual-stack. The intended policy requires both its security group and subnet NACL to restrict SSH to corporate address ranges. For IPv4, both controls allow TCP 22 only from 192.0.2.0/24. During IPv6 deployment, both controls were configured to allow TCP 22 from ::/0. The corporate network has a documented IPv6 prefix of 2001:db8:1200::/48.

Which change correctly applies the intended defense-in-depth policy to both protocol families?

  1. Keep the IPv6 rules because the IPv4 SSH restriction also filters IPv6-mapped traffic.
  2. Restrict IPv6 only in the security group because the NACL's IPv4 rule covers both families.
  3. Replace both ::/0 SSH allows with allows from 2001:db8:1200::/48. (correct answer)
  4. Remove the IPv6 security group rule but retain the NACL's ::/0 SSH allow.
Explanation: 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.

Question 5

A cloud platform evaluates NACL rules from the lowest rule number upward and applies the first match. A subnet NACL contains these inbound rules: rule 100 denies all protocols from 10.20.0.0/16, rule 110 allows TCP 443 from 10.20.5.0/24, and the final rule denies all remaining traffic. A server's security group allows TCP 443 from 10.20.5.0/24.

A client at 10.20.5.25 cannot connect to the server. Which change preserves the broad deny while enabling the intended exception?

  1. Add another security group allowing TCP 443 from the entire 10.20.0.0/16 network.
  2. Place the 10.20.5.0/24 allow rule before the 10.20.0.0/16 deny rule. (correct answer)
  3. Move the 10.20.0.0/16 deny rule after the NACL's final deny-all rule.
  4. Change the security group rule to allow all TCP ports from 10.20.5.0/24.
Explanation: 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.

Question 6

One compromised virtual machine shares a subnet with ten healthy production machines. Each machine has a dedicated security group, but all use the same subnet NACL. The response team wants to prevent new outbound connections from the compromised machine without disrupting new outbound connections from the healthy machines.

Which action best meets the requirement with the smallest network-control blast radius?

  1. Add a subnet NACL deny for the compromised machine's source IP on all outbound traffic.
  2. Replace the compromised machine's security group with a quarantine security group that has no outbound allows. (correct answer)
  3. Remove all outbound rules from the NACL currently associated with the shared subnet.
  4. Add an outbound deny rule to the compromised machine's existing security group.
Explanation: 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.

Question 7

A database security group allows inbound TCP 5432 from any network interface associated with the application security group. Existing application instances in 10.1.0.0/24 can connect. New instances associated with the same application security group are launched in 10.2.0.0/24 and cannot connect. The database subnet's stateless NACL allows inbound TCP 5432 only from 10.1.0.0/24 and allows all required response traffic.

Which action most directly restores database access for the new instances while retaining security-group-based workload identity?

  1. Add each new instance's private address as a source in the database security group.
  2. Associate the database security group with every new application network interface.
  3. Allow TCP 5432 to 10.2.0.0/24 in the application subnet's inbound NACL.
  4. Allow inbound TCP 5432 from 10.2.0.0/24 in the database subnet's NACL. (correct answer)
Explanation: 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.

Question 8

A virtual machine has a public IPv4 address and a subnet default route to an internet gateway. Its NACL allows inbound and outbound web traffic. Its security group allows inbound TCP 443 only from 203.0.113.0/24. A user at 198.51.100.60 attempts to connect to the machine's public address.

Which statement best explains the expected result?

  1. The connection succeeds because the public address implicitly overrides resource-level inbound filtering.
  2. The connection succeeds because a default internet route is more specific than security group rules.
  3. The connection fails because internet reachability does not replace the security group's source restriction. (correct answer)
  4. The connection fails because a NACL cannot permit traffic to a publicly addressed virtual machine.
Explanation: 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.

Question 9

Several public application servers share a subnet. Their security groups allow inbound TCP 443 from any source. A newly identified hostile network, 198.51.100.0/24, must be blocked immediately, while HTTPS access from all other internet sources remains available. Security groups on this platform contain allow rules but no explicit deny rules. The NACL supports ordered allow and deny rules.

Which control change most directly enforces the requirement across the shared subnet?

  1. Add a high-priority NACL deny for 198.51.100.0/24 before the broad HTTPS allow. (correct answer)
  2. Add a security group allow for every public source except 198.51.100.0/24.
  3. Add a security group deny for 198.51.100.0/24 to each application server.
  4. Place the NACL deny for 198.51.100.0/24 after the broad HTTPS allow.
Explanation: 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?"

Question 10

A managed proxy load balancer accepts internet TCP 443 using SG-LB. For each request, it creates a new TCP connection to an application instance on port 8443 using an interface associated with SG-LB. The application uses SG-App, which allows inbound TCP 8443 only from interfaces associated with SG-LB. The applicable NACLs allow the required traffic. The application instance also has a public address.

What happens if an internet client attempts to bypass the load balancer and connect directly to the application's public address on TCP 8443?

  1. The connection succeeds because SG-LB's internet-facing rule is inherited by the application.
  2. The connection succeeds because the application's public address satisfies the SG-LB source reference.
  3. The connection fails because NACLs reject traffic that does not traverse a load balancer.
  4. The connection fails because the client is not an interface associated with SG-LB. (correct answer)
Explanation: 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.