Map policy parts to their purpose

A teammate sends you one IAM policy statement to review before it ships. To read it the way AWS does, you first need to know what each part of the statement is for.

The statement has been broken into six fragments. Every fragment does one specific job in the decision AWS is about to make.

本练习是课程的一部分

Using AWS Security for Developers

查看课程

动手互动练习

通过我们的互动练习之一，将理论转化为实践

开始练习

本练习是课程的一部分

Using AWS Security for Developers

SkillTag.level.intermediateSkillTag.label

4.9+

9 reviews

免费开始课程

In this chapter, you'll build the mental model that keeps real AWS workloads safe: separating the actor from the principal AWS actually evaluates. You'll then learn to read an IAM policy the way AWS does, working out whether a call is allowed, denied, or silently blocked by nothing at all. Finally, you'll replace long-lived access keys with role assumption, temporary credentials, and pre-signed URLs, the pattern that removes a key from a repository for good.

Exercise 1: Introduction to AWS Security Exercise 2: Identify over-permissioned access paths Exercise 3: Give the function a narrow role Exercise 4: Almost nothing runs as you Exercise 5: IAM policy evaluation and explicit deny Exercise 6: Map policy parts to their purpose

当前练习

Exercise 7: See implicit deny in action Exercise 8: Predict the evaluation outcome Exercise 9: Roles, temporary credentials, and SigV4 Exercise 10: Decide who may assume the role Exercise 11: Scope a pre-signed URL Exercise 12: Swap a stored key for a role

In this chapter, you'll draw a clean line between Cognito user pools for sign-in and identity pools for AWS credentials, then verify a token's signature before you trust anything inside it. You'll then map where a permission really comes from among identity policies, resource policies, and the boundaries that cap them, and use that map to choose between IAM, Cognito, and Lambda authorizers for an API Gateway endpoint. Finally, you'll keep secrets out of code and logs, picking the store, the masking, and the rotation habits that survive an incident review.

Exercise 1: User pools, identity pools, and JWTs Exercise 2: Verify a token before you trust it Exercise 3: Decide access from the claims Exercise 4: Pick the right part of Cognito Exercise 5: Identity, resource, and boundary Exercise 6: Choose the policy home Exercise 7: Name the layer that refused Exercise 8: Isolate one tenant Exercise 9: Choosing an API Gateway authorizer Exercise 10: Match the caller to the door Exercise 11: Close the stale window Exercise 12: Stop the confused deputy Exercise 13: Keep secrets out of code and logs Exercise 14: Where the value lives Exercise 15: Sanitize without going blind Exercise 16: Survive the rotation

In this chapter, you'll match encryption mode to requirement: the four ways to encrypt an S3 object, and the one policy line that enforces transit. You'll then work out who really controls a KMS key when a key policy and an IAM policy both have a say, and read CloudTrail closely enough to know when its silence means nobody was logging, not that nothing happened. Finally, you'll run the whole course's checklist against one service you are about to ship, and see where the same identity, secrets, and encryption decisions carry into pipelines and AI agents calling AWS on your behalf.

Exercise 1: Encryption modes and enforcing transit Exercise 2: Encrypted, and still wrong Exercise 3: Match the mode to the requirement Exercise 4: Rank the private half by who holds a copy Exercise 5: Who controls the key Exercise 6: Which gate closed?Exercise 7: Read the denial, name the gate Exercise 8: Choose the key, then live with it Exercise 9: Reading AWS receipts Exercise 10: Under whose authority Exercise 11: What the trail will and will not hold Exercise 12: Right-size a role from its own activity Exercise 13: Shipping it safely Exercise 14: Ticked, and still open Exercise 15: The trigger that already fired Exercise 16: Ask the same three of a non-human caller Exercise 17: Congratulations