Here’s your AWS Developer Associate Study Guide (Markdown format) — written like a clean, shareable internal doc or Notion page, with exam-focused callouts.
-
Used by applications to call AWS APIs via:
- AWS SDKs
- CLI
-
Consists of:
- Access Key ID
- Secret Access Key
- Provide temporary credentials (via STS)
- No long-term secrets stored
- Automatically rotated by AWS
App → IAM User → Access Keys → AWS Services
-
Often combined with:
- IAM Groups (shared permissions)
-
Keys stored in:
.env- config files
- CI/CD secrets
App → IAM Role → Temporary Credentials → AWS Services
Examples:
- EC2 Instance Role
- ECS Task Role
- Lambda Execution Role
-
Human-driven (rotate every 90 days)
-
Risk:
- Forgotten keys
- Downtime during rotation
-
Via:
- Secrets Manager
- IAM Access Analyzer + scripts
-
Access Keys = long-term credentials → NOT recommended
-
Roles = preferred (temporary, auto-rotated)
-
If question mentions:
- “application running on AWS” → USE IAM ROLE
- “external system” → access keys may still be used
-
Grant only required permissions
-
Avoid:
"Action": "*", "Resource": "*"
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::my-bucket/*"
}- Overly broad permissions = common wrong answer
- Always pick: 👉 “minimum permissions required”
- Strong Read-After-Write (NEW objects)
- Eventual consistency (overwrites & deletes)
- New object → immediately readable ✅
- Update/delete → may take time ❗
| Feature | Bucket Policy | ACL |
|---|---|---|
| Scope | Bucket/Object | Object |
| Language | JSON (IAM style) | Simple |
| Flexibility | High | Low |
| Recommended | ✅ Yes | ❌ Legacy |
- AWS prefers: 👉 Bucket Policies over ACLs
- ACLs = legacy / limited control
- Required for: 👉 Files > 5GB
- Parallel uploads
- Resume failed uploads
- Improved performance
- File > 5GB → MUST use multipart
- Can use for smaller files too (optimization)
- Uses CloudFront edge locations
- Speeds up uploads over long distances
-
Best for: 👉 global users uploading to a single bucket
-
Uses:
bucket.s3-accelerate.amazonaws.com
-
Blueprint for containers
-
Includes:
- Docker image
- CPU/memory
- IAM roles
- Running instance of a Task Definition
-
Keeps tasks running
-
Handles:
- Scaling
- Load balancing
- Auto-recovery
- Logical group of compute resources
- Serverless containers
- No EC2 management
- You manage instances
- More control
| Feature | Fargate | EC2 |
|---|---|---|
| Server management | ❌ None | ✅ Required |
| Scaling | Automatic | Manual/ASG |
| Cost | Higher | Lower (optimized) |
| Control | Low | High |
| Use case | Simple, fast deploy | Custom infra |
- “No server management” → FARGATE
- “Need full control / custom AMI” → EC2
- Used by application inside container
- Access AWS services (S3, DynamoDB)
“What my app can do” (Medium)
-
Used by ECS service/agent
-
Handles:
- Pulling images (ECR)
- Writing logs (CloudWatch)
“What ECS needs to run the container” (AWS Documentation)
- App accessing S3 → Task Role
- Pulling Docker image → Execution Role
- NEVER put app permissions in execution role
- Prefer roles over access keys
- Use least privilege
- Strong consistency (new objects)
- Multipart for large files
- Bucket policy > ACL
- Task = container permissions
- Execution role = infrastructure permissions
- Fargate = serverless
-
If question says:
- “secure” → roles + least privilege
- “scalable uploads globally” → transfer acceleration
- “container needs AWS access” → task role
- “no server management” → Fargate