Supporting Applications and Developers
Supporting Applications and Developers tests the bridge between operations and software teams: runtimes, configuration, APIs, data services, logs, documentation, and reproducible troubleshooting.
Runtimes, dependencies, and configuration
Applications depend on language runtimes, libraries, environment variables, ports, and backing services. Pin dependency versions and build reproducible images. Keep configuration outside code so the same artifact runs in staging and production. Validate that the process listens on the expected interface and port, and that file permissions match its service account. Database changes should run as versioned migrations, not manual edits.
APIs, logs, and support workflow
HTTP APIs use methods such as GET, POST, PUT, and DELETE; status codes distinguish client errors (4xx) from server errors (5xx). JSON is common. Authentication uses tokens or keys. When a developer reports a failure, collect the request ID, timestamp, endpoint, payload shape, expected versus actual result, and relevant logs. Read application logs before changing infrastructure. Record the fix and update documentation or the ticket.
Worked example
A developer says an API returns 500 only in staging. Reproduce with the same endpoint and token, then correlate the request ID in logs. The stack trace shows a database connection refused. Compare configuration: staging's DATABASE_URL points to the old host, and the new database requires TLS. Update the staging secret, run the pending migration, restart the app, and retest. The reasoning follows the request path-client, API, configuration, network, database-instead of changing code first.
Traps
Do not debug production by editing files directly. Do not paste secrets or full tokens into tickets or logs. A 401 is authentication, not a server crash; a 403 is authorization. Assuming code is wrong before checking configuration, DNS, certificates, or migrations wastes time. Undocumented manual changes make the next incident harder.