Courseiva
Design and implement build and release pipelinesmediumMultiple ChoiceObjective-mapped

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

Your team uses GitHub Actions to build and deploy a static website to Azure Storage. The workflow uses the 'azure/storage-blob-upload' action to deploy to a storage account static website. Recently, deployments started failing with 'Error: Failed to get credentials'. The workflow uses OpenID Connect (OIDC) for authentication. What is the most likely cause?

⚠ Common exam trap

Many candidates confuse authentication (OIDC token exchange) with authorization (role assignment), assuming a valid OIDC configuration automatically grants access, when in fact the service principal must have the appropriate Azure RBAC role on the target resource.

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

The service principal used for OIDC does not have the 'Storage Blob Data Contributor' role on the storage account.

The 'azure/storage-blob-upload' action requires the service principal used for OIDC authentication to have the 'Storage Blob Data Contributor' role on the storage account to upload static website content. Without this role, the action fails to obtain credentials for blob write operations, resulting in the 'Failed to get credentials' error.

Answer analysis

Option-by-option breakdown

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

  • The service principal used for OIDC does not have the 'Storage Blob Data Contributor' role on the storage account.

    Why this is correct

    OIDC only authenticates the GitHub workflow as the service principal; for the upload to succeed, that principal must also be authorized for data operations. Without the 'Storage Blob Data Contributor' role assigned on the storage account (or a containing scope), Azure returns an authorization failure even though authentication succeeded.

  • The storage account firewall is blocking the GitHub Actions IP range.

    Why it's wrong here

    A storage account firewall denying GitHub Actions IP ranges would prevent the TCP connection entirely, producing a timeout or connection error, not a credential/authentication failure. Because OIDC authentication occurs before any network access to blob storage, the described symptom points to an RBAC authorization problem instead.

  • The OIDC configuration in GitHub is missing the 'client secret' field.

    Why it's wrong here

    OIDC authentication does not use a client secret; it relies on a federated credential with issuer, subject, and audience claims exchanged for a short-lived access token. The 'client secret' field belongs to service principal authentication and is not part of the GitHub Actions OIDC workflow.

  • The 'azure/storage-blob-upload' action does not support static websites.

    Why it's wrong here

    The azure/storage-blob-upload action explicitly supports static websites through the 'app-type' input, which you set to 'static-website' to target the '$web' container. Thus, the action is fully capable of deploying a static site, and a failure here would be due to configuration or authorization, not lack of support.

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 →

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.