AWS Cloud Security Assessment Pack

Intro: These tasks look like the kind of cloud-security assessment questions a hiring loop gives to see whether someone can reason from IAM, networking, logging, and workload behavior—not just recite service names.

What this page includes

five AWS-focused snippet labs;

misconfiguration analysis with safer remediations;

emphasis on IAM, S3, EC2, CloudTrail, and OIDC trust.

Task 1 - CI role trust policy is too broad

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:example-org/*"
        }
      }
    }
  ]
}

Prompt

Why is this dangerous for deployment? Tighten it.

Reveal the worked answer

Problem

Any repository in the org could match the trust condition. For a production deploy role, that is usually too broad.

Better trust policy

Scope to one repo and, ideally, one ref pattern or environment.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:example-org/invoice-api:ref:refs/tags/v*"
        }
      }
    }
  ]
}

Task 2 - S3 bucket policy allows destructive access to too many principals

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::team-artifacts/*"
    }
  ]
}

Prompt

List the obvious and non-obvious problems.

Reveal the worked answer

Obvious problems

public access through Principal: "*";
write and delete open to everyone;
no condition boundary for source account, VPC endpoint, or principal tag.

Non-obvious problems

artifact tampering risk;
malware planting or artifact swap;
deletion of release evidence;
supply-chain compromise if downstream systems trust the bucket.

Better direction

block public access at bucket and account level;
allow only named roles;
separate read, write, and delete paths;
enable versioning and ideally Object Lock where justified.

Task 3 - EC2 instance profile is used as a convenience admin role

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

Prompt

Explain why this is a classic cloud attack-chain starter and what you would do first.

Reveal the worked answer

Why it matters

If the instance is compromised through SSRF, remote code execution, or an agent flaw, the attacker can use the instance role as a broad admin principal.

First fixes

replace the role with workload-specific permissions;
block or reduce metadata abuse paths where possible;
review where the workload truly needs AWS API access;
alert on unusual role behavior via CloudTrail and GuardDuty / SIEM logic.

Task 4 - CloudTrail exists but does not cover what the team thinks it covers

Scenario

The team says: “CloudTrail is on, so investigations are fine.”

Returned config summary:

trail is single-region;
management events only;
no data events;
logs stored in one account bucket;
no validation enabled.

Prompt

What is missing and why should security care?

Reveal the worked answer

Missing coverage

multi-region visibility;
S3/Lambda or other data events where relevant;
log file validation;
strong centralization and restricted read/write paths;
likely incomplete event coverage for object-level or workload-level investigations.

Safer direction

org trail or strong central trail design;
multi-region enabled;
data events for critical resources;
restricted bucket policy plus validation;
alerting for trail modification and logging gaps.

Task 5 - Security group is “temporary” but now part of production baseline

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0

Prompt

What should the candidate say beyond “don’t expose SSH to the world”?

Reveal the worked answer

Strong answer should include

explain Internet-wide SSH exposure increases brute-force, password spray, exploit, and operator-error risk;
recommend SSM Session Manager or a bastion / JIT path instead of broad SSH exposure;
verify if port 22 is needed at all;
add detective controls for new wide-open rules;
review whether the instance is in a subnet and route posture consistent with private access.