SOA-C02 Networking and Content Delivery Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Add inbound rules on the server to allow HTTP and HTTPS from the client security group.

  Why this is correct

  Security groups are stateful, so adding inbound rules on the server to permit HTTP (80) and HTTPS (443) from the client security group is the correct, minimal fix. The inbound rule allows the client's request to reach the server, and because stateful filtering tracks the connection, the server's response is automatically allowed back to the client without any outbound rule on the server. The client security group as the source scopes access precisely to instances with that group, avoiding a 0.0.0.0/0 exposure.

• ✗

  Add inbound rules on both the client and server.

  Why it's wrong here

  Adding inbound rules on both the client and server is incorrect because the client does not need inbound rules for this traffic. The client is the initiator and sends its HTTP/HTTPS request outbound; the response comes back automatically thanks to statefulness, so inbound on the client is redundant. Inbound rules on the client would only matter if you wanted to allow unsolicited traffic into the client, which is irrelevant to this connectivity problem. The only required change is an inbound rule on the server allowing traffic from the client security group.

• ✗

  Add outbound rules on both the client and server.

  Why it's wrong here

  Adding outbound rules on both the client and server misdiagnoses which direction the stateful evaluation occurs. The client needs an outbound rule only if its default outbound policy denies all traffic; without that, the request cannot leave the client. The server does not need an outbound rule for the response because security group statefulness automatically permits return traffic for an allowed inbound flow. Adding a server outbound rule is harmless but unnecessary, and adding outbound rules alone will not fix the problem if the server lacks the inbound allow for the request.

• ✗

  Add inbound rules on the client and outbound rules on the server.

  Why it's wrong here

  This option reverses where the inbound and outbound rules belong. Inbound rules on the client are unnecessary because the client is the source of the request, not the destination, and its responses are covered by stateful return-traffic handling. Outbound rules on the server are also not needed, since the server's response is automatically allowed after an inbound rule permits the matching request. The effective fix is to add an inbound rule on the server (not the client) that allows HTTP/HTTPS from the client security group; adding rules in the wrong direction leaves the server's inbound path blocked, so the request never reaches the service.

Go deeper

Related to this question