Bird
Raised Fist0
AWScloud~10 mins

Stateful behavior of security groups in AWS - Interactive Code Practice

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to specify that the security group allows inbound HTTP traffic.

AWS
security_group = {
  "IpPermissions": [
    {
      "IpProtocol": "tcp",
      "FromPort": 80,
      "ToPort": 80,
      "IpRanges": [
        {"CidrIp": "[1]"}
      ]
    }
  ]
}
Drag options to blanks, or click blank then click option'
Alocalhost
B192.168.1.1/32
C255.255.255.0
D0.0.0.0/0
Attempts:
3 left
💡 Hint
Common Mistakes
Using an IP address without a CIDR suffix.
Using a private IP range that blocks public access.
2fill in blank
medium

Complete the code to allow outbound HTTPS traffic in the security group.

AWS
security_group = {
  "IpPermissionsEgress": [
    {
      "IpProtocol": "tcp",
      "FromPort": 443,
      "ToPort": 443,
      "IpRanges": [
        {"CidrIp": "[1]"}
      ]
    }
  ]
}
Drag options to blanks, or click blank then click option'
A10.0.0.0/8
B0.0.0.0/0
C172.16.0.0/12
D192.168.0.0/16
Attempts:
3 left
💡 Hint
Common Mistakes
Restricting outbound traffic to private IP ranges only.
Using an IP address without CIDR notation.
3fill in blank
hard

Fix the error in the security group rule that blocks all inbound traffic except SSH.

AWS
security_group = {
  "IpPermissions": [
    {
      "IpProtocol": "tcp",
      "FromPort": 22,
      "ToPort": 22,
      "IpRanges": [
        {"CidrIp": "[1]"}
      ]
    }
  ]
}
Drag options to blanks, or click blank then click option'
A22.22.22.22/32
B255.255.255.255/32
C0.0.0.0/0
Dlocalhost
Attempts:
3 left
💡 Hint
Common Mistakes
Using 0.0.0.0/0 which allows SSH from anywhere.
Using invalid IP addresses or missing CIDR suffix.
4fill in blank
hard

Fill both blanks to create a security group rule that allows inbound TCP traffic on port 8080 only from a specific subnet.

AWS
security_group = {
  "IpPermissions": [
    {
      "IpProtocol": "[1]",
      "FromPort": [2],
      "ToPort": 8080,
      "IpRanges": [
        {"CidrIp": "10.0.1.0/24"}
      ]
    }
  ]
}
Drag options to blanks, or click blank then click option'
Atcp
Budp
C8080
D80
Attempts:
3 left
💡 Hint
Common Mistakes
Using UDP protocol for TCP traffic.
Setting FromPort to a different port than ToPort.
5fill in blank
hard

Fill all three blanks to define a security group rule that allows outbound UDP traffic on port 53 to all IP addresses.

AWS
security_group = {
  "IpPermissionsEgress": [
    {
      "IpProtocol": "[1]",
      "FromPort": [2],
      "ToPort": [3],
      "IpRanges": [
        {"CidrIp": "0.0.0.0/0"}
      ]
    }
  ]
}
Drag options to blanks, or click blank then click option'
Atcp
B53
Cudp
D80
Attempts:
3 left
💡 Hint
Common Mistakes
Using TCP instead of UDP for DNS traffic.
Setting port numbers incorrectly.

Practice

(1/5)
1. What does it mean when we say AWS security groups are stateful?
easy
A. Return traffic is automatically allowed, even if no outbound rule exists
B. You must create separate rules for inbound and outbound traffic
C. Security groups remember user login sessions
D. They block all traffic by default without exceptions

Solution

  1. Step 1: Understand stateful behavior in security groups

    Stateful means the security group tracks connections and allows return traffic automatically.
  2. Step 2: Apply this to inbound and outbound rules

    If inbound traffic is allowed, the response outbound traffic is automatically allowed without explicit outbound rules.
  3. Final Answer:

    Return traffic is automatically allowed, even if no outbound rule exists -> Option A
  4. Quick Check:

    Stateful = automatic return traffic allowed [OK]
Hint: Remember: inbound allows return outbound automatically [OK]
Common Mistakes:
  • Thinking outbound rules must explicitly allow return traffic
  • Confusing stateful with session management
  • Assuming security groups block all traffic by default
