Supporting Applications and Developers
Supporting Applications and Developers tests the interface between operations and software teams: how applications are configured, observed, and debugged, and how to help developers without weakening production controls.
Configuration and environments
Applications read configuration from files, command-line flags, or environment variables. Separate environments, development, staging, and production, should use the same build artifact with different configuration. Secrets belong in a secret manager or injected environment, not committed to Git. A useful support request includes the environment, timestamp, request identifier, and exact error, because those details let you find the right log line.
Logs, APIs, and debugging
Application logs usually go to stdout and stderr in containers, where the platform collects them; on a host they may be under /var/log or the journal. kubectl logs reads a container's logs, and kubectl describe pod shows scheduling and restart events. HTTP status codes narrow the fault: 4xx is usually the caller's request, 5xx the server or dependency. Check DNS resolution, credentials, and dependency health before changing code.
Access and change control
Give developers read access to logs and metrics in non-production freely; in production, prefer scoped, audited, time-bound access. Reproduce in staging, then fix forward through the pipeline.
Worked example: a developer reports intermittent 502 errors from an API. 502 means a gateway could not get a valid response from upstream. Check the upstream service's health, restart count, and logs at the reported timestamps before touching the gateway; if the upstream is crash-looping, the gateway is a symptom.
Traps: giving production credentials to unblock a debug session; treating every 500 as an application bug when a dependency or expired certificate is the cause; and changing production configuration manually, which creates drift and hides the fix from review.