Courseiva
Design and implement build and release pipelineshardMultiple ChoiceObjective-mapped

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

Your team uses Azure Pipelines for CI/CD. A release pipeline fails intermittently during deployment to an Azure App Service slot. The error message indicates 'Failed to fetch access token for Azure Resource Manager service endpoint.' The service principal used has been granted Contributor role on the resource group. The issue resolves after re-creating the service connection in Azure DevOps. What is the most likely cause?

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 client secret has expired.

Service principal credentials (client secret) can expire, causing intermittent token fetch failures. Re-creating the service connection generates a new secret, temporarily resolving the issue until it expires again. Option B is wrong because the service connection is bound to the service principal, not the user who created it; removing the user does not affect the existing connection. Option C is wrong because network restrictions would cause consistent failure, not intermittent. Option D is wrong because the service principal already has the Contributor role on the resource group.

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 client secret has expired.

    Why this is correct

    The service principal client secret has expired. Because Azure DevOps caches Azure AD tokens for a period, the pipeline may succeed on cached tokens and then fail when it must refresh them, producing the intermittent behavior seen here. Once the secret expires, any new token request to Azure AD is rejected with a 401, so the ARM deployment service connection fails. Re-creating the service connection generates a fresh client secret, which is why that is the correct remedy.

  • The user who created the service connection has been removed from Azure DevOps.

    Why it's wrong here

    The user who created the service connection has been removed from Azure DevOps. Service connections are bound to the registered Azure AD application (service principal) and its credentials, not to the individual Azure DevOps user who created the connection. Even if that user is deleted from Azure DevOps, the pipeline still authenticates to Azure using the service principal’s app ID and secret. Removing the user only removes that person’s access to manage the organization—it does not invalidate the underlying Azure AD authentication for the pipeline.

  • The Azure DevOps organization is behind a firewall that blocks outbound requests to Azure Resource Manager.

    Why it's wrong here

    The Azure DevOps organization is behind a firewall that blocks outbound requests to Azure Resource Manager. Azure DevOps is a managed cloud service, not a customer-hosted environment with an outbound firewall that selectively blocks traffic to ARM while still allowing pipeline jobs to run. Moreover, if outbound requests to Azure Resource Manager were blocked, every ARM-related task would fail consistently from the moment the block is in place, not intermittently. A network-level block prevents token acquisition outright, so you would see continuous authorization errors rather than occasional ones.

  • The service principal lacks the required role on the target resource group.

    Why it's wrong here

    The service principal lacks the required role on the target resource group. A missing role assignment on the Azure resource group results in authorization failures (HTTP 403 Forbidden) when the pipeline attempts to deploy resources, but it does not prevent the service principal from acquiring an access token. Token acquisition via the client credentials flow only requires valid app credentials, not any RBAC role. Thus, the symptom would be consistent deployment errors, not intermittent secret-related failures, and adding a role would not resolve an expired secret.

Visual reference

Client DHCP Server 1 Discover (broadcast) 2 Offer (IP: 192.168.1.10) 3 Request (I accept) 4 Acknowledge (lease confirmed) DORA — the four-step DHCP lease process

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.