Develop a security and compliance plan →hardMultiple ChoiceObjective-mapped

AZ-400 Develop a security and compliance plan Practice Question

Your organization uses GitHub Actions and has a repository containing sensitive infrastructure code. You need to ensure that only approved actions are used in workflows. Which two settings should you configure? (Select two.)

⚠ Common exam trap

Many exam-takers confuse environment protection rules (which manage deployment approvals) with action source restrictions, or mistakenly think disabling actions entirely is a valid security measure when the repository still needs to run workflows.

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

✓

Allow actions created by GitHub.

This is a select-two question. The correct answers are A and C. Option A is correct because enabling 'Allow actions created by GitHub' restricts workflows to only use first-party actions published by GitHub, establishing a baseline security posture. Option C is correct because further limiting actions to only those from specific approved repositories provides granular control over third-party actions that have been vetted by the organization. Together, these settings ensure that only approved actions can be used in workflows, meeting the compliance requirement.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Allow actions created by GitHub.
Why this is correct
This is correct because it restricts the set of actions available in your workflows to only those published by GitHub itself (e.g., `actions/checkout`, `actions/setup-dotnet`). This significantly reduces supply-chain risk by excluding third-party actions, while still allowing all workflows to run with trusted, officially maintained actions.
✗
Disable actions for the repository.
Why it's wrong here
This option is incorrect because disabling actions for the repository entirely stops all GitHub Actions workflows from executing, which would break any existing CI/CD pipelines. The goal is to control which actions are used, not to eliminate automation altogether, so this is far too restrictive and not a valid mitigating control.
✓
Allow actions from only specific approved repositories.
Why this is correct
This is also correct because it allows you to whitelist specific action repositories (e.g., `actions/checkout` or a trusted third-party repository like `octocat/hello-world`) while blocking all others. This provides granular, policy-driven control over which action sources are permitted, making it a valid alternative to the stricter 'allow actions created by GitHub' option.
✗
Use environment protection rules.
Why it's wrong here
This option is incorrect because environment protection rules (e.g., required reviewers, wait timers, or deployment branches) apply to deployment jobs and environments, not to the selection or execution of actions within a workflow. They do not restrict which third-party or custom actions can be referenced, so they cannot mitigate the risk of untrusted actions running.
✗
Store actions in encrypted secrets.
Why it's wrong here
This option is incorrect because secrets are encrypted key-value stores intended for sensitive data like API tokens, passwords, and certificates; they are not a mechanism for storing or executing action definitions. Even if you embedded action code in a secret, GitHub Actions does not interpret secret contents as executable actions—actions must be referenced from repositories or containers, so this does not control which actions run.

Go deeper

AZ-400 Develop a security and compliance plan Practice Question

Why each option matters

Option-by-option breakdown

Related to this question