Production Debugging Vocabulary
Practice production debugging vocabulary: distributed tracing, non-intrusive profiling, audit log reconstruction, canary diagnostics, and remote debugging constraints.
0 / 41 completed
1 / 41
An SRE says 'We can't attach a debugger to production.' Why is this typically true?
Interactive debuggers pause execution at breakpoints — pausing a production process would freeze request handling, causing immediate user impact. Production debugging relies on observability tools (traces, logs, metrics) that provide insight without stopping execution.
2 / 41
A senior engineer says 'The distributed trace shows where the request failed.' What does a distributed trace reveal?
A distributed trace follows a request across all the services it touches, recording the timing and outcome of each operation (service calls, database queries, external API calls). This makes it possible to pinpoint which service or operation caused a latency spike or failure in a complex distributed system.
3 / 41
Your production tooling includes 'a profiler that runs without pausing the process.' What type of profiler is this?
Sampling profilers periodically capture stack traces without pausing the process, introducing minimal overhead. This makes them safe for production. They provide CPU/memory profiles that show where time is being spent — helping diagnose performance issues without a reproduce-in-dev step.
4 / 41
During an incident, your team says 'The audit log reconstructs the event sequence.' What makes an audit log useful for production debugging?
Audit logs are timestamped records of significant events. During debugging, they let you replay what happened: which user action triggered what, what state the system was in at a given time, and what sequence of events preceded the failure — crucial when you can't reproduce the issue locally.
5 / 41
A post-incident report says 'The canary is capturing diagnostic data.' What is a canary in production debugging?
A diagnostic canary routes a small fraction of production traffic to a specially instrumented build — one with verbose logging, extra tracing, or profiling enabled. This captures real production data for debugging while limiting the performance impact and blast radius to a small user subset.
6 / 41
Sarah: "Hey team, I'm seeing a lot of '500 Internal Server Error's in the logs for our new user onboarding flow. The metrics dashboard isn't showing anything obvious – no spikes or unusual patterns. What should we investigate first?"This question simulates a common scenario during production debugging. While restarting servers or scaling infrastructure might be considered later, the immediate priority is to gather detailed information about the errors themselves. Examining application logs for error messages and stack traces provides concrete evidence of what went wrong, allowing developers to pinpoint the root cause rather than relying on broad metrics. The incorrect options represent common missteps – blindly scaling without understanding the problem, ignoring alerts, or assuming a simple restart will fix everything.
7 / 41
Mark: "I've just submitted a pull request to update the payment processing logic. It should be fully tested in staging before deploying to production.". David replies: "Before we merge, could you include some instrumentation around the transaction ID and any external API calls? We need to be able to quickly trace these requests if they fail in production."This scenario highlights the importance of proactive instrumentation in production debugging. While staging testing is valuable, it doesn't fully replicate the complexity and potential failure points of a live system. Adding tracing mechanisms like transaction IDs allows developers to reconstruct the flow of events during an incident, bridging the gap between staging and production. The key here is understanding that production environments introduce new variables (network latency, real user data) that aren't present in a controlled test environment.
8 / 41
Liam: "I'm getting a high number of requests failing with HTTP 502 Bad Gateway errors. The monitoring dashboards show increased latency, but nothing else out of the ordinary." Maya: "Okay, let's add some logging around our interaction with the external CDN to see if we can pinpoint the issue."While a 502 Bad Gateway *can* indicate CDN issues, the prompt describes increased latency without other anomalies. The key here is to isolate the problem – by adding logs around the external CDN interaction, you can gather specific details (like request headers, response codes, and timings) that will definitively show if the CDN is failing or if a different part of the system is causing the slowdown. Focusing solely on the 502 error without further investigation risks missing a more subtle root cause.
9 / 41
David comments during a code review: "I'm noticing unusually high CPU usage on the backend servers. It's not consistently high, but there are periods where it spikes significantly, particularly around 3 AM. We haven't seen this before in staging.". Which of the following is the MOST appropriate next step for investigating this issue?
David's observation highlights a critical need for detailed performance data. Rate limiting (option 2) would be premature without understanding the root cause. A granular monitoring tool that captures process-level CPU usage with timestamps is crucial for identifying patterns and correlations – this allows you to pinpoint exactly which service or process is responsible for the spikes, rather than just seeing a general 'high CPU' metric. Ignoring the issue (option 4) is dangerous as it masks potential problems.
10 / 41
Sarah: "Hey team, I'm seeing a lot of '500 Internal Server Error's in the logs for our new user onboarding flow. The metrics dashboard isn't showing anything obvious – no spikes or unusual patterns. What should we investigate first?"This question simulates a common scenario during production debugging. While restarting servers or scaling infrastructure might be considered later, the immediate priority is to gather detailed information about the errors themselves. Examining application logs for error messages and stack traces provides concrete evidence of what went wrong, allowing developers to pinpoint the root cause rather than relying on broad metrics. The incorrect options represent common missteps – blindly scaling without understanding the problem, ignoring alerts, or assuming a simple restart will fix everything.
11 / 41
Mark: "I've just submitted a pull request to update the payment processing logic. It should be fully tested in staging before deploying to production.". David replies: "Before we merge, could you include some instrumentation around the transaction ID and any external API calls? We need to be able to quickly trace these requests if they fail in production."This scenario highlights the importance of proactive instrumentation in production debugging. While staging testing is valuable, it doesn't fully replicate the complexity and potential failure points of a live system. Adding tracing mechanisms like transaction IDs allows developers to reconstruct the flow of events during an incident, bridging the gap between staging and production. The key here is understanding that production environments introduce new variables (network latency, real user data) that aren't present in a controlled test environment.
12 / 41
Liam: "I'm getting a high number of requests failing with HTTP 502 Bad Gateway errors. The monitoring dashboards show increased latency, but nothing else out of the ordinary." Maya: "Okay, let's add some logging around our interaction with the external CDN to see if we can pinpoint the issue."While a 502 Bad Gateway *can* indicate CDN issues, the prompt describes increased latency without other anomalies. The key here is to isolate the problem – by adding logs around the external CDN interaction, you can gather specific details (like request headers, response codes, and timings) that will definitively show if the CDN is failing or if a different part of the system is causing the slowdown. Focusing solely on the 502 error without further investigation risks missing a more subtle root cause.
13 / 41
David comments during a code review: "I'm noticing unusually high CPU usage on the backend servers. It's not consistently high, but there are periods where it spikes significantly, particularly around 3 AM. We haven't seen this before in staging.". Which of the following is the MOST appropriate next step for investigating this issue?
David's observation highlights a critical need for detailed performance data. Rate limiting (option 2) would be premature without understanding the root cause. A granular monitoring tool that captures process-level CPU usage with timestamps is crucial for identifying patterns and correlations – this allows you to pinpoint exactly which service or process is responsible for the spikes, rather than just seeing a general 'high CPU' metric. Ignoring the issue (option 4) is dangerous as it masks potential problems.
14 / 41
Sarah: "Hey team, I'm seeing a lot of '500 Internal Server Error's in the logs for our new user onboarding flow. The metrics dashboard isn't showing anything obvious – no spikes or unusual patterns. What should we investigate first?"This question simulates a common scenario during production debugging. While restarting servers or scaling infrastructure might be considered later, the immediate priority is to gather detailed information about the errors themselves. Examining application logs for error messages and stack traces provides concrete evidence of what went wrong, allowing developers to pinpoint the root cause rather than relying on broad metrics. The incorrect options represent common missteps – blindly scaling without understanding the problem, ignoring alerts, or assuming a simple restart will fix everything.
15 / 41
Mark: "I've just submitted a pull request to update the payment processing logic. It should be fully tested in staging before deploying to production.". David replies: "Before we merge, could you include some instrumentation around the transaction ID and any external API calls? We need to be able to quickly trace these requests if they fail in production."This scenario highlights the importance of proactive instrumentation in production debugging. While staging testing is valuable, it doesn't fully replicate the complexity and potential failure points of a live system. Adding tracing mechanisms like transaction IDs allows developers to reconstruct the flow of events during an incident, bridging the gap between staging and production. The key here is understanding that production environments introduce new variables (network latency, real user data) that aren't present in a controlled test environment.
16 / 41
Liam: "I'm getting a high number of requests failing with HTTP 502 Bad Gateway errors. The monitoring dashboards show increased latency, but nothing else out of the ordinary." Maya: "Okay, let's add some logging around our interaction with the external CDN to see if we can pinpoint the issue."While a 502 Bad Gateway *can* indicate CDN issues, the prompt describes increased latency without other anomalies. The key here is to isolate the problem – by adding logs around the external CDN interaction, you can gather specific details (like request headers, response codes, and timings) that will definitively show if the CDN is failing or if a different part of the system is causing the slowdown. Focusing solely on the 502 error without further investigation risks missing a more subtle root cause.
17 / 41
David comments during a code review: "I'm noticing unusually high CPU usage on the backend servers. It's not consistently high, but there are periods where it spikes significantly, particularly around 3 AM. We haven't seen this before in staging.". Which of the following is the MOST appropriate next step for investigating this issue?
David's observation highlights a critical need for detailed performance data. Rate limiting (option 2) would be premature without understanding the root cause. A granular monitoring tool that captures process-level CPU usage with timestamps is crucial for identifying patterns and correlations – this allows you to pinpoint exactly which service or process is responsible for the spikes, rather than just seeing a general 'high CPU' metric. Ignoring the issue (option 4) is dangerous as it masks potential problems.
18 / 41
Sarah: "Hey team, I'm seeing a lot of '500 Internal Server Error's in the logs for our new user onboarding flow. The metrics dashboard isn't showing anything obvious – no spikes or unusual patterns. What should we investigate first?"This question simulates a common scenario during production debugging. While restarting servers or scaling infrastructure might be considered later, the immediate priority is to gather detailed information about the errors themselves. Examining application logs for error messages and stack traces provides concrete evidence of what went wrong, allowing developers to pinpoint the root cause rather than relying on broad metrics. The incorrect options represent common missteps – blindly scaling without understanding the problem, ignoring alerts, or assuming a simple restart will fix everything.
19 / 41
Mark: "I've just submitted a pull request to update the payment processing logic. It should be fully tested in staging before deploying to production.". David replies: "Before we merge, could you include some instrumentation around the transaction ID and any external API calls? We need to be able to quickly trace these requests if they fail in production."This scenario highlights the importance of proactive instrumentation in production debugging. While staging testing is valuable, it doesn't fully replicate the complexity and potential failure points of a live system. Adding tracing mechanisms like transaction IDs allows developers to reconstruct the flow of events during an incident, bridging the gap between staging and production. The key here is understanding that production environments introduce new variables (network latency, real user data) that aren't present in a controlled test environment.
20 / 41
Liam: "I'm getting a high number of requests failing with HTTP 502 Bad Gateway errors. The monitoring dashboards show increased latency, but nothing else out of the ordinary." Maya: "Okay, let's add some logging around our interaction with the external CDN to see if we can pinpoint the issue."While a 502 Bad Gateway *can* indicate CDN issues, the prompt describes increased latency without other anomalies. The key here is to isolate the problem – by adding logs around the external CDN interaction, you can gather specific details (like request headers, response codes, and timings) that will definitively show if the CDN is failing or if a different part of the system is causing the slowdown. Focusing solely on the 502 error without further investigation risks missing a more subtle root cause.
21 / 41
David comments during a code review: "I'm noticing unusually high CPU usage on the backend servers. It's not consistently high, but there are periods where it spikes significantly, particularly around 3 AM. We haven't seen this before in staging.". Which of the following is the MOST appropriate next step for investigating this issue?
David's observation highlights a critical need for detailed performance data. Rate limiting (option 2) would be premature without understanding the root cause. A granular monitoring tool that captures process-level CPU usage with timestamps is crucial for identifying patterns and correlations – this allows you to pinpoint exactly which service or process is responsible for the spikes, rather than just seeing a general 'high CPU' metric. Ignoring the issue (option 4) is dangerous as it masks potential problems.
22 / 41
During a code review, Alex says: "I'm seeing intermittent timeouts on the API endpoint. The logs show a high number of 'Connection Refused' errors, but the system metrics don't immediately indicate an overload." Which of the following is the most appropriate next step to investigate?
curl -v https://api.example.com/usersThe message indicates a connection problem. Deploying a fix immediately without understanding the root cause is premature. Investigating database connections or rate limits would be too broad at this stage. A full system audit would take far too long to execute - it's better to investigate more targeted areas.
23 / 41
In a Slack channel discussing a production issue, Ben writes: "The service is experiencing sporadic 503 errors. The monitoring shows CPU usage spiking around deployment times. It's not consistently high, but it's definitely noticeable." What does Ben likely mean by 'sporadic 503 errors'?
[API Response snippet with a 503 error]A 'sporadic' error indicates it doesn't happen all the time. A 503 error signifies a temporary service unavailability. The deployment-related CPU spike suggests that the issue might be related to the deployment process itself – possibly due to resource constraints or misconfiguration during updates.
24 / 41
During a standup meeting, Chloe reports: "We've been seeing an increase in '404 Not Found' errors on the new user registration flow. The analytics dashboard isn't showing any unusual traffic patterns, and there haven't been any recent code changes to that specific module." What is the most likely underlying cause?
[API Response snippet with a 404 error]The lack of unusual traffic patterns suggests it's not a simple surge. '404 Not Found' errors often stem from incorrect URL generation or routing issues on the frontend. Misconfiguration would likely cause other types of errors (e.g., 500). Malicious traffic is less probable given the absence of any indication of an attack.
25 / 41
David writes in a PR description: "This change implements improved error handling for failed database queries. We're logging all errors with detailed context to help with debugging." What is the primary benefit of 'detailed context' in this logging?
[CLI command example]Detailed context is crucial for debugging production issues. Simply logging a generic 'Database Query Failed' message isn't helpful without knowing *which* query failed, under what circumstances (user, request), and with what data. This information dramatically reduces the time needed to diagnose and fix the problem.
26 / 41
Liam says: "The service is experiencing high latency during peak hours. The monitoring dashboard shows CPU utilization consistently above 80%, but it's stable. There are no obvious bottlenecks." What does Liam likely mean by 'stable'?
[Graph showing consistent CPU usage]'Stable' in this context means that the CPU utilization isn't dramatically increasing or decreasing. While 80% might be high, if it's consistently stable, it suggests a predictable load rather than a sudden spike causing latency. It doesn't necessarily mean the system is *efficient*, just that the resource usage is consistent.
27 / 41
During a code review, Alex says: "I'm seeing intermittent timeouts on the API endpoint. The logs show a high number of 'Connection Refused' errors, but the system metrics don't immediately indicate an overload." Which of the following is the most appropriate next step to investigate?
curl -v https://api.example.com/usersThe message indicates a connection problem. Deploying a fix immediately without understanding the root cause is premature. Investigating database connections or rate limits would be too broad at this stage. A full system audit would take far too long to execute - it's better to investigate more targeted areas.
28 / 41
In a Slack channel discussing a production issue, Ben writes: "The service is experiencing sporadic 503 errors. The monitoring shows CPU usage spiking around deployment times. It's not consistently high, but it's definitely noticeable." What does Ben likely mean by 'sporadic 503 errors'?
[API Response snippet with a 503 error]A 'sporadic' error indicates it doesn't happen all the time. A 503 error signifies a temporary service unavailability. The deployment-related CPU spike suggests that the issue might be related to the deployment process itself – possibly due to resource constraints or misconfiguration during updates.
29 / 41
During a standup meeting, Chloe reports: "We've been seeing an increase in '404 Not Found' errors on the new user registration flow. The analytics dashboard isn't showing any unusual traffic patterns, and there haven't been any recent code changes to that specific module." What is the most likely underlying cause?
[API Response snippet with a 404 error]The lack of unusual traffic patterns suggests it's not a simple surge. '404 Not Found' errors often stem from incorrect URL generation or routing issues on the frontend. Misconfiguration would likely cause other types of errors (e.g., 500). Malicious traffic is less probable given the absence of any indication of an attack.
30 / 41
David writes in a PR description: "This change implements improved error handling for failed database queries. We're logging all errors with detailed context to help with debugging." What is the primary benefit of 'detailed context' in this logging?
[CLI command example]Detailed context is crucial for debugging production issues. Simply logging a generic 'Database Query Failed' message isn't helpful without knowing *which* query failed, under what circumstances (user, request), and with what data. This information dramatically reduces the time needed to diagnose and fix the problem.
31 / 41
Liam says: "The service is experiencing high latency during peak hours. The monitoring dashboard shows CPU utilization consistently above 80%, but it's stable. There are no obvious bottlenecks." What does Liam likely mean by 'stable'?
[Graph showing consistent CPU usage]'Stable' in this context means that the CPU utilization isn't dramatically increasing or decreasing. While 80% might be high, if it's consistently stable, it suggests a predictable load rather than a sudden spike causing latency. It doesn't necessarily mean the system is *efficient*, just that the resource usage is consistent.
32 / 41
During a code review, Alex says: "I'm seeing intermittent timeouts on the API endpoint. The logs show a high number of 'Connection Refused' errors, but the system metrics don't immediately indicate an overload." Which of the following is the most appropriate next step to investigate?
curl -v https://api.example.com/usersThe message indicates a connection problem. Deploying a fix immediately without understanding the root cause is premature. Investigating database connections or rate limits would be too broad at this stage. A full system audit would take far too long to execute - it's better to investigate more targeted areas.
33 / 41
In a Slack channel discussing a production issue, Ben writes: "The service is experiencing sporadic 503 errors. The monitoring shows CPU usage spiking around deployment times. It's not consistently high, but it's definitely noticeable." What does Ben likely mean by 'sporadic 503 errors'?
[API Response snippet with a 503 error]A 'sporadic' error indicates it doesn't happen all the time. A 503 error signifies a temporary service unavailability. The deployment-related CPU spike suggests that the issue might be related to the deployment process itself – possibly due to resource constraints or misconfiguration during updates.
34 / 41
During a standup meeting, Chloe reports: "We've been seeing an increase in '404 Not Found' errors on the new user registration flow. The analytics dashboard isn't showing any unusual traffic patterns, and there haven't been any recent code changes to that specific module." What is the most likely underlying cause?
[API Response snippet with a 404 error]The lack of unusual traffic patterns suggests it's not a simple surge. '404 Not Found' errors often stem from incorrect URL generation or routing issues on the frontend. Misconfiguration would likely cause other types of errors (e.g., 500). Malicious traffic is less probable given the absence of any indication of an attack.
35 / 41
David writes in a PR description: "This change implements improved error handling for failed database queries. We're logging all errors with detailed context to help with debugging." What is the primary benefit of 'detailed context' in this logging?
[CLI command example]Detailed context is crucial for debugging production issues. Simply logging a generic 'Database Query Failed' message isn't helpful without knowing *which* query failed, under what circumstances (user, request), and with what data. This information dramatically reduces the time needed to diagnose and fix the problem.
36 / 41
Liam says: "The service is experiencing high latency during peak hours. The monitoring dashboard shows CPU utilization consistently above 80%, but it's stable. There are no obvious bottlenecks." What does Liam likely mean by 'stable'?
[Graph showing consistent CPU usage]'Stable' in this context means that the CPU utilization isn't dramatically increasing or decreasing. While 80% might be high, if it's consistently stable, it suggests a predictable load rather than a sudden spike causing latency. It doesn't necessarily mean the system is *efficient*, just that the resource usage is consistent.
37 / 41
During a code review, Alex says: "I'm seeing intermittent timeouts on the API endpoint. The logs show a high number of 'Connection Refused' errors, but the system metrics don't immediately indicate an overload." Which of the following is the most appropriate next step to investigate?
curl -v https://api.example.com/usersThe message indicates a connection problem. Deploying a fix immediately without understanding the root cause is premature. Investigating database connections or rate limits would be too broad at this stage. A full system audit would take far too long to execute - it's better to investigate more targeted areas.
38 / 41
In a Slack channel discussing a production issue, Ben writes: "The service is experiencing sporadic 503 errors. The monitoring shows CPU usage spiking around deployment times. It's not consistently high, but it's definitely noticeable." What does Ben likely mean by 'sporadic 503 errors'?
[API Response snippet with a 503 error]A 'sporadic' error indicates it doesn't happen all the time. A 503 error signifies a temporary service unavailability. The deployment-related CPU spike suggests that the issue might be related to the deployment process itself – possibly due to resource constraints or misconfiguration during updates.
39 / 41
During a standup meeting, Chloe reports: "We've been seeing an increase in '404 Not Found' errors on the new user registration flow. The analytics dashboard isn't showing any unusual traffic patterns, and there haven't been any recent code changes to that specific module." What is the most likely underlying cause?
[API Response snippet with a 404 error]The lack of unusual traffic patterns suggests it's not a simple surge. '404 Not Found' errors often stem from incorrect URL generation or routing issues on the frontend. Misconfiguration would likely cause other types of errors (e.g., 500). Malicious traffic is less probable given the absence of any indication of an attack.
40 / 41
David writes in a PR description: "This change implements improved error handling for failed database queries. We're logging all errors with detailed context to help with debugging." What is the primary benefit of 'detailed context' in this logging?
[CLI command example]Detailed context is crucial for debugging production issues. Simply logging a generic 'Database Query Failed' message isn't helpful without knowing *which* query failed, under what circumstances (user, request), and with what data. This information dramatically reduces the time needed to diagnose and fix the problem.
41 / 41
Liam says: "The service is experiencing high latency during peak hours. The monitoring dashboard shows CPU utilization consistently above 80%, but it's stable. There are no obvious bottlenecks." What does Liam likely mean by 'stable'?
[Graph showing consistent CPU usage]'Stable' in this context means that the CPU utilization isn't dramatically increasing or decreasing. While 80% might be high, if it's consistently stable, it suggests a predictable load rather than a sudden spike causing latency. It doesn't necessarily mean the system is *efficient*, just that the resource usage is consistent.
Frequently Asked Questions
What does the "Production Debugging Vocabulary" exercise practise?
Practice production debugging vocabulary: distributed tracing, non-intrusive profiling, audit log reconstruction, canary diagnostics, and remote debugging constraints.
How many questions are in this exercise?
This exercise has 41 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Debugging Language category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Production Debugging Vocabulary" part of a larger series?
Yes — it's one exercise in the Debugging Language category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Debugging Language category page for related exercises, or browse the main Exercises hub for other IT English topics.