Service delivery contract
Outcome: create a release evidence card that names source SHA, artifact digest, environment, approval, customer-facing success signal, rollback revision, and the owner who can authorize the change. Practice a supplied release record before independently finding one missing boundary.
- •Start with an observable fact, then state what it does and does not establish.
- •Use a bounded, read-only exercise before recommending an authorized, reversible action.
- •Record the owner, decision boundary, and next update or escalation condition.
Artifact traceability
Trace a supplied deployment image reference to a digest, build record, lockfile, and source revision. A digest supports content identity; it does not prove the deployment, scan, or policy record unless those records are reconciled.
- •Start with an observable fact, then state what it does and does not establish.
- •Use a bounded, read-only exercise before recommending an authorized, reversible action.
- •Record the owner, decision boundary, and next update or escalation condition.
IaC review and state safety
Review a fixture plan for replacement, deletion, drift, unknown values, state ownership, and recovery constraints. Do not apply or edit state. Write a review comment that requests the missing owner, backup evidence, or approved recovery path.
- •Start with an observable fact, then state what it does and does not establish.
- •Use a bounded, read-only exercise before recommending an authorized, reversible action.
- •Record the owner, decision boundary, and next update or escalation condition.
Kubernetes workload and traffic model
Explain the path from Deployment to ReplicaSet to Pod, Service selector, EndpointSlice, readiness, and request. Work from supplied output so an absent endpoint is a diagnosis exercise, not a reason to restart a workload.
- •Start with an observable fact, then state what it does and does not establish.
- •Use a bounded, read-only exercise before recommending an authorized, reversible action.
- •Record the owner, decision boundary, and next update or escalation condition.
Kubernetes evidence-led diagnosis
Separate Pending, CrashLoop, startup, and zero-ready-endpoint failures. For each, choose one read-only observation, write what it proves and does not prove, and name the platform or service owner to involve.
- •Start with an observable fact, then state what it does and does not establish.
- •Use a bounded, read-only exercise before recommending an authorized, reversible action.
- •Record the owner, decision boundary, and next update or escalation condition.
Service signals and release evidence
Use a supplied request sample and deployment marker to decide whether a rollout correlates with customer harm. A green controller or CPU graph is not proof that the user journey works.
- •Start with an observable fact, then state what it does and does not establish.
- •Use a bounded, read-only exercise before recommending an authorized, reversible action.
- •Record the owner, decision boundary, and next update or escalation condition.
Rollouts, traffic, and rollback
Compare rollout, EndpointSlice, target-health, and user-signal evidence. Recommend halt, rollback, or escalation through the existing change boundary rather than making an unapproved production change.
- •Start with an observable fact, then state what it does and does not establish.
- •Use a bounded, read-only exercise before recommending an authorized, reversible action.
- •Record the owner, decision boundary, and next update or escalation condition.
Operational security and access boundaries
Follow a sanitized credential-exposure exercise: preserve evidence, notify the credential owner, revoke or rotate through the approved process, scope downstream copies, and add a prevention control. Deleting a log line is not containment.
- •Start with an observable fact, then state what it does and does not establish.
- •Use a bounded, read-only exercise before recommending an authorized, reversible action.
- •Record the owner, decision boundary, and next update or escalation condition.
Incident participation and follow-through
As an assigned technical responder, post impact, scope, knowns, unknowns, evidence, mitigation proposal, owner, and next update time. Verify recovery with a user signal and file one owned runbook or follow-up improvement.
- •Start with an observable fact, then state what it does and does not establish.
- •Use a bounded, read-only exercise before recommending an authorized, reversible action.
- •Record the owner, decision boundary, and next update or escalation condition.