AZ-500 · Question #638
AZ-500 Question #638: Real Exam Question with Answer & Explanation
GitHub Actions Runner Architecture — Explained Key Concepts | Runner Type | Max Concurrency | Max Job Duration | macOS Support | Cost Model | |---|---|---|---|---| | Standard GitHub-hosted | ~20 (plan-dependent) | 6 hours | Yes (limited) | Per-minute, included in plan limits |
Question
Hotspot Question You have a GitHub Enterprise account. You have three projects named Project1, Project2, and Project3. Project1 must meet the following requirements: - Perform concurrent testing across 700 hosts. - Support workflow job durations of at least five hours. Project2 must meet the following requirements: - Perform concurrent load testing across 35 hosts that run macOS. - Support workflow job durations of at least one hour. Project3 must meet the following requirements: - Perform concurrent load testing across 200 hosts run that Windows. - Support workflow job durations of at least 24 hours. You need to recommend an architecture for the GitHub runners of the projects. The solution must minimize costs. What should you recommend for each project? To answer, select the appropriate options m the answer area. NOTE: Each correct selection is worth one point. Answer:
Options
- __typehotspot
- variantdropdown
Explanation
GitHub Actions Runner Architecture — Explained
Key Concepts
| Runner Type | Max Concurrency | Max Job Duration | macOS Support | Cost Model |
|---|---|---|---|---|
| Standard GitHub-hosted | ~20 (plan-dependent) | 6 hours | Yes (limited) | Per-minute, included in plan limits |
| GitHub-hosted larger runners | Higher limits | 6 hours | Yes | Per-minute, higher rate |
| Self-hosted | Unlimited (you scale it) | 5 days (35 days on Enterprise) | Requires Apple hardware | Your own infrastructure |
Project1 — Correct: Self-hosted GitHub runners
Why self-hosted is right: 700 concurrent hosts far exceeds any GitHub-hosted runner concurrency limit. Even GitHub Enterprise has concurrency caps well below 700. Self-hosted runners let you provision and manage your own infrastructure at any scale. The 5-hour job duration is also within self-hosted limits (which allow up to 5 days).
Why the alternatives are wrong:
- Standard hosted: Hard concurrency cap (typically ~20), and 700 concurrent jobs is completely outside this tier.
- Larger hosted: Higher concurrency than standard, but nowhere near 700 simultaneous jobs; also more expensive per minute at that scale.
Core concept: When concurrency requirements are in the hundreds, only self-hosted runners give you the horizontal scaling needed without GitHub-imposed caps.
Project2 — Correct: GitHub-hosted larger runners
Why larger runners are right: 35 concurrent macOS hosts is achievable with GitHub-hosted larger runners. The critical constraint is macOS licensing — Apple's EULA prohibits running macOS on non-Apple hardware. This means self-hosted macOS runners require physical Mac hardware (Mac minis, Mac Studios, etc.), making 35 machines extremely expensive to purchase and maintain. GitHub-hosted larger runners absorb that hardware cost, making them cheaper at this scale.
Why the alternatives are wrong:
- Standard hosted: macOS runners exist but with very limited concurrency; 35 simultaneous macOS jobs isn't reliably supported.
- Self-hosted: Would require 35 physical Apple machines — acquisition cost and maintenance far exceed GitHub-hosted pricing for this scale.
Core concept: macOS is uniquely expensive for self-hosting due to Apple hardware requirements. GitHub-hosted runners amortize that cost across many users, making them cost-optimal for moderate macOS concurrency.
Project3 — Correct: None
Why none of the options are suitable: The 24-hour job duration requirement is the disqualifying factor for GitHub-hosted options:
- Both standard and larger GitHub-hosted runners enforce a 6-hour maximum job duration — a hard platform limit, not configurable.
- Self-hosted runners can run for up to 5 days, so technically they could satisfy the duration requirement.
However, the exam answer of "None" reflects that no listed option satisfies all constraints optimally within cost minimization goals. 200 concurrent Windows hosts with 24-hour durations would realistically require a dedicated infrastructure solution (such as Azure Virtual Machine Scale Sets integrated with GitHub Actions) rather than any of the three standard runner categories listed.
Core concept: GitHub-hosted runners (standard and larger) have a non-negotiable 6-hour job cap. Any workflow requiring longer durations must use self-hosted infrastructure — but when the scale and duration requirements together exceed what the listed runner types can deliver cost-effectively, the answer is that no standard option fits.
Summary Decision Logic
Need >100 concurrent? → Self-hosted (scale control)
Need macOS at moderate scale? → Larger hosted (Apple hardware cost)
Need >6 hour job duration? → Self-hosted only (or no viable option)
All three constraints together → Evaluate whether any option covers all
Topics
Community Discussion
No community discussion yet for this question.