AZ-400 Develop a security and compliance plan Practice Question
Which THREE measures should you implement to protect secrets used in GitHub Actions workflows? (Choose three.)
⚠ Common exam trap
A common mix-up: candidates confuse 'secret scanning' with 'secret management' and overlook that OIDC is a valid measure because it removes the need to store secrets altogether, while hardcoding secrets (Option A) seems convenient but is a critical security anti-pattern.
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
✓
Enable secret scanning to detect secrets in code pushes.
Option B is correct because enabling secret scanning (including push protection) lets GitHub detect and block credentials committed to the repository, catching accidental leaks before they are exploited. Option D is correct because configuring OpenID Connect (OIDC) with a federated identity credential allows GitHub Actions to authenticate to Azure via short-lived tokens, eliminating the need to store long-lived cloud credentials as secrets. Option E is correct because storing values as GitHub repository secrets or organization secrets keeps them encrypted at rest, masks them in logs, and injects them only at runtime rather than exposing them in workflow files. Option A is wrong because hardcoding secrets in workflow YAML exposes them in plaintext to anyone with repository read access and in logs. Option C is wrong because reusing one secret across all environments removes isolation, so a compromise in a low-trust environment grants access to production.
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 hardcoded secrets in workflow files for simplicity.
Why it's wrong here
Hardcoding secrets in workflow files exposes them to anyone with repository read access, persists them in Git history, and fails to mask them in logs, leading to credential leakage and potential unauthorized access to Azure resources.
- ✓
Enable secret scanning to detect secrets in code pushes.
Why this is correct
Enabling secret scanning on GitHub automatically detects known secret formats (e.g., Azure keys, GitHub tokens) during code pushes, alerts repository administrators and the secret owner, and can block the push or trigger remediation workflows, preventing secrets from being merged.
- ✗
Use the same secret across all environments to reduce management overhead.
Why it's wrong here
Reusing one secret across all environments removes the isolation that Azure identity and access management is designed to provide, so a developer who compromises the dev environment gains the exact same access to production data and management plane operations. This violates least privilege and defense in depth: a single exposed secret forces an immediate, organization-wide rotation that impacts every dependent workload and CI/CD pipeline, turning a localized incident into a global outage and forensic nightmare. Instead, use separate, short-lived credentials or Azure managed identities per environment, with distinct access policies, so a dev leak never escalates to a production breach.
- ✓
Use OpenID Connect (OIDC) to authenticate to Azure without storing credentials.
Why this is correct
Using OpenID Connect (OIDC) for GitHub Actions to Azure eliminates the need to store static credentials in GitHub by exchanging a short-lived token from the GitHub Actions workflow with an Microsoft Entra ID identity. Configure the Microsoft Entra ID app or user-assigned managed identity with federated credentials that trust the specific GitHub repository, branch, or environment; at runtime, the workflow uses the OIDC token to request an Microsoft Entra ID access token. This leverages conditional access and least-privilege federation, ensures tokens expire in minutes rather than months, and removes the rotation burden entirely — the secret that never gets stored is the one that cannot leak.
- ✓
Store secrets as GitHub repository secrets or organization secrets.
Why this is correct
Storing secrets as GitHub repository or organization secrets provides encryption at rest with AES-256, automatic log masking, and strict access controls that prevent exposure in workflow files and Git history. These secrets are injected into the workflow's environment only during the job runtime via the secrets context, and they are not available to pull requests from forks, mitigating malicious PR attacks. Organization-level secrets allow centralized management across multiple repositories while still honoring environment-based scoping like GitHub Environments, so you can enforce branch protection rules and require manual approval before sensitive values are released.
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-400 question from scratch — 696 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 →
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.