# 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
```json
{
"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.
```json
{
"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
```json
{
"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
```json
{
"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
1. replace the role with workload-specific permissions;
2. block or reduce metadata abuse paths where possible;
3. review where the workload truly needs AWS API access;
4. 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
```bash
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.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.product-security.expert/learning-labs-interview-and-templates/index-1/aws-cloud-security-assessment-pack.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.