200-901 Application Deployment and Security Practice Question
A team uses GitHub Actions for CI/CD. Their workflow includes a job that builds a Docker image and pushes it to a private registry. The job needs to authenticate to the registry using secrets stored in GitHub. Which approach is most secure for passing credentials?
⚠ Common exam trap
The trap is assuming any non-YAML location is 'secure' — candidates pick the .env file thinking it is external to the repo, but on ephemeral GitHub-hosted runners it is neither encrypted nor portable, so only GitHub Secrets provides proper masking and scoping.
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
✓
Use GitHub Secrets and reference them with ${{ secrets.REGISTRY_PASSWORD }}.
GitHub Secrets store encrypted values at the repository, environment, or organization level, and they are injected into the workflow at runtime as masked values referenced via the ${{ secrets.NAME }} context. They are never written to logs (GitHub automatically redacts them), are not exposed to forked PRs by default, and can be scoped to specific environments with required reviewers. This makes them the correct mechanism for passing registry credentials securely to a CI/CD job.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use GitHub Secrets and reference them with ${{ secrets.REGISTRY_PASSWORD }}.
Why this is correct
GitHub Secrets store credentials encrypted and inject them at runtime via the secrets context, so the registry password never appears in workflow files or logs. Referencing ${{ secrets.REGISTRY_PASSWORD }} keeps the value masked and out of version control.
- ✗
Embed the password directly in the workflow YAML file.
Why it's wrong here
Embedding the password in the YAML writes it into the repository and workflow logs, defeating the purpose of storing it as a GitHub secret. Inline values are acceptable for non-sensitive parameters such as image tags, which is what makes this look reasonable.
- ✗
Store the password in a plain text file in the repository and read it during the build.
Why it's wrong here
Plain text in the repository exposes the password to anyone with read access and to the full commit history, so it cannot satisfy the secrets requirement. Committing configuration files is legitimate for non-sensitive build settings, which is why it appears plausible here.
- ✗
Use environment variables set in the runner's local .env file.
Why it's wrong here
A runner-local .env file is not populated from GitHub secrets, so the workflow cannot retrieve the stored credentials and the value is absent on hosted runners. Local .env files suit developer machines for non-secret configuration, not CI jobs needing repository secrets.
Go deeper
Related to this question
About these practice questions
This 200-901 question is part of Courseiva's 975-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.