What's changed: In-scope service coverage (axis B): added Systems Manager (Parameter Store) and AppConfig config/feature-flag externalization definitions, roles, and selection criteria to s3.
3.1IAM and Authorizing Applications
Understand authorizing applications: temporary credentials via IAM roles (no embedded keys on Lambda/EC2), least-privilege policies, and assuming roles (AssumeRole). The core of "Security" in DVA-C02.
When an app accesses AWS services, never embed access keys in code. Instead use an IAM role to receive temporary credentials securely.
3.1.1Granting permissions to code
- IAM role: attached to Lambda or EC2 so the SDK auto-fetches temporary credentials. No long-lived keys.
- Least privilege: policies allow only the needed Actions and Resources; an explicit Deny always wins.
- AssumeRole (STS): temporarily assume another account/role’s permissions (STS issues temporary credentials); the standard for cross-account access.
- Policy types: identity-based (attached to users/roles) and resource-based (e.g., S3 bucket policy); access is decided by evaluating both.
The most important point in DVA-C02 "Security" is to never embed access keys in apps. Attach an IAM role (execution role) to Lambda/EC2 and the SDK auto-fetches temporary credentials. Use least privilege—Allow only the needed Actions and Resources—and remember an explicit Deny always wins. For another account/role’s permissions, use STS AssumeRole to assume them temporarily (no key handoff). Policies are identity-based (attached to roles/users) and resource-based (e.g., S3 bucket policy); access is decided by evaluating both. The classic wrong answer is "put access keys in code or plaintext env vars."
| Goal | Means |
|---|---|
| Access AWS from Lambda/EC2 | IAM role (execution role) |
| Temporarily get another role’s perms | STS AssumeRole |
| Allow access on the S3 bucket side | Resource-based policy |
| Avoid over-permission | Least privilege + explicit Deny |
Going one level deeper, policy evaluation has an order: an explicit Deny denies immediately; otherwise any Allow with no Deny permits; the default is an implicit deny. Condition keys enable fine-grained control like "only from a specific IP," "MFA required," or "only when tags match." A permissions boundary sets the maximum permissions a role/user can have, preventing over-grants when developers create their own roles. Policies come in three forms—AWS managed, customer managed, and inline—with customer-managed preferred for reuse and auditability. For Lambda, beyond the execution role, a resource-based policy controls which service (S3, API Gateway, etc.) may invoke the function.
Scenario: Lambda accessing another account’s S3. Attach an execution role to the Lambda (no embedded keys). To reach the other account’s S3, assume its role via STS AssumeRole, scoped to least privilege (only GetObject on that bucket). Also allow it on the S3 side via a bucket policy (resource-based). Access is decided by evaluating both identity- and resource-side policies.
Watch the mix-ups: (1) Never hard-code keys/use plaintext env vars—use IAM roles for temporary credentials. (2) AssumeRole (STS) is for cross-account/temporary permissions. (3) Identity-based and resource-based policies are both evaluated. (4) An explicit Deny always beats an Allow.
Q. How to grant Lambda permissions? Via the execution (IAM) role—no embedded keys. Q. Access another account’s resources? Use STS AssumeRole to temporarily assume their role. Q. Identity- vs resource-based? Identity-based attaches to roles/users; resource-based attaches to a resource (e.g., S3 bucket); both are evaluated.
Common on DVA: access AWS from Lambda/EC2 = IAM role (no embedded keys), temporarily take another role = STS AssumeRole, least privilege + explicit Deny wins, both identity- and resource-based policies evaluated. Hard-coded keys are a classic wrong answer.
3.1.2Section summary
- Authorize apps with IAM roles (temporary credentials); never embed keys
- Least privilege + explicit Deny wins; cross-account via STS AssumeRole; identity & resource policies both evaluated
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. What is the secure best practice for a Lambda function to access S3?
Q2. You want to temporarily assume a role in another account. What do you use?
Q3. Which is the best principle for IAM policy design?