📖 Scenario: You work as a DevOps engineer responsible for keeping an important web API running smoothly. Your team wants to monitor the API's response times and get alerts if it becomes slow.Imagine you have a simple script that checks the API response time and alerts if it is too high.
🎯 Goal: Build a simple API monitoring script that stores response times, sets a threshold for slow responses, checks the response times against the threshold, and prints alerts for slow responses.
📋 What You'll Learn
Create a list of API response times in milliseconds
Add a threshold variable for slow response time
Write a loop to find response times above the threshold
Print alerts for each slow response time
💡 Why This Matters
🌍 Real World
Monitoring API response times helps keep web services reliable and fast for users.
💼 Career
DevOps engineers often write scripts like this to automate monitoring and alerting for system health.
Progress0 / 4 steps
1
Create a list of API response times
Create a list called response_times with these exact values: 120, 250, 180, 300, 90
Rest API
Hint
Use square brackets to create a list and separate numbers with commas.
2
Set a threshold for slow response time
Create a variable called threshold and set it to 200 to represent the maximum acceptable response time in milliseconds.
Rest API
Hint
Use a simple assignment statement to create the variable.
3
Find slow response times
Use a for loop with the variable time to iterate over response_times. Inside the loop, use an if statement to check if time is greater than threshold. If yes, add time to a new list called slow_responses.
Rest API
Hint
Remember to create the empty list slow_responses before the loop.
4
Print alerts for slow responses
Use a for loop with the variable slow_time to iterate over slow_responses. Inside the loop, print the message: "Alert: Slow response time detected - X ms" where X is the value of slow_time.
Rest API
Hint
Use an f-string inside the print statement to include the variable value.
Practice
(1/5)
1. What is the main purpose of API monitoring in DevOps?
easy
A. To design the API user interface
B. To write new API endpoints
C. To regularly check if the API is working correctly
D. To store API data permanently
Solution
Step 1: Understand API monitoring
API monitoring means checking the API often to see if it works well without errors.
Step 2: Identify the main goal
The main goal is to ensure the API is available and responds correctly to requests.
Final Answer:
To regularly check if the API is working correctly -> Option C
Quick Check:
API monitoring = regular checks [OK]
Hint: Monitoring means checking often if API works [OK]
Common Mistakes:
Confusing monitoring with API design
Thinking monitoring stores data
Mixing monitoring with coding new endpoints
2. Which of the following is the correct way to set up an alert for API downtime in a monitoring tool?
easy
A. Trigger alert if API response time is less than 100ms
B. Trigger alert if API documentation changes
C. Trigger alert if API returns status code 200
D. Trigger alert if API returns status code 500 or no response
Solution
Step 1: Understand alert conditions for downtime
An alert for downtime should trigger when the API fails or does not respond, such as status code 500 or no response.
Step 2: Evaluate options
Trigger alert if API returns status code 500 or no response correctly triggers alert on error or no response. Other options either alert on success or unrelated events.
Final Answer:
Trigger alert if API returns status code 500 or no response -> Option D
Quick Check:
Alert on errors or no response = Trigger alert if API returns status code 500 or no response [OK]
Hint: Alert on errors or no response, not success [OK]
Common Mistakes:
Alerting on successful responses
Alerting on unrelated changes like docs
Using wrong status codes for alerts
3. Given this monitoring script snippet:
response = requests.get('https://api.example.com/data')
if response.status_code != 200:
send_alert('API error detected')
What happens if the API returns status code 404?
medium
A. No alert is sent
B. An alert is sent with message 'API error detected'
C. The script crashes with an error
D. The script retries the request automatically
Solution
Step 1: Analyze the condition in the script
The script sends an alert if the status code is not 200.
Step 2: Check the status code 404
Since 404 is not 200, the condition is true and alert is sent.
Final Answer:
An alert is sent with message 'API error detected' -> Option B
Quick Check:
Status code 404 triggers alert [OK]
Hint: Alert triggers if status code not 200 [OK]
Common Mistakes:
Thinking 404 is success
Assuming script crashes on 404
Believing script retries automatically
4. You wrote this alert rule:
if response.status_code = 500:
send_alert('Server error')
Why does this rule not work as expected?
medium
A. The comparison operator should be '==' not '='
B. The status code 500 is not an error
C. send_alert function is missing parentheses
D. The API URL is missing
Solution
Step 1: Identify the operator used
The code uses '=' which is assignment, not comparison.
Step 2: Correct operator for comparison
To compare values, '==' must be used instead of '='.
Final Answer:
The comparison operator should be '==' not '=' -> Option A
Quick Check:
Use '==' for comparison [OK]
Hint: Use '==' to compare values, '=' assigns [OK]
Common Mistakes:
Using '=' instead of '==' in conditions
Thinking 500 is not an error
Ignoring syntax errors in conditions
5. You want to monitor an API that sometimes returns status 429 (too many requests) temporarily. Which alerting strategy best avoids false alarms?
hard
A. Alert only if 429 responses occur continuously for 5 minutes
B. Alert immediately on any 429 response
C. Ignore 429 responses completely
D. Alert only if 429 responses are followed by 200 responses
Solution
Step 1: Understand 429 status meaning
Status 429 means too many requests temporarily; it may resolve quickly.
Step 2: Choose alerting strategy to avoid false alarms
Alerting immediately on one 429 may cause false alarms; waiting for continuous 429s for 5 minutes reduces noise.
Final Answer:
Alert only if 429 responses occur continuously for 5 minutes -> Option A
Quick Check:
Delay alerts on temporary errors to reduce false alarms [OK]
Hint: Wait before alerting on temporary errors [OK]
Common Mistakes:
Alerting immediately on every 429
Ignoring 429 which may hide real issues
Alerting on 429 followed by success
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.