Let's think about it this way for a moment
This round is about putting the Basic/Intermediate concepts you've already learned to practical use — telling EC2, S3, and RDS apart, spotting security gaps in an architecture, and designing IAM permissions correctly, all hands-on. Each task shouldn't take more than 5 minutes.
Let's connect it to a real scenario
Task 1: Explain the difference in what 'EC2', 'S3', and 'RDS' are each responsible for, in one sentence per service. Task 2: If an RDS instance sits in a Public Subnet with its Security Group open to 0.0.0.0/0 on port 5432, guess and write down what security risk that creates. Task 3: Explain the difference between an IAM User and an IAM Role, tied to the scenario of an EC2 instance connecting to S3. Task 4: If an EC2 instance is running but the website can't be accessed, write down the first 2 things you'd check (Security Group, or something else).
Let's walk through it together
# Task 2 - public RDS risk
RDS in a Public Subnet + Security Group open on 0.0.0.0/0:5432
= the database is reachable from anywhere on the internet.
An attacker can attempt brute-force login or exploit a
known database vulnerability directly, with no network
layer protecting it. RDS should always live in a Private
Subnet, reachable only from the app tier's Security Group.
# Task 4 - EC2 website unreachable, check:
1. Security Group — is port 80/443 open to the right source?
2. Is the web server process actually running on the instance?You'll come away knowing the differences between EC2/S3/RDS, the security risk of a public RDS, and how to decide between an IAM User vs Role.Try it in 5 minutes
Deliberately reproduce the Task 2 scenario in a practice account (Free Tier), then confirm via `nmap` or `telnet <ip> 5432` (from an external network) that the port is actually open — then close the Security Group back up.
A quick word of caution
Do not test this on a production account for this round — only reproduce the security gap inside a practice/sandbox account.