Create an IAM OIDC identity provider, a role trusting the IdP audience, and use AssumeRoleWithWebIdentity

DOP-C02 By islever Editorial Last updated

Implement techniques for identity and access management at scale.

Short answer

BDE Create an IAM OIDC identity provider, trust the role on auth.company.com:aud, and use AssumeRoleWithWebIdentity for the S3 calls.

Question

A company is refactoring applications to use AWS. The company identifies an internal web application that needs to make Amazon S3 API calls in a specific AWS account. The company wants to use its existing identity provider (IdP) auth.company.com for authentication. The IdP supports only OpenID Connect (OIDC). A DevOps engineer needs to secure the web application's access to the AWS account. Which combination of steps will meet these requirements? (Choose three.)
  1. Configure AWS IAM Identity Center (AWS Single Sign-On). Configure an IdP. Upload the IdP metadata from the existing IdP.
  2. Create an IAM IdP by using the provider URL, audience, and signature from the existing IP. Correct Answer
  3. Create an IAM role that has a policy that allows the necessary S3 actions. Configure the role's trust policy to allow the OIDC IP to assume the role if the sts.amazon.com:aud context key is appid_from_idp.
  4. Create an IAM role that has a policy that allows the necessary S3 actions. Configure the role's trust policy to allow the OIDC IP to assume the role if the auth.company.com:aud context key is appid_from_idp. Correct Answer
  5. Configure the web application to use the AssumeRoleWithWebIdentity API operation to retrieve temporary credentials. Use the temporary credentials to make the S3 API calls. Correct Answer

Key Takeaways

Because the IdP supports only OIDC, the direct path is an IAM OIDC identity provider rather than SAML and without Identity Center (A), which would add an SSO layer the app does not need. AWS requires the trust policy condition to use the IdP's fully qualified URL with the aud key (auth.company.com:aud), so D is correct and C's sts.amazon.com:aud is wrong. The app then exchanges the OIDC token for temporary credentials via AssumeRoleWithWebIdentity (E).

An internal web app must call S3 in a specific account using the existing OIDC-only identity provider auth.company.com. Create an IAM OIDC identity provider from the provider URL, audience, and signature; create an IAM role whose permissions policy allows the required S3 actions and whose trust policy allows the OIDC provider to assume it when the auth.company.com:aud context key equals the app id; then have the web app call AssumeRoleWithWebIdentity to obtain temporary credentials for the S3 calls.

Common mistake: Choosing sts.amazon.com:aud as the trust-policy condition key (C)—for a custom OIDC provider AWS requires the IdP's own fully qualified domain with the aud key, such as server.example.com:aud. Setting up IAM Identity Center (A)—it is an SSO-based alternative that adds unnecessary complexity when the app already federates directly via OIDC, and it is not part of the minimal path.

Expert Analysis

Why the Answer Is Correct

Since the identity provider supports only OpenID Connect, the correct mechanism is an IAM OIDC identity provider created from the provider URL, audience, and signature (B). A matching IAM role is created with a permissions policy for the necessary S3 actions and a trust policy whose StringEquals condition uses the IdP's fully qualified URL with the aud key, auth.company.com:aud, to constrain assumption to this app (D). The web application then calls AssumeRoleWithWebIdentity to exchange its OIDC token for short-lived credentials and performs the S3 calls with them (E).

Why the Other Options Are Wrong

A configures IAM Identity Center, an SSO-oriented service that adds a layer the application does not need when it can federate directly with OIDC. C uses sts.amazon.com:aud, which is not the correct condition key for a custom OIDC provider; AWS documents using the IdP's fully qualified URL with the aud key, so C would fail to constrain assumption correctly. B, D, and E are the correct combination.

Community Comment Notes

Community voted B,D,E (73), citing the AWS page for creating a role for OIDC federation. One commenter chose B,C,E, but the AWS documentation specifies the IdP's fully qualified domain with the aud key rather than sts.amazon.com:aud, confirming D over C. B, D, E confirmed.

Official Reference

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

