200-901 Application Deployment and Security Practice Question
A developer is configuring a GitHub Actions workflow that must authenticate to AWS to push an image to Amazon ECR. The security team prohibits long-lived AWS access keys in repository secrets. Which authentication method should the workflow use?
⚠ Common exam trap
The trap here is thinking that an encrypted repository secret makes a long-lived key acceptable, when the policy forbids the credential type regardless of storage encryption.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure an OpenID Connect (OIDC) identity provider in AWS IAM and assume a role using the workflow's OIDC token.
OIDC federation lets GitHub Actions exchange a short-lived identity token for temporary AWS credentials through a trusted IAM role. This removes long-lived access keys entirely, which is the only option consistent with the security team's prohibition. Storing static keys in secrets, passing them to actions, or embedding them in images all retain long-lived credentials and expand the attack surface.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Embed the AWS credentials in the Docker image at build time using build arguments and read them at runtime.
Why it's wrong here
Build arguments are visible in image history and can be extracted from the image, so embedding credentials exposes them to anyone who can pull the image. This also uses long-lived keys, violating the policy. It is a severe anti-pattern that combines credential leakage with the prohibited credential type.
- ✓
Configure an OpenID Connect (OIDC) identity provider in AWS IAM and assume a role using the workflow's OIDC token.
Why this is correct
GitHub Actions can issue a short-lived OIDC token that AWS IAM trusts via a configured identity provider. The workflow assumes an IAM role and receives temporary credentials, eliminating long-lived keys. This satisfies the prohibition, supports fine-grained trust conditions such as repository and branch, and automatically expires credentials, reducing the risk of credential leakage.
- ✗
Use the `aws-actions/configure-aws-credentials` action with `aws-access-key-id` and `aws-secret-access-key` inputs populated from repository secrets.
Why it's wrong here
This action can assume a role via OIDC, but populating static access key inputs means long-lived credentials are still used. That directly contradicts the security team's requirement. Even though the action is the correct tool, supplying static keys here is the wrong configuration and would fail a security review.
- ✗
Store the AWS secret access key in an encrypted repository secret and reference it in the workflow.
Why it's wrong here
Encrypted repository secrets still represent long-lived credentials that must be rotated and can be exfiltrated if the workflow is compromised. The security policy explicitly prohibits long-lived keys, so this approach violates the requirement even though the secret is encrypted at rest. It also requires manual rotation and broad IAM permissions, increasing blast radius.
Go deeper
Related to this question
About these practice questions
One of 975 original 200-901 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Cisco exam blueprint
This 200-901 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-901 exam.