

0 / 2 embers
0 / 3000 xp
click for more info
Complete a lesson to start your streak
click for more info
Difficulty: 3
click for more info
Not enough gems
Cost: 6 gems
1: Identity and Access Management (IAM)
incomplete
2: IAM Users
incomplete
3: Inline Policies
incomplete
4: IAM Groups
incomplete
5: IAM Roles
incomplete
6: Deny Policies
incomplete
7: SSM Parameters
incomplete
8: SSM Parameters Are Strings
incomplete
9: Accessing SSM Parameters from EC2
incomplete
10: Use SSM from EC2
incomplete
11: Cleanup
incomplete
Back
ctrl+,
Next
ctrl+.
This lesson's interactive features are locked, please to keep using them
An explicit Deny policy always wins; even if other policies Allow the same action. This is your shield when you need to set absolute boundaries.
Follow the principle of least privilege: grant people and resources only the permissions they actually need, nothing more. So don't "allow all actions by default" and then add Deny rules for dangerous actions. Prefer to add permissions as they're needed.
That said, there are situations where Deny policies are helpful:
Something is misbehaving on server 3; can you quickly disable its AWS access?
A deny-all policy is like putting someone in time-out. They can't do anything, no matter what other permissions they might have. Useful for quarantine, break-glass prevention, or stopping a rogue service from causing more damage.
Hackers love getting access to random EC2 instances and using the permissions to the AWS account they're in. Sometimes for data exfiltration, sometimes to mine crypto, and sometimes just to cause chaos for your team.
Security drill: assume the EC2 instance is compromised. Lock it down immediately.
Create a deny-all policy patientping-deny-all and attach it to the role patientping-ec2-readonly-role.
Cost check: Creating IAM policies is free; costs arise from service usage.
aws ec2 describe-instances --no-cli-pager
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyEverything",
"Effect": "Deny",
"Action": "*",
"Resource": "*"
}
]
}
aws ec2 describe-instances --no-cli-pager
Run and submit the CLI tests.
At this point, the role has no effective AWS access (Deny always wins)!
You can accomplish the same thing via CLI. Here's the command structure:
# Create the deny-all policy
aws iam create-policy --policy-name POLICY-NAME --policy-document file://DENY-POLICY.json
# Attach the policy to a role
aws iam attach-role-policy --role-name ROLE-NAME --policy-arn POLICY-ARN