Learn vocabulary for environment promotion in CI/CD: dev, staging, production, and environment parity.
0 / 29 completed
1 / 29
What is 'environment promotion' in CI/CD vocabulary?
Environment promotion is the controlled progression of a verified artefact through environments — each requiring additional validation before the next step. The artefact (image, package) is identical across environments; only configuration changes.
2 / 29
What is 'environment parity' in deployment vocabulary?
Environment parity (from 12-factor app principles) means staging should be as close to production as possible: same infrastructure type, same services, similar data volumes. Large differences between staging and production cause hard-to-debug production failures.
3 / 29
What is a 'release candidate' (RC) in deployment vocabulary?
A release candidate is a build that has passed all quality gates in staging and is the proposed version for production. It becomes the production release if final checks pass — or is rejected and replaced if issues are found.
4 / 29
What is 'blue-green deployment' in vocabulary?
Blue-green deployment maintains two identical production environments. Traffic goes to blue; new version deploys to green; traffic switches to green. If problems occur, traffic switches back to blue instantly — zero-downtime deployment with instant rollback.
5 / 29
What is 'GitOps' in deployment vocabulary?
GitOps (popularised by Flux and ArgoCD) uses Git PRs as the mechanism for all infrastructure and deployment changes — a git merge triggers reconciliation, bringing the system state to match the declared desired state in the repo.
6 / 29
Reviewer: 'I'm seeing a lot of logs flapping between the staging and production environments. It looks like we're running different versions of the logging library in each. This is causing inconsistent error reporting and makes debugging extremely difficult.
What does this reviewer *mean* when they say 'logging library version mismatch'? Consider the context of environment promotion and its impact on deployments.
This question focuses on a common issue arising from poorly managed environment promotion. The reviewer isn't simply criticizing different log levels; they're pointing out a fundamental problem: inconsistent dependencies across environments.
Misinterpreting 'logging library version mismatch' as only referring to log level configurations overlooks the core concept that differing versions can introduce unexpected behavior and break compatibility, directly impacting debugging efforts. A consistent environment promotes predictable deployments and reduces these types of issues.
7 / 29
Reviewer: 'I'm seeing a lot of logs flapping between the staging and production environments. It looks like we're running different versions of the logging library in each. This is causing inconsistent error reporting and makes debugging extremely difficult.
What does this reviewer *mean* when they say 'logging library version mismatch'? Consider the context of environment promotion and its impact on deployments.
This question focuses on a common issue arising from poorly managed environment promotion. The reviewer isn't simply criticizing different log levels; they're pointing out a fundamental problem: inconsistent dependencies across environments.
Misinterpreting 'logging library version mismatch' as only referring to log level configurations overlooks the core concept that differing versions can introduce unexpected behavior and break compatibility, directly impacting debugging efforts. A consistent environment promotes predictable deployments and reduces these types of issues.
8 / 29
Reviewer: 'I'm seeing a lot of logs flapping between the staging and production environments. It looks like we're running different versions of the logging library in each. This is causing inconsistent error reporting and makes debugging extremely difficult.
What does this reviewer *mean* when they say 'logging library version mismatch'? Consider the context of environment promotion and its impact on deployments.
This question focuses on a common issue arising from poorly managed environment promotion. The reviewer isn't simply criticizing different log levels; they're pointing out a fundamental problem: inconsistent dependencies across environments.
Misinterpreting 'logging library version mismatch' as only referring to log level configurations overlooks the core concept that differing versions can introduce unexpected behavior and break compatibility, directly impacting debugging efforts. A consistent environment promotes predictable deployments and reduces these types of issues.
9 / 29
Reviewer: 'I'm seeing a lot of logs flapping between the staging and production environments. It looks like we're running different versions of the logging library in each. This is causing inconsistent error reporting and makes debugging extremely difficult.
What does this reviewer *mean* when they say 'logging library version mismatch'? Consider the context of environment promotion and its impact on deployments.
This question focuses on a common issue arising from poorly managed environment promotion. The reviewer isn't simply criticizing different log levels; they're pointing out a fundamental problem: inconsistent dependencies across environments.
Misinterpreting 'logging library version mismatch' as only referring to log level configurations overlooks the core concept that differing versions can introduce unexpected behavior and break compatibility, directly impacting debugging efforts. A consistent environment promotes predictable deployments and reduces these types of issues.
10 / 29
Alex: "Hey team, I've just deployed a new version of the user authentication service to staging. Can someone verify it's working as expected?" What does 'environment promotion' mean in this context?
'Environment promotion' refers to the *process* of moving code and configurations from one environment (like development or staging) to a more production-like environment. It's not just deployment; it includes steps like testing and verification within that target environment. Option A is too broad – it doesn't specify the deliberate movement to a specific environment.
11 / 29
Sarah (as a Slack message): "I'm getting this error in production: 'No such file or directory'. It's not showing up in staging. What could be causing this?"
Which of the following is MOST likely the root cause?
This error strongly suggests a discrepancy in how paths are defined and used between the environments. 'Environment parity' means that all environments – staging, testing, and production – should have identical configurations, including paths to files and directories. Option A is possible but less direct than a configuration mismatch.
12 / 29
Mark (in a PR description): "This release includes updated dependencies for the analytics library. We've ensured environment parity across all stages before merging to production." What is the primary goal of 'environment parity' in this scenario?
'Environment parity' is about ensuring that the different environments – staging, testing, and production – are as identical as possible. This creates a reliable testing ground because any issues observed in production are likely due to configuration differences, not inherent code problems. It's crucial for accurate regression testing.
13 / 29
David (during a standup): "We're planning to use a blue-green deployment strategy for the next major feature release. What is the main benefit of this approach?"
'Blue-green deployment' involves running two identical environments – blue (live) and green (staging). New code is deployed to the green environment, tested, and then traffic is switched over. This minimizes downtime because if issues arise, you can quickly revert to the blue environment. Option A is a related benefit but not the core purpose.
14 / 29
Emily (in a code review comment): "I noticed that our logging configuration differs slightly between staging and production. This could lead to inconsistent error reporting. We should strive for GitOps principles to ensure consistent configurations across all environments.". What does 'GitOps' primarily represent?
'GitOps' is a methodology that uses Git repositories to manage and automate infrastructure changes. It dictates that the desired state of your systems (e.g., configurations, deployments) are defined in Git and automatically applied when changes are pushed to the repository. This ensures consistency across environments.
15 / 29
Alex: "Hey team, I've just deployed a new version of the user authentication service to staging. Can someone verify it's working as expected?" What does 'environment promotion' mean in this context?
'Environment promotion' refers to the *process* of moving code and configurations from one environment (like development or staging) to a more production-like environment. It's not just deployment; it includes steps like testing and verification within that target environment. Option A is too broad – it doesn't specify the deliberate movement to a specific environment.
16 / 29
Sarah (as a Slack message): "I'm getting this error in production: 'No such file or directory'. It's not showing up in staging. What could be causing this?"
Which of the following is MOST likely the root cause?
This error strongly suggests a discrepancy in how paths are defined and used between the environments. 'Environment parity' means that all environments – staging, testing, and production – should have identical configurations, including paths to files and directories. Option A is possible but less direct than a configuration mismatch.
17 / 29
Mark (in a PR description): "This release includes updated dependencies for the analytics library. We've ensured environment parity across all stages before merging to production." What is the primary goal of 'environment parity' in this scenario?
'Environment parity' is about ensuring that the different environments – staging, testing, and production – are as identical as possible. This creates a reliable testing ground because any issues observed in production are likely due to configuration differences, not inherent code problems. It's crucial for accurate regression testing.
18 / 29
David (during a standup): "We're planning to use a blue-green deployment strategy for the next major feature release. What is the main benefit of this approach?"
'Blue-green deployment' involves running two identical environments – blue (live) and green (staging). New code is deployed to the green environment, tested, and then traffic is switched over. This minimizes downtime because if issues arise, you can quickly revert to the blue environment. Option A is a related benefit but not the core purpose.
19 / 29
Emily (in a code review comment): "I noticed that our logging configuration differs slightly between staging and production. This could lead to inconsistent error reporting. We should strive for GitOps principles to ensure consistent configurations across all environments.". What does 'GitOps' primarily represent?
'GitOps' is a methodology that uses Git repositories to manage and automate infrastructure changes. It dictates that the desired state of your systems (e.g., configurations, deployments) are defined in Git and automatically applied when changes are pushed to the repository. This ensures consistency across environments.
20 / 29
Alex: "Hey team, I've just deployed a new version of the user authentication service to staging. Can someone verify it's working as expected?" What does 'environment promotion' mean in this context?
'Environment promotion' refers to the *process* of moving code and configurations from one environment (like development or staging) to a more production-like environment. It's not just deployment; it includes steps like testing and verification within that target environment. Option A is too broad – it doesn't specify the deliberate movement to a specific environment.
21 / 29
Sarah (as a Slack message): "I'm getting this error in production: 'No such file or directory'. It's not showing up in staging. What could be causing this?"
Which of the following is MOST likely the root cause?
This error strongly suggests a discrepancy in how paths are defined and used between the environments. 'Environment parity' means that all environments – staging, testing, and production – should have identical configurations, including paths to files and directories. Option A is possible but less direct than a configuration mismatch.
22 / 29
Mark (in a PR description): "This release includes updated dependencies for the analytics library. We've ensured environment parity across all stages before merging to production." What is the primary goal of 'environment parity' in this scenario?
'Environment parity' is about ensuring that the different environments – staging, testing, and production – are as identical as possible. This creates a reliable testing ground because any issues observed in production are likely due to configuration differences, not inherent code problems. It's crucial for accurate regression testing.
23 / 29
David (during a standup): "We're planning to use a blue-green deployment strategy for the next major feature release. What is the main benefit of this approach?"
'Blue-green deployment' involves running two identical environments – blue (live) and green (staging). New code is deployed to the green environment, tested, and then traffic is switched over. This minimizes downtime because if issues arise, you can quickly revert to the blue environment. Option A is a related benefit but not the core purpose.
24 / 29
Emily (in a code review comment): "I noticed that our logging configuration differs slightly between staging and production. This could lead to inconsistent error reporting. We should strive for GitOps principles to ensure consistent configurations across all environments.". What does 'GitOps' primarily represent?
'GitOps' is a methodology that uses Git repositories to manage and automate infrastructure changes. It dictates that the desired state of your systems (e.g., configurations, deployments) are defined in Git and automatically applied when changes are pushed to the repository. This ensures consistency across environments.
25 / 29
Alex: "Hey team, I've just deployed a new version of the user authentication service to staging. Can someone verify it's working as expected?" What does 'environment promotion' mean in this context?
'Environment promotion' refers to the *process* of moving code and configurations from one environment (like development or staging) to a more production-like environment. It's not just deployment; it includes steps like testing and verification within that target environment. Option A is too broad – it doesn't specify the deliberate movement to a specific environment.
26 / 29
Sarah (as a Slack message): "I'm getting this error in production: 'No such file or directory'. It's not showing up in staging. What could be causing this?"
Which of the following is MOST likely the root cause?
This error strongly suggests a discrepancy in how paths are defined and used between the environments. 'Environment parity' means that all environments – staging, testing, and production – should have identical configurations, including paths to files and directories. Option A is possible but less direct than a configuration mismatch.
27 / 29
Mark (in a PR description): "This release includes updated dependencies for the analytics library. We've ensured environment parity across all stages before merging to production." What is the primary goal of 'environment parity' in this scenario?
'Environment parity' is about ensuring that the different environments – staging, testing, and production – are as identical as possible. This creates a reliable testing ground because any issues observed in production are likely due to configuration differences, not inherent code problems. It's crucial for accurate regression testing.
28 / 29
David (during a standup): "We're planning to use a blue-green deployment strategy for the next major feature release. What is the main benefit of this approach?"
'Blue-green deployment' involves running two identical environments – blue (live) and green (staging). New code is deployed to the green environment, tested, and then traffic is switched over. This minimizes downtime because if issues arise, you can quickly revert to the blue environment. Option A is a related benefit but not the core purpose.
29 / 29
Emily (in a code review comment): "I noticed that our logging configuration differs slightly between staging and production. This could lead to inconsistent error reporting. We should strive for GitOps principles to ensure consistent configurations across all environments.". What does 'GitOps' primarily represent?
'GitOps' is a methodology that uses Git repositories to manage and automate infrastructure changes. It dictates that the desired state of your systems (e.g., configurations, deployments) are defined in Git and automatically applied when changes are pushed to the repository. This ensures consistency across environments.
What will I practice in "Environment Promotion — Vocabulary and Language"?
This is a CI/CD Pipeline Language exercise set. It walks through 29 scenario-based multiple-choice questions built around real usage of CI/CD Pipeline Language terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 29 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the CI/CD Pipeline Language vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more CI/CD Pipeline Language exercises?
See the CI/CD Pipeline Language exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — CI/CD Pipeline Language vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.