AZ-400 Practice Question: Design and implement build and release pipelines
Your organization uses GitHub Actions for CI/CD. You have a workflow that deploys to Azure App Service. The deployment uses a publish profile secret stored as a GitHub secret. You want to improve security by using OpenID Connect (OIDC) to authenticate to Azure without storing secrets. What should you do?
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 the GitHub workflow to use the 'azure/login' action with OIDC, and set up a federated identity credential in Microsoft Entra ID for the GitHub environment.
Configuring OIDC with Microsoft Entra ID (formerly Azure AD) using a federated identity credential for the GitHub environment allows token-based authentication without storing secrets. Option A is incorrect because Azure Managed Identity cannot be used directly from a GitHub runner; Managed Identity is designed for Azure-hosted resources, not external runners. Option C is incorrect because replacing the publish profile secret with a service principal secret still requires storing a secret, which does not improve security compared to OIDC. Option D is incorrect because setting the 'Publish Profile' parameter to an empty string does not enable OIDC authentication; the deployment would fail due to missing credentials.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Remove the secret and use Azure AD Managed Identity directly from the GitHub runner.
Why it's wrong here
You cannot assign an Azure AD Managed Identity to an external GitHub runner because managed identities are tied to Azure resources such as VMs, App Services, or Functions, and cannot be assumed from outside Azure. Even if the runner were hosted on an Azure VM, using that VM's managed identity would require the runner to run inside that VM and would not work for GitHub-hosted runners. OIDC federated credentials are the only supported way for GitHub Actions to obtain short-lived Azure credentials without storing secrets.
- ✓
Configure the GitHub workflow to use the 'azure/login' action with OIDC, and set up a federated identity credential in Microsoft Entra ID for the GitHub environment.
Why this is correct
The 'azure/login' action with OIDC exchanges GitHub's OIDC token for an Azure AD access token by using a federated identity credential configured in Microsoft Entra ID for the GitHub environment. You create the credential with the correct subject identifier (e.g., repo:owner/repo:environment:prod) so that GitHub's token is trusted, and the action automatically retrieves the token without requiring a client secret. This eliminates long-lived secrets, enables automatic token rotation, and is the recommended secure pattern for GitHub Actions to Azure deployments.
- ✗
Replace the publish profile secret with an Azure service principal secret stored as a GitHub secret.
Why it's wrong here
Replacing the publish profile secret with a service principal secret stored as a GitHub secret changes the type of credential but does not remove the long-lived secret from the workflow. A service principal password is static, can expire, and must be manually rotated, whereas OIDC generates short-lived tokens on every run. This approach still leaves a high-value secret in GitHub and fails to address the core requirement of secretless authentication.
- ✗
Use the 'Azure App Service Deploy' task with the 'Publish Profile' parameter set to an empty string.
Why it's wrong here
The 'Azure App Service Deploy' task requires an authenticated Azure session; setting 'Publish Profile' to an empty string provides no credentials, so the deployment call will fail with an authentication or authorization error. The task itself cannot initiate OIDC; it relies on a prior 'azure/login' step to establish the Azure context. An empty publish profile is simply invalid, not a secretless solution.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Managed identity
A managed identity is an automatically managed service principal in Azure that allows your code to authenticate to any service that supports Azure AD authentication without storing credentials.
Key term
Environment
An environment is a dedicated set of computing resources, configurations, and services used to develop, test, or host software applications in a controlled and repeatable way.
About these practice questions
One of 823 original AZ-400 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 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.