A production deploy job must share a concurrency group named 'prod-deploy' so only one production deployment runs at a time, and queued deploys should wait rather than cancel the active one. Which job configuration is correct?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Same concurrency group serializes runs; cancel-in-progress: false (the default) queues the new run until the current one finishes — perfect for non-interruptible production deploys.
Full explanation below image
Full Explanation
Concurrency groups limit how many workflow or job runs with the same group key execute simultaneously. For production, you typically want exactly one active deploy and you do not want a newer push to abort an in-flight release. Setting concurrency.group to a fixed name like prod-deploy and cancel-in-progress: false achieves that: the second run waits. cancel-in-progress: true would kill the running deploy when a new one arrives, which is dangerous for production. A bare concurrency: prod-deploy string form is not valid YAML for this use case — group must be under the concurrency mapping. max-parallel limits matrix fan-out within one run, not cross-run deployments. environment.exclusive is not a valid GitHub Actions key; environment protection rules and concurrency are separate controls that can be combined.