hardMultiple Select

200-901 Practice Question: Which TWO of the following are valid ways to…

Which TWO of the following are valid ways to handle errors in a Python program that uses the Cisco Meraki API?

⚠ Common exam trap

Cisco often tests the distinction between handling errors via HTTP status codes versus parsing the response body for API-specific error fields, and the trap here is that candidates may think catching a generic Exception is sufficient, but the exam expects specific, layered error handling that respects both the HTTP protocol and the API's documented response format.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Checking the response body for an 'errors' key and handling accordingly

Option A is correct because the Cisco Meraki API returns structured JSON error payloads that include an 'errors' key (for example, {"errors":["Invalid API key"]}), so inspecting the response body for that key lets the program detect and handle API-level failures even when the HTTP status alone is ambiguous. Option B is correct because the Meraki API uses standard HTTP status codes, returning 4xx for client errors such as 400 Bad Request, 401 Unauthorized, 404 Not Found, and 429 Too Many Requests, and 5xx for server errors, so checking the status code and raising an exception for those ranges is a reliable, idiomatic error-handling pattern. Option C is wrong because assuming a 200 response and logging success ignores real failure conditions like 401, 404, or 429 and would silently mask errors. Option D is wrong because retrying indefinitely can hammer the API, trigger rate limiting (429) or account suspension, and never terminate; retries should be bounded and ideally use exponential backoff. Option E is wrong because catching a generic Exception is overly broad and can swallow unrelated bugs such as TypeError or KeyError, rather than handling specific HTTP or API errors precisely.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Checking the response body for an 'errors' key and handling accordingly
Why this is correct
The Meraki API returns structured JSON error payloads, so inspecting the response body for an 'errors' key lets the program read the specific failure reason and branch accordingly, satisfying the requirement to handle API-level errors rather than only transport failures.
✓
Checking the HTTP status code and raising an exception for 4xx and 5xx
Why this is correct
HTTP status codes signal request outcomes; catching 4xx client errors and 5xx server errors via exceptions gives a uniform, transport-level handling path, satisfying the requirement to detect failures returned by the Meraki API before parsing any payload.
✗
Assuming the API always returns 200 and logging success
Why it's wrong here
Assuming a 200 response and logging success performs no error detection at all, so failures pass silently. It is tempting because Meraki returns JSON with HTTP status codes, but this suits only a script where every call is known to succeed.
✗
Retrying the request indefinitely until success
Why it's wrong here
Retrying indefinitely never terminates on persistent errors such as 400 or 401, exhausting the client and hammering the API. It is tempting because Meraki enforces rate limits with 429 responses, where bounded retries with backoff are the correct handling.
✗
Using a try-except block around the API call and catching generic Exception
Why it's wrong here
Catching generic Exception hides unexpected errors and is not recommended.

Go deeper

200-901 Practice Question: Which TWO of the following are valid ways to…

Why each option matters

Option-by-option breakdown

Related to this question