Practice deployment observability vocabulary: deployment dashboards, watching latency during rollout, deployment markers in Grafana, and post-deployment monitoring.
0 / 30 completed
1 / 30
'The deployment dashboard shows 0 errors in the first _____ minutes.' What window is typically watched?
The first 5 minutes post-deployment is a critical observation window — most regressions from a bad deploy manifest quickly in error rates and latency.
2 / 30
'Deployment _____ in Grafana' are annotations that mark when a deployment happened on metric charts.
Deployment markers (annotations) in Grafana add vertical lines on dashboards showing exactly when a deployment occurred, making it easy to correlate metric changes with releases.
3 / 30
'The canary looks healthy — promoting to _____.' What percentage comes after a successful 10% canary?
A typical progressive promotion moves from 10% → 50% → 100%. '50%' is the standard next step after confirming health at the initial canary weight.
4 / 30
Which two metrics are most commonly watched during a rollout?
Latency (p99/p95) and error rate are the primary SLI/SLO signals watched during deployment — they most directly indicate user-facing impact.
5 / 30
'Post-deployment monitoring' refers to:
Post-deployment monitoring is the active observation period after a release goes live, watching for regressions in SLOs, error budgets, and service health.
6 / 30
Alice: "Hey team, the latency for the new user authentication service has spiked significantly after deployment. I'm seeing a 300ms increase on average."
Alice's message highlights a critical observability concern: increased latency. Simply rolling back isn't always the best immediate response; investigating the underlying metrics is crucial to understand *why* the latency is rising. Increasing instances might mask the problem if it's related to code or configuration, and ignoring the issue would delay finding a solution. This demonstrates proactive monitoring.
7 / 30
During a Slack discussion about a recent deployment of the Payment Gateway service, Ben says: "We should definitely add some SLOs for successful transactions to track our performance."
Ben's statement correctly identifies the value of defining Service Level Objectives (SLOs). SLOs provide measurable targets for performance and reliability, enabling proactive monitoring and alerting. They aren't just for infrastructure – they apply to any service where availability or performance is important. Setting them helps track success and allows for informed decision-making about improvements.
8 / 30
You're reviewing a Pull Request description for deploying a new version of the Inventory Management API. The description includes the following: "Deployed to production via Blue/Green strategy. Monitoring key metrics like request latency and error rates. Initial results look promising – latency is down 10% compared to the previous release."
The PR description accurately reflects key aspects of post-deployment monitoring. While the initial 10% latency reduction is positive, relying solely on this single metric provides an incomplete picture. Longer-term tracking is essential to validate whether the change has a sustained impact and doesn't introduce new issues over time.
9 / 30
Charlie, during a standup meeting, reports: "We deployed the Recommendation Engine update to production earlier today. We're seeing increased CPU utilization on the backend servers."
Charlie's report necessitates investigation. Simply assuming it's peak activity or scaling up without understanding the root cause isn't effective. Investigating the logs and metrics is the crucial first step to identify if the new code is causing the increased CPU usage – this allows for targeted troubleshooting and avoids unnecessary resource allocation.
10 / 30
A Grafana dashboard displays a series of charts showing the performance of a newly deployed application. A 'deployment marker' annotation indicates when the deployment occurred on each chart.
Which of the following best describes the *purpose* of these annotations?
Deployment markers in Grafana are primarily used to correlate changes in application performance (displayed by the charts) with the actual deployment event. This allows developers and operations teams to quickly assess whether a new release is positively or negatively impacting service health – it's about understanding *why* performance changed after deployment, not just tracking timestamps.
11 / 30
Alice: "Hey team, the latency for the new user authentication service has spiked significantly after deployment. I'm seeing a 300ms increase on average."
Alice's message highlights a critical observability concern: increased latency. Simply rolling back isn't always the best immediate response; investigating the underlying metrics is crucial to understand *why* the latency is rising. Increasing instances might mask the problem if it's related to code or configuration, and ignoring the issue would delay finding a solution. This demonstrates proactive monitoring.
12 / 30
During a Slack discussion about a recent deployment of the Payment Gateway service, Ben says: "We should definitely add some SLOs for successful transactions to track our performance."
Ben's statement correctly identifies the value of defining Service Level Objectives (SLOs). SLOs provide measurable targets for performance and reliability, enabling proactive monitoring and alerting. They aren't just for infrastructure – they apply to any service where availability or performance is important. Setting them helps track success and allows for informed decision-making about improvements.
13 / 30
You're reviewing a Pull Request description for deploying a new version of the Inventory Management API. The description includes the following: "Deployed to production via Blue/Green strategy. Monitoring key metrics like request latency and error rates. Initial results look promising – latency is down 10% compared to the previous release."
The PR description accurately reflects key aspects of post-deployment monitoring. While the initial 10% latency reduction is positive, relying solely on this single metric provides an incomplete picture. Longer-term tracking is essential to validate whether the change has a sustained impact and doesn't introduce new issues over time.
14 / 30
Charlie, during a standup meeting, reports: "We deployed the Recommendation Engine update to production earlier today. We're seeing increased CPU utilization on the backend servers."
Charlie's report necessitates investigation. Simply assuming it's peak activity or scaling up without understanding the root cause isn't effective. Investigating the logs and metrics is the crucial first step to identify if the new code is causing the increased CPU usage – this allows for targeted troubleshooting and avoids unnecessary resource allocation.
15 / 30
A Grafana dashboard displays a series of charts showing the performance of a newly deployed application. A 'deployment marker' annotation indicates when the deployment occurred on each chart.
Which of the following best describes the *purpose* of these annotations?
Deployment markers in Grafana are primarily used to correlate changes in application performance (displayed by the charts) with the actual deployment event. This allows developers and operations teams to quickly assess whether a new release is positively or negatively impacting service health – it's about understanding *why* performance changed after deployment, not just tracking timestamps.
16 / 30
Alice: "Hey team, the latency for the new user authentication service has spiked significantly after deployment. I'm seeing a 300ms increase on average."
Alice's message highlights a critical observability concern: increased latency. Simply rolling back isn't always the best immediate response; investigating the underlying metrics is crucial to understand *why* the latency is rising. Increasing instances might mask the problem if it's related to code or configuration, and ignoring the issue would delay finding a solution. This demonstrates proactive monitoring.
17 / 30
During a Slack discussion about a recent deployment of the Payment Gateway service, Ben says: "We should definitely add some SLOs for successful transactions to track our performance."
Ben's statement correctly identifies the value of defining Service Level Objectives (SLOs). SLOs provide measurable targets for performance and reliability, enabling proactive monitoring and alerting. They aren't just for infrastructure – they apply to any service where availability or performance is important. Setting them helps track success and allows for informed decision-making about improvements.
18 / 30
You're reviewing a Pull Request description for deploying a new version of the Inventory Management API. The description includes the following: "Deployed to production via Blue/Green strategy. Monitoring key metrics like request latency and error rates. Initial results look promising – latency is down 10% compared to the previous release."
The PR description accurately reflects key aspects of post-deployment monitoring. While the initial 10% latency reduction is positive, relying solely on this single metric provides an incomplete picture. Longer-term tracking is essential to validate whether the change has a sustained impact and doesn't introduce new issues over time.
19 / 30
Charlie, during a standup meeting, reports: "We deployed the Recommendation Engine update to production earlier today. We're seeing increased CPU utilization on the backend servers."
Charlie's report necessitates investigation. Simply assuming it's peak activity or scaling up without understanding the root cause isn't effective. Investigating the logs and metrics is the crucial first step to identify if the new code is causing the increased CPU usage – this allows for targeted troubleshooting and avoids unnecessary resource allocation.
20 / 30
A Grafana dashboard displays a series of charts showing the performance of a newly deployed application. A 'deployment marker' annotation indicates when the deployment occurred on each chart.
Which of the following best describes the *purpose* of these annotations?
Deployment markers in Grafana are primarily used to correlate changes in application performance (displayed by the charts) with the actual deployment event. This allows developers and operations teams to quickly assess whether a new release is positively or negatively impacting service health – it's about understanding *why* performance changed after deployment, not just tracking timestamps.
21 / 30
Alice: "Hey team, the latency for the new user authentication service has spiked significantly after deployment. I'm seeing a 300ms increase on average."
Alice's message highlights a critical observability concern: increased latency. Simply rolling back isn't always the best immediate response; investigating the underlying metrics is crucial to understand *why* the latency is rising. Increasing instances might mask the problem if it's related to code or configuration, and ignoring the issue would delay finding a solution. This demonstrates proactive monitoring.
22 / 30
During a Slack discussion about a recent deployment of the Payment Gateway service, Ben says: "We should definitely add some SLOs for successful transactions to track our performance."
Ben's statement correctly identifies the value of defining Service Level Objectives (SLOs). SLOs provide measurable targets for performance and reliability, enabling proactive monitoring and alerting. They aren't just for infrastructure – they apply to any service where availability or performance is important. Setting them helps track success and allows for informed decision-making about improvements.
23 / 30
You're reviewing a Pull Request description for deploying a new version of the Inventory Management API. The description includes the following: "Deployed to production via Blue/Green strategy. Monitoring key metrics like request latency and error rates. Initial results look promising – latency is down 10% compared to the previous release."
The PR description accurately reflects key aspects of post-deployment monitoring. While the initial 10% latency reduction is positive, relying solely on this single metric provides an incomplete picture. Longer-term tracking is essential to validate whether the change has a sustained impact and doesn't introduce new issues over time.
24 / 30
Charlie, during a standup meeting, reports: "We deployed the Recommendation Engine update to production earlier today. We're seeing increased CPU utilization on the backend servers."
Charlie's report necessitates investigation. Simply assuming it's peak activity or scaling up without understanding the root cause isn't effective. Investigating the logs and metrics is the crucial first step to identify if the new code is causing the increased CPU usage – this allows for targeted troubleshooting and avoids unnecessary resource allocation.
25 / 30
A Grafana dashboard displays a series of charts showing the performance of a newly deployed application. A 'deployment marker' annotation indicates when the deployment occurred on each chart.
Which of the following best describes the *purpose* of these annotations?
Deployment markers in Grafana are primarily used to correlate changes in application performance (displayed by the charts) with the actual deployment event. This allows developers and operations teams to quickly assess whether a new release is positively or negatively impacting service health – it's about understanding *why* performance changed after deployment, not just tracking timestamps.
26 / 30
Alice: "Hey team, the latency for the new user authentication service has spiked significantly after deployment. I'm seeing a 300ms increase on average."
Alice's message highlights a critical observability concern: increased latency. Simply rolling back isn't always the best immediate response; investigating the underlying metrics is crucial to understand *why* the latency is rising. Increasing instances might mask the problem if it's related to code or configuration, and ignoring the issue would delay finding a solution. This demonstrates proactive monitoring.
27 / 30
During a Slack discussion about a recent deployment of the Payment Gateway service, Ben says: "We should definitely add some SLOs for successful transactions to track our performance."
Ben's statement correctly identifies the value of defining Service Level Objectives (SLOs). SLOs provide measurable targets for performance and reliability, enabling proactive monitoring and alerting. They aren't just for infrastructure – they apply to any service where availability or performance is important. Setting them helps track success and allows for informed decision-making about improvements.
28 / 30
You're reviewing a Pull Request description for deploying a new version of the Inventory Management API. The description includes the following: "Deployed to production via Blue/Green strategy. Monitoring key metrics like request latency and error rates. Initial results look promising – latency is down 10% compared to the previous release."
The PR description accurately reflects key aspects of post-deployment monitoring. While the initial 10% latency reduction is positive, relying solely on this single metric provides an incomplete picture. Longer-term tracking is essential to validate whether the change has a sustained impact and doesn't introduce new issues over time.
29 / 30
Charlie, during a standup meeting, reports: "We deployed the Recommendation Engine update to production earlier today. We're seeing increased CPU utilization on the backend servers."
Charlie's report necessitates investigation. Simply assuming it's peak activity or scaling up without understanding the root cause isn't effective. Investigating the logs and metrics is the crucial first step to identify if the new code is causing the increased CPU usage – this allows for targeted troubleshooting and avoids unnecessary resource allocation.
30 / 30
A Grafana dashboard displays a series of charts showing the performance of a newly deployed application. A 'deployment marker' annotation indicates when the deployment occurred on each chart.
Which of the following best describes the *purpose* of these annotations?
Deployment markers in Grafana are primarily used to correlate changes in application performance (displayed by the charts) with the actual deployment event. This allows developers and operations teams to quickly assess whether a new release is positively or negatively impacting service health – it's about understanding *why* performance changed after deployment, not just tracking timestamps.
What will I practice in "Deployment Observability Vocabulary"?
This is a Progressive Delivery Language exercise set. It walks through 30 scenario-based multiple-choice questions built around real usage of progressive delivery 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 30 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 progressive delivery 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 Progressive Delivery Language exercises?
See the Progressive Delivery 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 — progressive delivery language vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.