In AWS IAM, what is the difference between an implicit deny and an explicit Deny, and what does each mean for how you write and troubleshoot policies?

## The starting point: nothing is permitted AWS authorization begins from a closed default. When a request arrives — `s3:GetObject`, `ec2:TerminateInstances`, anything — the evaluator assumes the answer is no and then looks for a reason to say yes. A brand-new IAM user with no policies attached can call nothing at all, not even read its own name. This is called the **default deny** or **implicit deny**. ## Implicit deny: the absence of an Allow An implicit deny is not something you write. It is the result of the search for a matching `Allow` coming up empty. Any of these produce it: - no policy is attached to the principal at all; - a policy is attached but its `Action` does not cover the call (an `s3:GetObject` allow does not cover `s3:ListBucket`, which is a separate action); - the `Resource` does not match the ARN in the request (`arn:aws:s3:::my-bucket` matches the bucket but not the objects inside it, which are `arn:aws:s3:::my-bucket/*`); - a `Condition` on the Allow does not hold at request time, so the statement does not match. The defining property is that an implicit deny is **overridable**: attach or widen a policy that allows the action, and the request now succeeds. Nothing has to be removed first. ## Explicit Deny: a statement that ends the argument An explicit Deny is a statement you author with `"Effect": "Deny"`. If any policy that applies to the request contains a matching Deny — an identity-based policy, a resource-based policy such as an S3 bucket policy, a permissions boundary, a session policy, or a service control policy in AWS Organizations — the final decision is deny. There is no Allow strong enough to beat it, and there is no ordering trick that helps: policies are not evaluated top to bottom like a firewall rule list, so a Deny later in the same document, or in a completely different document, still wins. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:DeleteBucket", "Resource": "*" } ] } ``` This principal can do everything in S3 except delete a bucket, and attaching `AdministratorAccess` on top changes nothing. ## Why the asymmetry exists The rule "Allows are additive, Deny is final" is what makes delegated administration safe. If Denies could be outvoted, then anyone able to attach one more policy could unwind a security control. Because they cannot, a central team can write a rule once — deny anything outside `eu-central-1`, deny disabling CloudTrail, deny access to the audit bucket — and know that no account admin, no future policy edit, and no automation can quietly re-enable it. The cost of that power is that Denies are blunt. A Deny with a `Condition` you got slightly wrong takes down callers that were never the target, and because it wins everywhere, it is the hardest kind of breakage to diagnose from inside the affected account. ## Troubleshooting: which one are you looking at? When you get `AccessDenied`, the first useful question is which of the two you hit, because the remedies are opposite. Modern AWS error messages usually tell you: a message ending in *"because no identity-based policy allows the ... action"* is an implicit deny — go add or widen a policy. A message naming *"an explicit deny in a service control policy"*, or in an identity-based or resource-based policy, means adding permissions is wasted effort; you must find and change the denying statement, which often lives in another account or another team's repository. ## Writing guidance Prefer scoping the Allow over patching it with a Deny. `Allow s3:GetObject on arn:aws:s3:::reports/*` is easier to read and reason about than `Allow s3:*` plus three Deny statements. Reserve explicit Deny for invariants that must survive every future edit: guardrails on regions and root-like actions, protection of security-relevant resources, and conditions such as requiring MFA or a specific VPC endpoint. And remember that a Deny in a resource-based policy protects the resource against principals in other accounts too — it is not just an identity-side tool.