An IAM user is a long-lived identity with static credentials — best kept to a minimum. An IAM role is an identity that is assumed temporarily, issuing short-lived credentials to whoever or whatever is allowed to assume it. Roles are the preferred pattern for humans (via SSO) and workloads (via instance or workload identity), because there are no long-lived keys to leak.

A permission boundary is a policy that sets the maximum permissions an IAM entity can have, regardless of what its identity policies grant. It lets you delegate role creation to teams without letting them escalate beyond a ceiling you control. The AWS foundations lab uses boundaries alongside identity policies and evidence from Access Analyzer.

AWS Organizations groups many accounts under central governance, and service control policies (SCPs) set guardrails that even account admins cannot exceed. Control Tower layers a curated landing zone, blueprints and controls on top. Together they give multi-account least privilege and consistent baselines. Lab 02 builds guardrails and landing-zone controls.

GCP IAM binds principals to roles on a resource hierarchy (organization, folder, project, resource), with policies inherited down the tree, plus IAM Conditions for context. AWS attaches JSON policies to users, groups and roles and evaluates them per request. The concepts rhyme, but the inheritance model and role granularity differ — the GCP lab highlights the mapping.

Kubernetes RBAC controls what identities can do against the API server using four objects: Role and ClusterRole define permissions, while RoleBinding and ClusterRoleBinding grant them to subjects such as users, groups and ServiceAccounts. The RBAC lab builds least-privilege access for workloads and humans and audits who can do what.

Workload identity federation lets a workload in one trust domain access another cloud without long-lived keys, by exchanging a signed OIDC token it already holds (for example a Kubernetes or GitHub token) for short-lived cloud credentials. It removes stored secrets from pipelines and clusters. The multi-cloud lab federates workload identity across AWS, GCP and Azure over OIDC.

You anchor on a single source of human identity (an IdP for SSO into each cloud's access system), use roles and short-lived credentials everywhere instead of static keys, and federate workloads over OIDC rather than copying secrets between platforms. Centralized policy and consistent naming keep least privilege auditable. The multi-cloud federation lab ties these together.