Question 81 of 1,420
mediumMultiple ChoiceObjective-mapped
IP SLA HTTP Operation: Troubleshooting Status Codes and Failure Detection
A network engineer configures IP SLA 1 to monitor HTTP server availability at 10.1.1.1 using HTTP GET. The operation is used as a track object for a backup static route. The engineer notices that the IP SLA operation shows 'State: Active' and 'Latest RTT: 200 ms', but the track object shows 'Track 1: up' even though the HTTP server returns a 404 error. What is the cause?
Quick Answer
The answer is that by default, an IP SLA HTTP operation only verifies TCP connectivity, not the actual HTTP status code. This is the root cause of the issue because the IP SLA establishes a successful TCP handshake with the server at 10.1.1.1, which satisfies the operation’s default success criteria, regardless of the HTTP 404 response. On the ENCOR 350-401 exam, this scenario tests your understanding that IP SLA HTTP operations treat any HTTP response as a success unless you explicitly configure a status code match using the `expect` option. A common trap is assuming a 404 error will cause the operation to fail, but the track object remains “up” because the TCP connection itself is healthy. To remember this, think: “IP SLA HTTP checks the pipe, not the payload.”
⚠ Common exam trap
Cisco often tests the misconception that IP SLA HTTP operations automatically validate HTTP response codes, when in fact they only verify TCP connectivity unless explicitly configured with 'expect' statements.
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
✓
The IP SLA HTTP operation does not interpret HTTP status codes by default; it only checks if a TCP connection is established.
The IP SLA HTTP operation, by default, only verifies that a TCP three-way handshake completes with the destination host on port 80 (or the configured port). It does not parse or evaluate the HTTP response status code (e.g., 404). Therefore, even though the server returns a 404 error, the TCP connection succeeds, the operation shows 'Active', and the track object remains 'up'. To detect a 404, you must use the 'http-get' operation with a specific URL and enable status code checking via the 'expect' option.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The IP SLA HTTP operation must be configured with a 'url' that includes the full path, otherwise it defaults to the root and returns 404.
Why it's wrong here
Incorrect because the 404 is returned, but the operation still succeeds; the issue is that the operation does not treat 404 as a failure.
- ✓
The IP SLA HTTP operation does not interpret HTTP status codes by default; it only checks if a TCP connection is established.
Why this is correct
Correct. IP SLA HTTP probe by default only verifies that the TCP handshake succeeds and a response is received. It does not parse the HTTP status code unless a 'status-code' match is configured.
- ✗
The track object must be configured with a 'down' threshold to trigger when the HTTP response time exceeds a value.
Why it's wrong here
Incorrect because the track object is already up; the issue is that the operation does not consider the 404 as a failure, not that the response time is too high.
- ✗
The HTTP server is responding, so the IP SLA operation correctly shows success; the engineer must use a different type of probe, like TCP connect, to detect the 404.
Why it's wrong here
Incorrect because the HTTP probe can be configured to match specific status codes; it is not necessary to use a different probe type.
Visual reference
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on 350-401
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Drag and drop the steps of IP SLA HTTP operation for application monitoring into the correct order, from first to last.
medium- ✓ A.Create IP SLA HTTP operation with URL
- ✓ B.Set HTTP method (GET/POST) and version
- ✓ C.Configure HTTP response code monitoring
- ✓ D.Schedule IP SLA operation
- ✓ E.Verify operation with show ip sla statistics
Why A: First, the HTTP operation is defined with the target URL. Then optional parameters like HTTP method or version are set. The operation is configured to monitor HTTP response. Next, the operation is scheduled. Finally, verification is done to confirm the operation is active.
Variation 2. Drag and drop the steps of IP SLA HTTP operation for application monitoring into the correct order, from first to last.
medium- ✓ A.Create IP SLA operation with type http
- ✓ B.Specify target URL and HTTP method
- ✓ C.Configure optional HTTP parameters
- ✓ D.Schedule the IP SLA operation
- ✓ E.Verify HTTP response and latency
Why A: Start by creating the IP SLA operation with HTTP type. Then specify the target URL and HTTP method (e.g., GET). Optionally configure HTTP version and other parameters. Next, schedule the operation to run. Finally, verify the HTTP response times and status.
Last reviewed: Jul 4, 2026
This 350-401 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 350-401 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.