2. Which of the following is the correct way to allow inbound HTTP traffic on port 80 in a security group?
easy
A. Inbound: TCP port 22 from 0.0.0.0/0
B. Outbound: TCP port 80 from 0.0.0.0/0
C. Inbound: UDP port 80 from 0.0.0.0/0
D. Inbound: TCP port 80 from 0.0.0.0/0

Solution

  1. Step 1: Identify the correct protocol and port for HTTP

    HTTP uses TCP protocol on port 80.
  2. Step 2: Confirm the direction and source

    Inbound rules control incoming traffic; source 0.0.0.0/0 means from anywhere.
  3. Final Answer:

    Inbound: TCP port 80 from 0.0.0.0/0 -> Option D
  4. Quick Check:

    HTTP inbound = TCP 80 inbound [OK]
Hint: Inbound TCP 80 for HTTP, outbound not needed [OK]
Common Mistakes:
  • Using UDP instead of TCP for HTTP
  • Setting outbound instead of inbound rule
  • Using port 22 which is for SSH
3. If a security group allows inbound SSH (port 22) from a specific IP, what happens when the instance responds to that SSH request?
medium
A. The response is blocked unless an outbound rule allows port 22
B. The response is automatically allowed due to stateful behavior
C. The response is allowed only if a separate inbound rule exists
D. The response is blocked by default and requires a NAT gateway

Solution

  1. Step 1: Recall stateful nature of security groups

    Security groups track connections and allow return traffic automatically.
  2. Step 2: Apply to SSH inbound and response outbound

    Inbound SSH allowed means response outbound traffic is automatically allowed without extra rules.
  3. Final Answer:

    The response is automatically allowed due to stateful behavior -> Option B
  4. Quick Check:

    Inbound SSH allows automatic response outbound [OK]
Hint: Inbound allows return traffic automatically [OK]
Common Mistakes:
  • Thinking outbound rules must explicitly allow return traffic
  • Confusing inbound and outbound directions
  • Assuming NAT gateway is needed for return traffic
4. You created a security group with only an outbound rule allowing all traffic, but no inbound rules. You cannot connect to your instance via SSH. What is the likely problem?
medium
A. Inbound SSH traffic is blocked because no inbound rule allows port 22
B. Outbound rules block SSH response traffic
C. Security groups require both inbound and outbound rules for SSH
D. The instance must have a public IP to allow SSH

Solution

  1. Step 1: Analyze the security group rules

    Only outbound rules exist; no inbound rules allow SSH (port 22).
  2. Step 2: Understand inbound rules control incoming connections

    Without inbound port 22 allowed, SSH connection attempts are blocked.
  3. Final Answer:

    Inbound SSH traffic is blocked because no inbound rule allows port 22 -> Option A
  4. Quick Check:

    No inbound port 22 = no SSH access [OK]
Hint: Inbound rules must allow SSH for connection [OK]
Common Mistakes:
  • Assuming outbound rules control incoming SSH
  • Thinking both inbound and outbound rules are mandatory for SSH
  • Ignoring instance public IP requirement
5. You want to allow inbound HTTP traffic from anywhere and ensure your instance can respond properly. Which security group configuration achieves this with minimal rules?
hard
A. Allow inbound TCP port 80 and outbound TCP port 80 from 0.0.0.0/0
B. Allow inbound TCP port 80 from 0.0.0.0/0 and outbound all traffic
C. Allow inbound TCP port 80 from 0.0.0.0/0 only
D. Allow inbound all traffic and outbound all traffic

Solution

  1. Step 1: Recall stateful behavior of security groups

    Inbound rules allow return outbound traffic automatically without explicit outbound rules.
  2. Step 2: Apply minimal rule principle

    Allowing inbound TCP port 80 from anywhere is enough; no outbound rule needed for response.
  3. Final Answer:

    Allow inbound TCP port 80 from 0.0.0.0/0 only -> Option C
  4. Quick Check:

    Inbound HTTP alone allows response outbound [OK]
Hint: Only inbound HTTP needed; outbound auto allowed [OK]
Common Mistakes:
  • Adding unnecessary outbound rules for return traffic
  • Allowing all inbound traffic instead of just HTTP
  • Confusing outbound rules as mandatory for responses