DevOps / GitLab CI Basics Interview Questions
What is the 'resource_group' keyword and how does it prevent concurrent deployments?
The resource_group keyword ensures that only one job with the same resource group name runs at a time across all pipelines. This prevents concurrent deployments to the same environment, which can cause race conditions or configuration conflicts.
# Prevent concurrent deployments to production: deploy-production: stage: deploy script: - ./deploy.sh production resource_group: production # only one "production" deploy at a time environment: production # Multiple environments, each serialized separately: deploy-staging: script: ./deploy.sh staging resource_group: staging # serializes staging deploys deploy-production: script: ./deploy.sh production resource_group: production # serializes production deploys separately # Process mode (controls job ordering within the group): deploy-job: resource_group: my-group process_mode: oldest_first # FIFO - deploy in the order triggered # Options: # oldest_first (default): FIFO queue # newest_first: LIFO - skip old deploys, do most recent # unordered: no ordering guarantee
| Mode | Behaviour | Best for |
|---|---|---|
| oldest_first (default) | Queue in order - FIFO, every deploy runs | Compliance-critical environments |
| newest_first | LIFO - newer jobs skip older ones waiting in queue | Fast-moving dev environments |
| unordered | No guaranteed order | Non-deployment resource exclusion |
Why this matters: without resource groups, if two pipelines both have a deploy-to-production job and run at the same time, both deployment scripts could run concurrently, overwriting each other's changes or causing partial deployments.
What does the 'resource_group' keyword guarantee in GitLab CI?
Which resource_group process_mode would you use to skip outdated deploy jobs and only run the most recently triggered one?
More Related questions...
