AWS Security, Identity & Compliance: Policies

In the AWS ecosystem, Policies are the fundamental building blocks of security. They are JSON documents that define permissions, specifying exactly “Who” can do “What” on “Which” resource, and under “What” conditions. Mastering policy evaluation logic is critical for passing the SAA-C03 exam.

The Security Badge Analogy

Imagine a high-security office building:

Identity-based Policy: Your employee ID badge lists the rooms you are allowed to enter. You carry this with you.
Resource-based Policy: A list posted on a specific door (like the server room) stating exactly which individuals are allowed inside, regardless of what their ID badge says.

Core Policy Types for SAA-C03

1. Identity-Based Policies

Attached to IAM users, groups, or roles. These define what the identity can do. They come in two flavors:

AWS Managed: Created and maintained by AWS (e.g., AdministratorAccess).
Customer Managed: Created by you for fine-grained control.
Inline: Embedded directly into a single user/role (not recommended for reuse).

2. Resource-Based Policies

Attached directly to a resource (e.g., S3 Bucket Policies, SQS Queue Policies, KMS Key Policies). Unlike identity-based policies, these must specify a Principal (who is getting the permission).

3. Service Control Policies (SCPs)

Used in AWS Organizations to manage permissions across multiple accounts. SCPs act as a “guardrail.” Crucial Exam Note: SCPs do not grant permissions; they filter the maximum permissions available to IAM users and even the Root user in member accounts.

Policy Comparison Table

Feature	Identity-based	Resource-based	SCP (Organizations)
Attached To	IAM User, Group, Role	S3, SQS, KMS, etc.	OU or AWS Account
Principal Element	Implicit (the attached entity)	Required	N/A (Applies to all)
Limits Root User?	No	No	Yes
Use Case	Daily user permissions	Cross-account access	Governance guardrails

Decision Matrix / If–Then Guide

If you need to grant an external AWS account access to your S3 bucket… Then use a Resource-based Policy (Bucket Policy).
If you need to ensure no one in a Dev account can delete CloudWatch Logs… Then apply an SCP with a Deny effect.
If you want to limit the maximum permissions an admin can grant to a new user… Then use a Permissions Boundary.
If you need to grant an EC2 instance permission to access DynamoDB… Then use an IAM Role with an Identity-based policy.

Exam Tips and Gotchas

The “Explicit Deny” Rule: An explicit Deny in any policy (IAM, SCP, or Resource-based) always overrides any Allow.
Implicit Deny: By default, all requests are denied unless specifically allowed.
Cross-Account Access: To access a resource in Account B from Account A, you usually need permission in Account A (Identity-based) AND permission in Account B (Resource-based or Role Trust Policy).
SCP vs IAM: If an SCP denies s3:PutObject, even an Admin with FullS3Access in that account cannot upload files.
JSON Structure: Remember PARC (Principal, Action, Resource, Condition). Principal is only for Resource-based policies.

Topics covered:

Summary of key subtopics covered in this guide:

IAM Policy Structure (Version, Statement, Effect, Action, Resource, Condition)
Managed vs. Customer Managed vs. Inline Policies
Resource-based Policies (S3, KMS, SQS)
AWS Organizations & Service Control Policies (SCPs)
Permission Boundaries and Session Policies
The Policy Evaluation Logic (Deny > Allow > Default Deny)

Infographic: Policy Evaluation Logic

JSON Anatomy

{ “Effect”: “Allow”, “Action”: “s3:GetObject”, “Resource”: “arn:aws:s3:::my-bucket/*”, “Condition”: { “IpAddress”: {“aws:SourceIp”: “1.2.3.4”} } }

Condition: Adds extra security like IP restrictions or MFA requirements.

Service Ecosystem

IAM: Identity management center.

Organizations: Centralized policy control (SCPs).

CloudTrail: Logs who used which policy to perform an action.

Access Analyzer: Identifies resources shared with external entities.

Optimization & Cost

Cost: IAM and Policies are Free services.

Performance: Policy evaluation happens in milliseconds. To optimize, use Groups instead of attaching policies to individual users.

Limit: Managed policies have a character limit (6,144 characters). Use multiple policies if needed.

Production Use Case

Scenario: A financial company wants to ensure no developer can disable encryption on S3 buckets, even if they have Admin rights in their sandbox account.

Solution: Apply an SCP at the Organizational Unit (OU) level that explicitly Denies the s3:PutBucketEncryption action. Since Deny trumps Allow, the developer is blocked regardless of their local IAM permissions.