A network engineer's Python script posts a device template to SD-WAN Manager and the call fails with HTTP 400. The script prints only 'request failed', while the JSON response body names the exact field the manager rejected. The engineer needs to find that rejected value, and a retry of this request would return the identical failure. Which part of the error response should the script parse to identify the rejected field?
Select an answer to reveal the explanation.
Short Explanation
You can use the status code to understand the kind of failure, but the JSON error body is where the manager names the exact field it rejected. Since the same request will fail again unchanged, you can use that field detail to find what to fix before retrying.
Full Explanation
Parse the response body as structured JSON and interpret it alongside the HTTP status code. The 400 indicates a client-side rejection, and the JSON body names the rejected field, letting you map the manager’s diagnosis to the corresponding template input. Validating the template against the manager’s published schema can catch mistakes before submission, but reporting a local constraint violation does not extract the field the manager rejected in this response; schema versions or validation rules may also differ. Capturing response headers and using a request ID to search manager logs can help when the response lacks useful detail, but it bypasses the precise field information already present in the JSON body. Parsing the JSON error code and category can classify the 400 as a non-retryable validation failure, but those details alone do not identify the rejected field, and omitting the body’s field-level detail misses the needed answer. Exam caveat: HTTP 400 generally signals a client-side request problem, but the status code alone cannot show which input failed; the response format and API contract determine where that detail appears. Practical check: log the status, safely parse the response body, confirm that the named field exists in the submitted template, and avoid retrying unchanged input when it is known to produce the same failure.