A late reply, but thats not how AWS IAM (or most advanced authz systems) work. AWS IAM is a “capability” system with dynamic policies; its nothing so simple as a “role” based authorization contrary to some product naming. To wit, every authz evaluation is a dynamic evaluation of policy and context. Each check uses one or more policies with one or more policy statements that are combined with some boolean logic and predicate rules. The policies may be associated (sourced) with the particular request based on calling principal, principal attributes, the target resource, a related resource, or even other metadata like AWS Org membership. Thats combined with the point in time context from the request (ex action name, parameters), request metadata (eg time), principal (id, tags, etc), resource (arn, attributes, tags), and some more “system” specific context variables. You (and the authorizing service) need ALL of that information to perform an authz evaluation.
This is complicated by dynamic data, like time or source address or caller principal tag values, so even identical requests may have different results. There are also complications like DENY statements and “unless” predicates that entirely defeat a simple “resource x requires y” approach.
Evem if you solve all of those challenges via magic you end up back at information disclosure where your adversary is now capable of rapidly enumerating and testing all your authz policies!
This is complicated by dynamic data, like time or source address or caller principal tag values, so even identical requests may have different results. There are also complications like DENY statements and “unless” predicates that entirely defeat a simple “resource x requires y” approach.
Evem if you solve all of those challenges via magic you end up back at information disclosure where your adversary is now capable of rapidly enumerating and testing all your authz policies!