When an exam scenario says the IdP supports only OIDC and an app needs AWS credentials, skip IAM Identity Center options that add SSO metadata uploads; focus on direct IAM OIDC federation. The trust-policy trap is the condition key: use the IdP's fully qualified URL plus :aud (auth.company.com:aud), not sts.amazon.com:aud. Pair that with AssumeRoleWithWebIdentity to exchange the OIDC token for temporary credentials.

Frequently Asked Questions

Why is AssumeRoleWithWebIdentity needed for this OIDC web application?

The app must exchange its OIDC token for temporary AWS credentials to call Amazon S3, which is exactly what AssumeRoleWithWebIdentity does. This avoids long-term access keys and matches option E.

Which trust policy condition key should the IAM role use for auth.company.com?

Use auth.company.com:aud with StringEquals, matching option D. Option C's sts.amazon.com:aud is not the documented condition key for a custom OIDC provider.

What three steps combine to secure S3 access with an OIDC-only IdP?

Create an IAM OIDC provider using the provider URL, audience, and signature (B); create an IAM role with S3 permissions and the OIDC trust policy (D); then call AssumeRoleWithWebIdentity (E).

More DOP-C02 FAQ →

Community Votes

BDE
100%

100% of anonymous learners picked answer BDE. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 8 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 8

  1. vortegon 👍 5
    https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html
  2. thanhnv142 👍 3
    BDE: A: we need to create an IDP. We dont need a AWS Single Sign-On B: correct C: we need to authen. sts.amazon.com:aud does not for authen D: auth.company.com:aud is for authen E: This used for authen AssumeRoleWithWebIdentity F: This is not used for authen
  3. Gomer 👍 2
    "Use OpenID Connect (OIDC) federated identity providers instead of creating" IAM users." "With an" IdP "you can manage" "user identities outside of AWS and give these external user identities permissions to access AWS resources in your account." B: (YES) "IAM OIDC identity Providers" "This is useful when creating a mobile app or web application that requires access to AWS resources, but you don't want to create custom sign-in code or manage your own user identities." D: (YES) "For OIDC providers, use the fully qualified URL of the OIDC IdP with the aud context key" e.g.: "Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}" E: (YES) "AssumeRoleWithWebIdentity" "Federation through a web-based" IDP "returns a set of temporary security credentials for federated users" "authenticated" "with a public identity provider." "This operation is useful for" "client-based web applications that require access to AWS."
  4. dkp 👍 1
    DE is correct not sure between A & B A. Configure AWS IAM Identity Center (AWS Single Sign-On). Configure an IdP. Upload the IdP metadata from the existing IdP. Pros: Integrates with AWS SSO and allows for IdP metadata upload. Cons: AWS SSO is generally used for managing multiple AWS accounts and SSO for multiple AWS services, might be overkill for a single account and application. B. Create an IAM IdP by using the provider URL, audience, and signature from the existing IP. Pros: Creates a custom IAM IdP using the existing IdP's details. Cons: Manual configuration of IAM IdP might be error-prone and not the best practice for OIDC integration.
  5. Ramdi1 👍 1
    C & D: Creating an IAM role with specific S3 permissions and configuring the trust policy based on the appropriate audience (sts.amazon.com:aud or auth.company.com:aud) allows secure role assumption by the OIDC IdP on behalf of authenticated users. E: Using AssumeRoleWithWebIdentity fetches temporary credentials with restricted privileges, enhancing security compared to long-lived credentials.
Show 3 more comments
  1. sn61613 👍 1
    BCE https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html
  2. Chelseajcole 👍 3
    BDE is my answer
  3. seetpt 👍 1
    BDE for me

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Optimizing Amazon Timestream Query Performance

S-grade

Deploy the CloudWatch agent as a StatefulSet with IRSA and CloudWatchAgentServerPolicy, and configure the OIDC provider

S-grade

Disable cross-zone load balancing on the target group and start an Application Recovery Controller zonal shift

S-grade

Stream all CloudWatch metrics to Firehose, transform with Lambda, and deliver to S3

S-grade

Practice All DOP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full DOP-C02 Practice Test →

← Back to DOP-C02 Study Guide