Housing-authority automation must send a waitlist status update to an HTTP API and also keep human-editable runtime settings for batch size and retry count. Which representation pairing is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
You want the API to receive a JSON payload, while operators can adjust batch size and retry count in readable YAML. That pairing keeps the machine-facing update structured and the runtime settings easy for you to edit.
Full Explanation
Housing-authority automation needs a machine-readable API request and settings that operators can edit, so use a structured JSON payload for the waitlist update and a YAML configuration file for batch size and retry count. JSON is a conventional HTTP API request format, with structured fields and broad library support; YAML is readable, supports comments, and is convenient for operator-tuned values. Keeping the request and runtime settings in these separate formats distinguishes interchange from configuration. A Word document containing free-form text is unsuitable because an HTTP client cannot reliably parse manually edited values, and formatting changes can cause drift. JPEG screenshots of the admin console are images, not safely machine-readable settings, and make accessibility and versioning harder. CSV rows can represent tabular data, but using CSV exclusively and never JSON is a poor fit for a structured waitlist status request and ignores common API expectations. Exam caveat: follow the API’s published contract if it specifies a different request format; the pairing here is appropriate for the stated scenario. Practical check: load the YAML into a test job, send a sample JSON update to a non-production endpoint, and verify that changing batch size or retry count in YAML changes the job’s behavior. Keep secrets out of plaintext configuration except as permitted by approved secret-management practices.