Reading IAM policies is important. Writing them is where the knowledge solidifies. In this exercise, you will write IAM policies for five real-world scenarios that GRC engineers encounter regularly. Each scenario presents a specific access requirement, and your job is to write the minimum-privilege policy that satisfies it.
These are not trick questions. They are based on actual access patterns in production AWS environments. The goal is precision — granting exactly the permissions needed, scoping to specific resources, and including conditions where appropriate.
For each scenario, you will see a description of the requirement, a JSON template with placeholders to get you started, and a reference solution you can reveal after you have written your own version. Write your policy first, then compare.
Scenario 1: S3 Read-Only Access
Exercise
~30 min
Write an IAM policy for this scenario
Scenario
S3 Read-Only Access for a Data Analyst
A data analyst needs read-only access to a specific S3 bucket containing quarterly financial reports. They need to list the contents of the bucket and download individual objects, but must not be able to upload, modify, or delete anything.
- The bucket name is company-quarterly-reports
- The analyst should be able to list objects in the bucket and download (get) any object
- No write, delete, or administrative actions should be permitted
- Note: ListBucket applies to the bucket ARN, while GetObject applies to the objects inside (bucket ARN with /*)
Write your IAM policy in JSON below. The policy must be a valid JSON object.
Scenario 2: Cross-Account Assume Role (Trust Policy)
Exercise
~30 min
Write an IAM policy for this scenario
Scenario
Cross-Account Audit Role Trust Policy
The security team in account 111111111111 needs to assume a read-only audit role in account 222222222222. Write the trust policy for the role in account 222222222222 that allows only the security team's role to assume it, and only when MFA is present.
- This is a trust policy (attached to the role being assumed), not an identity-based policy
- The security team's role ARN in account 111111111111 is: arn:aws:iam::111111111111:role/SecurityTeamRole
- MFA must be required as a condition — use the aws:MultiFactorAuthPresent condition key
- The Action for trust policies is sts:AssumeRole and the Principal specifies who can assume the role
Write your IAM policy in JSON below. The policy must be a valid JSON object.
Scenario 3: SCP — Deny CloudTrail Deletion
Exercise
~30 min
Write an IAM policy for this scenario
Scenario
SCP: Protect CloudTrail Integrity
Write a Service Control Policy (SCP) that prevents anyone in the organization from stopping CloudTrail logging, deleting CloudTrail trails, or modifying event selectors. This SCP will be attached to the root OU to protect audit log integrity across all accounts.
- SCPs use the same JSON syntax as IAM policies but are attached at the Organization/OU level
- This should be a Deny policy — SCPs with deny effect cannot be overridden by any IAM policy
- The actions to deny: cloudtrail:StopLogging, cloudtrail:DeleteTrail, cloudtrail:PutEventSelectors
- Resource should be * since this applies organization-wide to all CloudTrail trails
Write your IAM policy in JSON below. The policy must be a valid JSON object.
Scenario 4: Least-Privilege Lambda Execution Role
Exercise
~30 min
Write an IAM policy for this scenario
Scenario
Least-Privilege Lambda Execution Role
A Lambda function processes images uploaded to an S3 bucket and writes metadata to a DynamoDB table. Write the identity-based policy for the Lambda execution role that grants exactly the permissions needed — no more.
- The S3 bucket name is image-uploads — the Lambda needs to read (GetObject) images from it
- The DynamoDB table name is image-metadata in us-east-1, account 123456789012 — the Lambda needs to write items (PutItem)
- The Lambda also needs to write logs to CloudWatch Logs (CreateLogGroup, CreateLogStream, PutLogEvents)
- Use specific resource ARNs wherever possible: arn:aws:s3:::image-uploads/* for S3, arn:aws:dynamodb:us-east-1:123456789012:table/image-metadata for DynamoDB, arn:aws:logs:us-east-1:123456789012:* for CloudWatch Logs
Write your IAM policy in JSON below. The policy must be a valid JSON object.
Scenario 5: Permission Boundary
Exercise
~30 min
Write an IAM policy for this scenario
Scenario
Permission Boundary for Delegated Role Creation
A team lead can create IAM roles for their team members. You need to ensure that any role the team lead creates can never have more than S3 and DynamoDB permissions — even if the team lead attaches AdministratorAccess. Write the permission boundary policy that limits the maximum possible permissions.
- Permission boundaries define the maximum permissions an identity-based policy can grant
- This boundary should allow all S3 actions (s3:*) and all DynamoDB actions (dynamodb:*) only
- Even if a role has AdministratorAccess, the permission boundary will restrict effective permissions to the intersection
- Resource should be * for both services since the boundary applies to actions regardless of specific resources
Write your IAM policy in JSON below. The policy must be a valid JSON object.
After you finish
Review your solutions against the references. Pay attention to these common mistakes:
- Missing the second S3 resource ARN.
s3:ListBucketoperates on the bucket (arn:aws:s3:::bucket-name), whiles3:GetObjectoperates on the objects inside (arn:aws:s3:::bucket-name/*). Forgetting one of the two ARNs is the most common S3 policy error. - Overly broad resources. Using
"Resource": "*"when you could scope to a specific bucket, table, or log group. Least privilege applies to resources, not just actions. - Missing conditions. Cross-account assume-role policies should require MFA. Forgetting the condition weakens the control even if the Principal is correctly scoped.
- Confusing allow and deny in SCPs. The CloudTrail SCP is a deny policy. If you wrote it as an allow policy, you misunderstood the purpose — deny SCPs are preventive controls that cannot be overridden.
Each correctly written policy maps directly to a control you would document in a SOC 2 or ISO 27001 assessment. The S3 read-only policy demonstrates least privilege (CC6.3). The cross-account trust policy demonstrates access control and MFA enforcement (CC6.1, CC6.3). The SCP demonstrates preventive controls for audit log integrity (CC7.2). The Lambda role demonstrates least privilege for machine identities. The permission boundary demonstrates delegated administration with guardrails.