Exercises: Cloud Security

These exercises build the two reflexes a cloud defender lives by: reading an IAM policy or a security-group rule and seeing the over-broad grant, and knowing which side of the shared-responsibility line a problem falls on. Difficulty is marked ⭐ (recall/application), ⭐⭐ (analysis), and ⭐⭐⭐ (synthesis/open-ended). A dagger (†) marks problems with a full worked solution in Appendix: Answers to Selected Exercises — try every problem before you read one.

All identifiers are documentation values: account 123456789012, meridianbank.example, TEST-NET source IPs, and AKIA...EXAMPLE keys. Never put a real account ID, key, or routable IP in your own work either.

Part A — Shared responsibility & service models ⭐

1.† For each scenario, state whether the security task is the provider's responsibility, the customer's, or shared, and name the service model (IaaS/PaaS/SaaS): (a) patching the operating system of an EC2 instance running a web server; (b) patching the database engine of an Amazon RDS managed database; (c) deciding which employees can read a Google Workspace shared drive; (d) the physical security of the datacenter housing your Azure VMs; (e) enabling encryption at rest on an S3 bucket holding customer data; (f) the durability of the S3 storage service itself.

2. In one sentence each, define IaaS, PaaS, and SaaS, and state what layer of the stack the customer's security responsibility starts at in each.

3. Two layers are the customer's responsibility in every service model, including SaaS. Name them and explain in two sentences why a cloud provider can never take them over.

4.† An engineer argues: "We moved to the cloud, so security is the provider's job now — that's what we're paying for." Rebut this in three to four sentences using the shared-responsibility model. Name one specific layer the move did not offload.

5. A SaaS application (say, a CRM) is breached because a departed employee's account was never disabled and had broad access. Whose responsibility was the failed control, and why does "the vendor got breached" misdescribe what happened?

Part B — Find the misconfiguration ⭐⭐

6.† Find the public bucket. Here is a simplified S3 bucket ACL. (a) Is this bucket public? (b) Which specific grant makes it so? (c) What is the attacker's "exploit," and (d) what single account-level control would have prevented this regardless of the ACL?

Grants:
  - Grantee: { ID: "a1b2c3...ownerid" }                          Permission: FULL_CONTROL
  - Grantee: { URI: "http://acs.amazonaws.com/groups/global/AllUsers" }  Permission: READ

7.† Find the over-broad policy. Review this IAM policy attached to a log-shipping job that only needs to write objects to one bucket. (a) What does this policy actually grant? (b) What is the precise risk if the job's credentials leak? (c) Rewrite it as a least-privilege policy.

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "*", "Resource": "*" }
  ]
}

8. Find the wide-open firewall. A security group on a production database instance has these inbound rules. Identify every dangerous rule, say what each exposes, and give a least-privilege replacement (assume the application tier is in 10.20.0.0/24 and a bastion host is 10.20.255.10/32).

Protocol  Port   Source        Description
TCP       5432   0.0.0.0/0     PostgreSQL
TCP       22     0.0.0.0/0     SSH
TCP       443    0.0.0.0/0     HTTPS app
ICMP      -      10.20.0.0/24  ping from app tier

9. Spot the subtle one. An IAM policy grants "Action": ["iam:CreateUser", "iam:AttachUserPolicy", "iam:CreateAccessKey"] on "Resource": "*" to a deployment role. The role does not use wildcards for Action, so a quick scan calls it "scoped." Explain why this policy is nonetheless extremely dangerous — what can an attacker who steals this role's credentials do? (Hint: think about privilege escalation.)

10.† Read the log. You find this (illustrative) CloudTrail event. Walk through what each field tells you, state what just happened in one sentence, and decide whether it should page the on-call analyst.

{
  "eventTime": "2026-06-14T03:11:54Z",
  "eventName": "StopLogging",
  "eventSource": "cloudtrail.amazonaws.com",
  "userIdentity": { "type": "IAMUser", "userName": "svc-deploy", "accountId": "123456789012" },
  "sourceIPAddress": "198.51.100.23",
  "errorCode": null
}

11. Read the log, harder. Three CloudTrail events occur within ninety seconds from the same source IP and credential: CreateAccessKey (for an existing user), AttachUserPolicy (attaching an admin policy), PutBucketAcl (public-read on a customer-data bucket). Describe the likely attack narrative these three events tell together, and name the detection that would have caught it earliest.

Part C — Analyze this (scenarios & telemetry) ⭐⭐

