AZ-400 Practice Question: Design and implement build and release pipelines
Your organization uses GitHub Actions for CI/CD. You have a workflow that builds a .NET application and runs tests. The workflow uses a self-hosted runner on an on-premises Windows server. Recently, builds started failing with 'Access to the path is denied' errors when the runner tries to restore NuGet packages. The runner has been working for months. What is the most likely cause?
⚠ Common exam trap
Many candidates confuse authentication failures (token expiry) with local file system permission errors, assuming any 'access denied' relates to GitHub connectivity rather than the runner's service account permissions on the on-premises machine.
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 runner service account's permissions have changed, and it no longer has write access to the working directory or cache.
The 'Access to the path is denied' error during NuGet restore on a self-hosted runner typically indicates a file system permission issue. Since the runner has been working for months, the most likely cause is that the service account under which the runner runs no longer has write access to the working directory or the NuGet cache folder, often due to a group policy change, account modification, or folder permission drift.
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 runner's authentication token to GitHub has expired.
Why it's wrong here
A GitHub authentication token is used only for authenticating the runner with GitHub APIs (e.g., to fetch jobs or upload artifacts); it does not govern filesystem permissions on the runner itself. An expired token would cause API authentication errors, not an 'access denied' error when writing to a local working directory or cache.
- ✓
The runner service account's permissions have changed, and it no longer has write access to the working directory or cache.
Why this is correct
If the Windows service or daemon account that runs the runner no longer has write permissions on the workspace, _work, or the NuGet cache directory, the restore step fails with an access denied (UnauthorizedAccessException) error. This exactly matches the symptom, as permission changes on the runner service account directly affect local file access.
- ✗
The NuGet cache directory on the runner has been deleted.
Why it's wrong here
Deleting the NuGet cache directory would cause a DirectoryNotFoundException or 'path not found' error when NuGet tries to access or create the cache, not an 'access denied' error. 'Access denied' indicates the path exists but the runner account lacks sufficient write permissions, which is a different failure mode.
- ✗
The runner has been updated to a newer version that no longer supports NuGet restore.
Why it's wrong here
GitHub Actions runner updates are backward compatible and do not remove support for NuGet restore; NuGet restore is performed by workflow steps or commands like 'dotnet restore' running inside the job, not by the runner host itself. A runner version change would not affect NuGet functionality and therefore cannot be the cause of an access denied error.
Go deeper
Related to this question
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.