Identity and access management (IAM) determines which identity can authenticate and which actions that identity may perform on a named resource. In a multi-cloud environment, one corporate identity provider can establish workforce sign-in, while AWS, Azure, and Google Cloud each make their own authorization decisions within their own administrative boundaries. A successful sign-in does not itself authorize a resource API request. In AWS, workforce SSO is normally configured through IAM Identity Center, and IAM roles with AWS Security Token Service (STS) issue the resulting temporary credentials.
The useful boundary is between the identity provider, each cloud control plane, and each cloud’s data plane. A control plane manages cloud resources and their configuration. A data plane handles requests to the resources themselves; each cloud evaluates a principal, an action, a resource, and relevant conditions in its own IAM when such a request is made. These planes may share identity information, but they do not share one universal permission set.
We can now trace sign-in boundaries without implying resource access.
Multi-cloud IAM failures often begin with familiar words that have different scopes. An AWS account is an administrative boundary for AWS resources. An Azure tenant is the Microsoft Entra ID directory boundary, while Azure resource access is commonly authorized through Azure role-based access control (Azure RBAC) at a management group, subscription, resource group, or resource scope. In Google Cloud, an organization and a project provide separate scopes for Cloud IAM policy attachment and resource ownership.
This distinction matters because identity membership is not a resource permission. In Azure, Microsoft Entra ID can authenticate a user and expose group membership, while Azure RBAC must still grant an applicable role to authorize the requested Azure action. In AWS, AWS Identity and Access Management (IAM) policies and AWS Security Token Service (STS) credentials participate in AWS authorization. In Google Cloud, Cloud IAM evaluates its policy bindings for the relevant resource hierarchy. Similar-looking group names do not create equivalent access across these boundaries.
Operational evidence is similarly bounded. A corporate identity provider sign-in event can show that authentication occurred, but cannot alone establish that AWS, Azure, or Google Cloud allowed a later API request. A cloud audit record can show a control-plane or resource API attempt in that cloud, but it does not prove the corporate identity provider’s lifecycle data was correct. We need evidence from the plane that made the decision, with its identity, resource, action, and time window.
Decision rule Diagnose access one cloud and one request at a time. First identify the principal, target resource, API action, and authorization plane that evaluated it.
We will use one bounded workload rather than treating all identities alike. The orders-api service listens on port 8080. A workforce identity, orders-workforce-user, represents an operator who needs interactive access through the corporate identity provider. The app-operators group represents the intended operational role, while cloud-admins is deliberately separate because administrative access carries a different risk and approval boundary.
The automated identity is orders-ci, representing a continuous integration job that deploys or manages the workload. Its requests are not workforce browser sessions. It receives short-lived federated credentials for each cloud rather than holding long-lived cloud access keys. Our provider boundaries are AWS account dev, Azure tenant contoso, and Google Cloud project orders-prod; each later authorization question must name one of these targets explicitly.
We can now inspect how workforce and CI identity paths reach each cloud.