A manufacturer runs Kubernetes on-premises and in another cloud that must call S3 and SQS without storing AWS keys, with short-lived credentials tied to existing enterprise identities. Which workload identity design is correct?
Select an answer to reveal the explanation.
Short Explanation
You don’t need to bury AWS keys in containers or servers. With IAM Roles Anywhere, outside workloads prove their identity with certificates and receive short-lived credentials for AWS services.
Full Explanation
IAM Roles Anywhere is the right design because it lets workloads outside AWS—including on-premises Kubernetes and servers in another cloud—use X.509 client certificates to authenticate against a configured trust anchor, such as the enterprise PKI, and obtain short-lived STS role credentials for S3 and SQS without storing AWS keys. The role trust policy controls which external identities can assume the role. EKS IRSA with OIDC federation depends on an Amazon EKS cluster’s registered OIDC issuer and is therefore not the fit for Kubernetes running on-premises or in another cloud. EC2 instance profiles deliver role credentials through the EC2 instance metadata mechanism, so they apply to EC2 instances rather than external servers and do not provide the required enterprise-identity-based authentication. IAM Identity Center federation connects an enterprise IdP to human workforce access, such as console access; it is not the workload credential mechanism for server processes calling service APIs. Exam caveat: match the identity mechanism to where the workload runs and who or what is authenticating—these external workloads need certificate-based trust, not an EKS issuer, EC2 metadata, or human federation. Practical check: validate the trust anchor, certificate validity and subject mapping, role trust policy, and CloudTrail evidence of successful role assumption with expiring STS credentials before granting the role S3 and SQS permissions.