Thuta Learning
Search
ExercisesDevOpsbeginner

Hands-On Practice Set 2

Relax. We'll talk through this in plain words — no textbook voice.

What you'll walk away with

  • Understand Hands-On Practice Set 2 without feeling intimidated by it
  • Get hands-on running the AWS CLI/Console yourself
  • Apply this concept immediately in a real project

Let's think about it this way for a moment

This round steps up from round 1 — instead of practicing each skill separately, you'll combine them all at once. That means choosing between serverless vs EC2-based architecture depending on the scenario, estimating monthly cost from service pricing, and writing a response plan for a production incident (database down). Budget about 10 minutes per task.

Let's connect it to a real scenario

Task 1: For a low-traffic side-project app (around 100 requests a day), decide whether EC2-based or serverless (Lambda) architecture fits better, and explain why. Task 2: For a t2.micro EC2 instance (running 24/7) plus a 20GB RDS db.t3.micro (Multi-AZ), estimate the approximate monthly cost once you're past the Free Tier, citing the AWS pricing page. Task 3: If a production RDS database suddenly becomes unavailable (with Multi-AZ enabled), write down the step-by-step order you'd investigate/respond in (CloudWatch, RDS Console, failover status). Task 4: Write the IAM Policy JSON for this requirement — 'the CI/CD pipeline should only be allowed to upload deploy artifacts to S3, with no permission to modify EC2/RDS.'

Let's walk through it together

text
# Task 3 - RDS unavailable incident response
1. Check CloudWatch alarms — which metric triggered?
2. Check RDS Console — is it a Multi-AZ failover in progress?
   (failover usually completes in 60-120 seconds automatically)
4. Check recent changes — was there a manual modification
   (instance class change, parameter group change)?
5. If failover completed, verify application reconnects
   (some apps cache the old DB endpoint's IP and need a restart)
6. Document root cause once resolved

# Task 4 - scoped IAM Policy sketch
{
  "Effect": "Allow",
  "Action": ["s3:PutObject"],
  "Resource": "arn:aws:s3:::deploy-artifacts-bucket/*"
}
# No ec2:* or rds:* actions granted at all.
You should see
You'll come away with a serverless vs EC2 decision, a cost estimate, an RDS incident response plan, and a scoped IAM Policy.

Try it in 5 minutes

Create an IAM User in a practice account and attach the Task 4 IAM Policy to it — run `aws ec2 describe-instances` and confirm you get an AccessDenied error (S3 PutObject, on the other hand, should work fine).

A quick word of caution

When writing an IAM Policy, don't just casually write `"*"` (wildcard, every resource) for the `Resource` field — write out exactly the bucket/resource named in the requirement.

Easy traps

  • Estimating cost by simply multiplying the per-hour rate without factoring in the instance's actual running time (24/7 vs part-time)
  • Writing an incident response plan that stops at 'it's back up now, so we're done' and leaves root-cause documentation out of the plan entirely

Now try it yourself

Create an IAM User in a practice account and attach the Task 4 IAM Policy to it — run `aws ec2 describe-instances` and confirm you get an AccessDenied error (S3 PutObject, on the other hand, should work fine).

You'll know it worked when: You'll come away with a serverless vs EC2 decision, a cost estimate, an RDS incident response plan, and a scoped IAM Policy.

Hands-On Practice Set 2 | Thuta Learning