Courseiva
Design and implement build and release pipelineshardMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

Your company uses GitHub Actions to build and deploy a Python application. The workflow includes a job that runs on a self-hosted runner. You need to ensure that sensitive environment variables are not exposed in the workflow logs. What is the best approach?

⚠ Common exam trap

A common mistake is thinking you need to manually mark secrets as 'sensitive' or that repository secrets are not masked. In fact, all GitHub secrets are masked automatically.

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

Store secrets in GitHub repository secrets and reference them in the workflow.

GitHub repository secrets and environment secrets are both automatically masked in workflow logs when referenced via ${{ secrets.NAME }}. The best practice is to store sensitive variables in GitHub secrets and reference them in the workflow, rather than defining them directly in YAML or reading from a file. Option C correctly describes this approach.

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 a custom action to read secrets from a file.

    Why it's wrong here

    Reading secrets from a file via a custom action does not prevent the file’s contents from being captured if the file is printed, echoed, or accidentally included in a debug step, and GitHub’s log redaction for secrets applies only to values injected through the `secrets` context, not to file contents. This approach is tempting because it mirrors a common pattern for loading configuration in local development or containerised environments, where a `.env` file is read at runtime. It would be correct if the runner environment were fully isolated and the goal were to avoid hard-coding secrets in YAML, but it fails here because the requirement is to prevent exposure in logs, not merely to externalise secret values.

  • Use GitHub environment secrets and mark the secret as sensitive to ensure it is masked in logs.

    Why it's wrong here

    GitHub environment secrets provide scoped access to specific deployment environments and can enforce manual approval via required reviewers; when referenced through the `secrets` context, GitHub automatically masks the value in workflow logs, making this the secure, least-exposure option.

  • Store secrets in GitHub repository secrets and reference them in the workflow.

    Why this is correct

    Secrets are automatically masked, but this is the standard approach, not necessarily the 'best' for additional security.

  • Define the variables directly in the workflow YAML.

    Why it's wrong here

    Hardcoding secrets directly in workflow YAML exposes plaintext values to anyone with repository read access and prevents GitHub from applying its automatic log redaction, since redaction only works for secrets injected via the `secrets` context. This violates security best practices, leaves secrets in source control history, and makes rotation and scope control impossible.

About these practice questions

Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-400 practice question is part of Courseiva's free Microsoft 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 AZ-400 exam.