12.† The metadata chain. A public web app on a cloud VM has a server-side request forgery (SSRF) bug. The VM's attached role grants "Action": "*". (a) Step through how an attacker turns the SSRF bug into full account compromise, naming the 169.254.169.254 step. (b) List three independent controls, each of which alone would break the chain, and say at which layer each sits.

13. A CSPM tool reports 4,000 findings across Meridian's AWS accounts on its first scan. Your manager says "fix them all this sprint." Describe, in steps, how you would turn 4,000 findings into a defensible priority order. Which two or three finding types would you put at the very top, and why?

14. Meridian's SOC has CloudTrail flowing into the SIEM but has written zero cloud detection rules. List the first five cloud detections you would build, in priority order, and for each name the key event(s) and the one-sentence reason it matters.

15. An engineer enables "S3 Block Public Access" account-wide. A product team complains that their public marketing website's images, served from a bucket, have stopped loading. (a) Why did this break? (b) How do you let the website work without making the bucket itself public? (c) What does this teach about the difference between "needs to be reachable by the public" and "the bucket must be public"?

Part D — Write it / design it ⭐⭐–⭐⭐⭐

16.† Write the IAM policy. A Meridian Lambda function must read objects from the bucket meridian-statements and write objects to the bucket meridian-statements-processed, and do nothing else. Write a least-privilege IAM policy granting exactly that, scoped to those two buckets, and requiring TLS. (Use the standard JSON policy form; you may use s3:GetObject, s3:ListBucket, s3:PutObject.)

17. Write the guardrail (in words). Express, as a plain-language service-control-policy rule, a guardrail that prevents any account in the organization from disabling CloudTrail — even by an account administrator. Explain why this must be a guardrail set above the account rather than an IAM policy within it.

18. Harden the account. You inherit a Meridian AWS account with: no Block Public Access, CloudTrail only in one region, three IAM users with "Action": "*" policies, MFA on none of them, and four long-lived AKIA...EXAMPLE access keys in use. Write an ordered remediation plan (what you do first, second, …) and justify the ordering by risk.

19. ⭐⭐⭐ Design the cloud security baseline. For a small fintech startup moving to AWS, draft a one-page cloud security baseline (six to eight requirements) covering storage, IAM, network, logging, encryption, and posture management. For each requirement, note whether it is a guardrail (preventive) or a detective control, and which shared-responsibility layer it addresses.

20. ⭐⭐⭐ Design it. Sketch (in words or a simple diagram) a multi-account AWS structure for Meridian that separates production from development, isolates the security/logging function, and applies organization-wide guardrails. Explain what each account is for and which guardrails you would enforce org-wide. (You are previewing structure used by zero-trust and DevSecOps chapters later.)

Part E — CTF-style challenge ⭐⭐⭐

21.† The leaked key. During a code review you find this in a public-facing repository's commit history:

# config/deploy.sh  (committed 14 months ago, never removed)
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

The key belongs to an IAM user with the over-broad policy from Exercise 7. (a) Rank, in order, the actions you take in the first fifteen minutes. (b) Which CloudTrail events would you search to determine whether the key was used by anyone other than the deploy job, and what would "impossible travel" or an unfamiliar source IP indicate? (c) What three preventive controls (one per layer: code, identity, detection) would have stopped this from becoming an incident? (The key shown is AWS's published documentation example — never a real credential.)

Part F — Interleaved & forward-looking ⭐⭐

22. (Interleave with Ch. 11.) You are hardening a cloud IaaS instance. List three host-hardening controls from Chapter 11 that apply unchanged in the cloud, and one cloud-specific control from this chapter that has no on-premises equivalent. Why does the OS hardening not "go away" in the cloud?

23. (Interleave with Ch. 6.) A security group is a firewall. Restate the Chapter 6/7 principle of default-deny in cloud security-group terms, and explain why a security group that starts with "allow all, then add denies" is backwards and dangerous.

24. (Interleave with Ch. 1.) Re-read the offense/defense asymmetry from Chapter 1. Explain why guardrails (preventive, automatic) respond to that asymmetry better than gates (a human approving each change) in a cloud environment where infrastructure is created thousands of times a day.

25. ⭐⭐⭐ Forward look. This chapter said "identity is the new perimeter." Based only on what you have seen, write two sentences predicting what a zero-trust architecture (Chapter 32) might add on top of cloud IAM — what would it verify that a static IAM policy does not?

Solutions to daggered (†) problems are in the Answers appendix. The remaining problems are deliberately open — bring them to a study group or your instructor.