Resolving an Intermittent Microsoft-Hosted Agent Timeout on an App1 Build Job

AZ-400 By islever Editorial Last updated

Design and implement pipelines

Short answer

D Free Microsoft-hosted parallel jobs cap a job at 60 minutes while paid ones raise it to 360, so buying parallel jobs removes the timeout with no infrastructure.

Question

You have an Azure pipeline that is used to build and deploy an app named App1. The build job uses a Microsoft-hosted Windows agent. The build job for App1 intermittently returns a timeout error. You need to ensure that the build job completes successfully. The solution must minimize administrative effort. What should you do?
  1. Change the configuration of the build agent.
  2. Deploy a self-hosted agent.
  3. Change to a Microsoft-hosted Linux agent.
  4. Purchase more parallel jobs. Correct Answer

Key Takeaways

The free tier of Microsoft-hosted parallel jobs caps a single job at 60 minutes, while paid Microsoft-hosted parallel jobs raise that hard limit to 360 minutes, so raising the ceiling through additional parallel jobs removes the timeout without maintaining any infrastructure.

An Azure pipeline builds and deploys an app named App1, and the build job on a Microsoft-hosted Windows agent intermittently returns a timeout error. The fix must ensure the job completes while minimizing administrative effort, and the root cause is the execution-time ceiling applied to Microsoft-hosted agents.

Common mistake: Changing the agent configuration or switching to a self-hosted agent, both of which require deploying and maintaining infrastructure that the problem does not demand. The timeout comes from the hosted agent tier limit, not from a misconfigured or underpowered agent.

Expert Analysis

Why the Answer Is Correct

The build job times out intermittently on a Microsoft-hosted Windows agent, and the documented reason is the per-job execution ceiling on Microsoft-hosted parallel jobs: the free allowance caps jobs at 60 minutes each, whereas paid Microsoft-hosted parallel jobs raise the hard limit to 360 minutes. Because the requirement is to minimize administrative effort, purchasing additional parallel jobs is a configuration change that removes the ceiling immediately and requires no infrastructure to build or maintain. The vote was 57 for D and 33 for B. freddyneen gave the clearest statement of the two tiers, noting that a private project gets one free Microsoft-hosted agent running jobs up to 60 minutes, and that paying for additional parallel jobs yields the 360-minute hard limit, and cited the hosted agents documentation directly.

Why the Other Options Are Wrong

Deploying a self-hosted agent (B) is the option the community runner-up chose, and arr73's reasoning is technically sound since a self-hosted agent does let you set a longer timeout and rules out agent-side timeouts. It loses on the stated constraint, though, because a self-hosted agent is infrastructure you must provision, secure, patch, and maintain, which is the opposite of minimizing administrative effort. Changing to a Microsoft-hosted Linux agent (C) does not raise the ceiling either, since the timeout limit applies to Microsoft-hosted parallel jobs regardless of the agent operating system, so the intermittent timeout would persist. Changing the configuration of the build agent (A) is likewise ineffective, because the agent configuration is not what determines the job execution limit; the limit comes from the hosted agent tier the job runs under.

Community Comment Notes

The community split 57 for D and 33 for B, and the disagreement is about which lever the question wants. arr73, the highest-liked commenter, chose B and quoted the documentation line about increasing the max timeout, which lists buying a Microsoft-hosted agent and using a self-hosted agent as the two options, and UrbanRellik added the sharpest practical argument for B, noting that even 360 minutes is still a ceiling, so going self-hosted is the only way to remove the timeout variable entirely. d526b99, AnishGS, and hotspot02103 argued the opposite way for D, with AnishGS pointing at the minimize administrative effort wording and hotspot02103 noting the exam's own bias toward the purchase option. djhyfdgjk made a technically correct objection that the real fix is the timeoutInMinutes job property, which no option offers, so the question is imperfect; within the given choices, D is the lowest-effort answer.

Official Reference

https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml

This link opens the official vendor documentation in a new tab.

Community Votes

D
63%
B
37%

63% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 14 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 14

  1. arr73 👍 4 Answered B
    I’ll go for B (self hosted agent) becaute it allows to set a timeout of rule out any timeout issues due to the agent. As indicated in MS Documentation in the reference below: “To increase the max timeout for a job, you can opt for any of the following. Buy a Microsoft hosted agent which will give you 360 minutes for all jobs, irrespective of the repository used Use a self-hosted agent to rule out any timeout issues due to the agent” Ref: https://learn.microsoft.com/en-us/azure/devops/pipelines/troubleshooting/troubleshooting?view=azure-devops#job-time-out
  2. d526b99 👍 3
    Selected Answer is D. Purchase more parallel jobs. Here's why: Minimizes administrative effort: Purchasing more parallel jobs is the simplest and quickest solution, requiring no configuration changes or agent setup. Addresses the timeout issue: The timeout errors likely occur due to resource constraints on the shared Microsoft-hosted agents. More parallel jobs provide additional resources for the build job, reducing the likelihood of timeouts
  3. freddyneen 👍 3 Answered D
    For private projects there is one free Microsoft-hosted agent which can run jobs up to 60 minutes each time. You can pay for additional parallel jobs which have 360 minutes as the hard limit. https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml
  4. UrbanRellik 👍 2 Answered B
    All MS-Hosted (parallel) jobs will timeout at 360 minutes. Although this appears to be the least administrative effort, there's still a timeout of 360m. Having to go back after a second timeout of 360m, then deploy a self-hosted agent would be more effort. The only way to entirely eliminate the variable of timeout is to use a self-hosted agent.
  5. djhyfdgjk 👍 2
    This is very odd question, because none of the provided answers will solve the timeout problem with the job. The thing which could realy fix this is 'timeoutInMinutes' property of the job.
Show 9 more comments
  1. AnishGS 👍 2 Answered D
    Minimize Administrative effort
  2. FeriAZ 👍 1 Answered D
    Purchasing more parallel jobs allows you to leverage additional Microsoft-hosted agents within the same pool. This increases the available resources for your build job, potentially reducing queuing time and timeouts.
  3. hotspot02103 👍 1 Answered D
    as somebody else wrote in diff comment, if there is a doubt chose the purchase reply -> that's MS, they need to sell :)
  4. dddddddddddww12 👍 1 Answered A
    A. Change the configuration of the build agent. you need to change the timeout setting as there is only one build jobs
  5. xda 👍 1 Answered D
    Ill go with D, because ist said "The solution must minimize administrative effort."
  6. Tightbot 👍 1 Answered B
    Agree with arr73. And there is only 1 job. So going for self hosted agent
  7. mochiemon 👍 1 Answered A
    Change the timeout settings in the agent job
  8. Munwalinwali 👍 2 Answered D
    Purchase more
  9. Gooldmember 👍 1 Answered D
    I'm convinced

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Committing a 3-GB ZIP of VM Images to Git with Git LFS and Azure Blob Versioning

S-grade

Linking Azure Boards Work Item 123 to a GitHub Pull Request Two Ways

S-grade

Setting Work Item 456 to Done While Linking a GitHub Pull Request to Items 456 457 and 458

S-grade

Surfacing Azure Boards Work Item Status in README.md by Installing the Azure Boards App for GitHub

S-grade

Practice All AZ-400 Questions

Access 100 questions with complete answers and detailed explanations.

View Full AZ-400 Practice Test →

← Back to AZ-400 Study Guide