When no authenticator is specified, the API execution is implicitly allowed if no resource policy is defined and explicitly blocked if a resource policy is defined but not explicitly allow.
When IAM authenticator is specified, authentication is performed first and if there is a resource policy defined the final result based on the combination of the both along with the consideration if the identity request the API execution comes from the same AWS account of the API, in which case only if both explicitly allow will result to an invocation (Note, it is not shown in the Lambda authenticator flow but the same cross account validation logic applies there as well).
When Cognito authenticator is specified, authentication is performed first and if there is not an explicit Allow then the request is denied before checking on any resource policy, which is different from the IAM authenticator flow. Another difference is the final decision requires resource policy if there is one to explicitly Allow for the final decision Allow which is different from the Table A defined for Lambda and IAM authenticator.
Policy evaluation outcome tables
Table A lists the resulting behavior when access to an API Gateway API is controlled by an IAM policy (or a Lambda or Amazon Cognito user pools authorizer) and an API Gateway resource policy, both of which are in the same AWS account.
Table B lists the resulting behavior when access to an API Gateway API is controlled by an IAM policy (or a Lambda or Amazon Cognito user pools authorizer) and an API Gateway resource policy, which are in different AWS accounts. If either is silent (neither allow nor deny), cross-account access is denied. This is because cross-account access requires that both the resource policy and the IAM policy (or a Lambda or Amazon Cognito user pools authorizer) explicitly grant access.
