Workload identity outside AWS (IAM Roles Anywhere, OIDC federation): SCS-C03 study notes and practice questions
What to know about Workload identity outside AWS (IAM Roles Anywhere, OIDC federation) for the SCS-C03 exam, from the Identity and Access Management domain (20% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe a workload that needs AWS access and a rule such as “no stored access keys” or “the pipeline must not hold a secret.” The answer depends on what the workload can prove about itself: a certificate from your certificate authority, a token from an identity provider, or nothing beyond the AWS compute it runs on.
The facts that decide answers
IAM Roles Anywhere gives a workload temporary credentials when it presents an X.509 certificate issued by a trusted certificate authority. You register a trust anchor (AWS Private CA, or an external CA certificate), a profile that sets the roles and session limits, and a role whose trust policy names the Roles Anywhere service principal with conditions on the certificate.
The workload obtains credentials through the credential helper (aws_signing_helper) or an SDK credential configuration, and the credentials are short-lived.
IAM OIDC identity providers let AWS trust a token issuer. GitHub Actions, for example, calls AssumeRoleWithWebIdentity. The role’s trust policy must check the token’s aud and sub claims, which pin the access to a repository, branch or environment.
EKS Pod Identity links an IAM role to a Kubernetes service account through the Pod Identity agent, and it needs no OIDC provider to manage per cluster. IAM roles for service accounts (IRSA) use an OIDC provider for the same job.
EC2 instance profiles cover workloads that already run on AWS compute. They need no certificate and no keys.
A long-term access key on a server or in a pipeline is the failure these questions are built around. Rotate it and remove it.
How to choose
Scenario wording
Pick
On-premises server with a certificate from the corporate CA
IAM Roles Anywhere
GitHub Actions deploys to AWS without stored keys
IAM OIDC provider for GitHub, with a trust policy on sub
Pods in an EKS cluster need their own role
EKS Pod Identity, or IRSA where an OIDC provider already exists
Code on an EC2 instance calls AWS APIs
Instance profile role
Workload with its own OIDC token from another identity provider
IAM OIDC identity provider with aud and sub conditions
Common traps
Creating IAM users and access keys for a server, container or pipeline.
An OIDC trust policy with no sub condition. It lets any workload from that issuer assume the role.
Using Roles Anywhere for code that already runs on AWS. An instance profile or task role is simpler.
Treating Pod Identity and IRSA as different security models. Both give pods temporary credentials. They differ in setup, not in the outcome.
Trusting a certificate authority more broadly than the workload needs. Restrict the trust anchor and the profile to the roles the workload needs.
A regional water utility runs control software on 30 Linux servers at pumping stations. The servers are not in AWS. They upload sensor summaries to an Amazon S3 bucket and write alerts to a DynamoDB table, and they can reach AWS public endpoints over HTTPS.
The utility's security standard bans long-term access keys on any server. Each server must have its own identity, so that one compromised server can be revoked without affecting the others. The utility already runs a private certificate authority in AWS Private CA.
Which solution meets these requirements with the LEAST operational overhead?
Choose one answer.
AA. Create an IAM user for each server, with a policy that allows only its bucket and table. Store the access keys in a vault on each server, and rotate them every 90 days with a script.
BB. Create a Roles Anywhere trust anchor that trusts the utility's private CA. Issue each server a certificate from that CA, map it to a least-privilege role, and run the Roles Anywhere credential helper on each server.
CC. Enable OpenID Connect federation between each server and IAM, and have each server get a web identity token from its local operating system. Call AssumeRoleWithWebIdentity to receive temporary credentials.
DD. Connect the pumping stations to a VPC with a site-to-site VPN, and attach an instance profile to each server. The servers then receive temporary credentials from the instance metadata service.
Show the answer and explanation
Answer: B
A. Wrong: Each server gets its own identity, but the access keys are long-term credentials, which the standard bans. A rotation script adds upkeep without removing the stored keys from the servers.
B. Right: Correct. Each server authenticates with its own certificate, and Roles Anywhere exchanges it for temporary credentials, so no long-term keys are stored. Revoking one certificate removes only that server's access. Learn more: What is IAM Roles Anywhere? (opens in a new tab)
C. Wrong: Web identity federation needs a token issuer that IAM trusts, and plain servers do not run one. Building and operating that issuer adds an identity system the utility must maintain, which conflicts with the low-overhead requirement.
D. Wrong: Instance profiles are available only to EC2 instances, not to servers outside AWS, even when a VPN connects them. The instance metadata service is also not reachable from the stations, so this approach cannot supply credentials.
Explanation
IAM Roles Anywhere lets workloads outside AWS get temporary credentials with an X.509 certificate that the organization's own CA issues. Per-server certificates give each server its own identity and a simple revocation path. Long-term keys, a custom token issuer, and instance profiles each miss a stated requirement.
Want more on Workload identity outside AWS (IAM Roles Anywhere, OIDC federation)? The 5 full-length practice sets have 6 more Workload identity outside AWS (IAM Roles Anywhere, OIDC federation) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Workload identity outside AWS (IAM Roles Anywhere, OIDC federation)