When an AWS service receives a request, the request is first authenticated and then checks if the requester is authorized to perform that action. A few services, like Amazon S3, also allow requests from anonymous users.
If the request is made by an IAM user, or if the request is signed using temporary credentials that are granted by AWS STS, AWS uses IAM policies to determine whether the user's request is authorized.
Requests that are made by the AWS account root user are allowed for resources in that account.
Service control policies (SCPs) can be attached to accounts to put additional restrictions and is mostly done for orgaization accounts. If an SCP attached to an account denies access to a service, administrator or even root user is denied access.
AWS authorizes a request based on information from several sources:
Principal (the requester) and associated aggregate permissions is determined based on the secret access key. E.g. the root user, an IAM user, a federated user (via STS), or an assumed role.
Environment data, such as the IP address, user agent, SSL enabled, the time of day, etc.
Resource data that is part of the resource being requested, such as a DynamoDB table name, a tag on an Amazon EC2 instance, etc.
When a request is made, the AWS service decides whether a given request should be allowed or denied as follows:
By default, all requests are denied.
An explicit allow (Effect=allow) overrides this default.
An explicit deny (Effect=deny) overrides any allows.
Important Notes (Exam Tips)
The order in which the policies are evaluated has no effect. All policies are evaluated, and the result is always that the request is either allowed or denied.
If the code encounters an error at any point during the evaluation, then it will generate an exception and close.
By default, a request is denied, but this can be overridden by an allow. In contrast, if a policy explicitly denies a request, that deny can't be overridden.
Also, see example scenarios in the reference link.