Exam AWS Certified SysOps Administrator - Associate topic 1 question 318 discussion

this is an utterly terrible question. that's it. that's my input.

bad kwazshin

This is a very confusing question. Option A could be an answer if the SG default Outbound rule that allows all protocols and all ports has been tempered with. This was not mentioned, therefore it is difficult to make this assumption. Option C could also be an answer if a rule was configured for the network ACL. Since network ACL is stateless, an Outbound rule could be necessary. This was not clarified either. Another solution to the problem described in this question is a NAT Gateway in public subnet that the instances in the private subnet could point to in the route table. Here, I'm assuming we already have an Internet Gateway for instances in the public subnet. Unfortunately, this could be the best answer to this question but none of the answers choices mentions a NAT Gateway.

C. Ensure that there is an outbound network ACL for ephemeral ports 1024-66535 to 0.0.0.0/0. Explanation: When an EC2 instance in a private subnet needs to access resources on the internet, such as https://www.example.com, it uses outbound connections. Outbound connections are controlled by the Network Access Control List (network ACL) associated with the subnet. Option C suggests ensuring that there is an outbound network ACL rule allowing traffic on ephemeral ports (1024-66535) to 0.0.0.0/0. Ephemeral ports are used as source ports for outbound connections, and allowing traffic from these ports is necessary for the EC2 instance to communicate with external resources. Options A and B involve security groups, but security groups are stateful and are applied to inbound and outbound traffic. In this case, the issue is likely related to the network ACL controlling outbound traffic from the subnet. Option D is not relevant to the issue. It mentions an outbound network ACL for port 80, but the issue is related to connecting to https://www.example.com, which uses port 443 for HTTPS.

A. It can't be, because when you try connect to https://www.example.com from inside of the EC2 instance, you don't use port 443 (HTTPS) on your machine, you use a random one and try to connect to 443 at the destination server. B. As security groups are stateful, you don't need special inbound rules C. This is the right answer, because the HTTPS-Connection uses a random port at your instance to try to connect to 443 on the destination server. D The connection has nothing to do with port 80 (HTTP).

who wrote this question?

Inbound security group rules control incoming traffic to the EC2 instance, and outbound security group rules control outgoing traffic. For the EC2 instance to access external resources on the internet, including https://www.example.com, you need to ensure that there is an outbound security group rule allowing traffic on port 443 to the destination IP or CIDR range (0.0.0.0/0 in this case).

Going for C based on this: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html

Default sg allows for outbound.

A seems right option

In security group rules are allowed in inbound.

A. Can' t be C because ephemeral ports 1024-65535 are not relevant to HTTPS communication.

https://repost.aws/knowledge-center/resolve-connection-sg-acl-inbound

It's important to remember that security groups are stateful. So if you have an outbound rule in your security group for HTTPS and you send a HTTPS request from your instance to a remote web server, the instance will be able to receive the response, even though port 443 is not allowed by your inbound rule in the security group. When a connection is made to or from an instance, a "state" is created that allows bidirectional communication - but only for that connection.

keyword ephemeral

I think question is not cleared. EC2 is private and where source to curl to EC2 that located in private subnet. No ALB and route 53 to manage traffic to EC2 in private subnet.

Option B is not correct because it refers to an inbound security group rule. Inbound security group rules control the traffic that is allowed to reach the instance from other sources. In this case, the issue is with traffic leaving the instance and reaching the website, so an outbound security group rule is needed, not an inbound one.