3.1 Operational Excellence

Official task mapping

SAP-C02 task 3.1: Telemetry and deployment knowledge; operational automation and recovery exercises. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.

Prerequisites

Review Systems Manager, CloudTrail and deployment strategies. Be able to explain the relevant failure boundary and access/cost model before choosing a service.

Make operations observable

Define service-level indicators for user outcomes, then correlate metrics, logs and traces with deployment/change records. CloudWatch dashboards are not a substitute for actionable alarms. OpenTelemetry/ADOT can standardize instrumentation; cross-account observability needs deliberate permissions and data scope.

X-Ray annotations support indexed search; metadata carries additional context without the same indexing. Avoid secrets and unnecessary personal data in either. Track telemetry retention and sampling costs.

Systems Manager supports configuration, patching, automation and sessions for managed nodes. Session Manager can record supported session content, but SSH and port-forwarding sessions cannot provide content logging through the encrypted tunnel. CloudTrail API activity is not a transcript of commands inside that tunnel. Design audit requirements before choosing the connection mode.

Observability and fleet-operation reference

CapabilityEvidenceOperational use
CloudWatch LogsStructured application/service recordsDiagnose events with correlation IDs and retention
MetricsTime-series operational measurementsTrack SLOs, capacity and bottlenecks
Alarms/composite alarmsThreshold/evaluation stateNotify or apply bounded supported responses
Contributor InsightsSupported contributor patternsFind dominant sources from configured data
EventBridgeSupported events and routingTrigger workflows, with source delivery semantics
TracesInstrumented request spansLocate cross-service latency and errors

EventBridge is separate from a metrics/logs dashboard; not every source event is an immediate guaranteed stream. X-Ray/OTel tracing needs instrumentation, propagation and sampling; it does not automatically reconstruct every request from logs.

Run Command performs authorized node commands; State Manager applies associations; Automation executes runbooks; Patch Manager manages supported patch workflows. Establish managed-node access, network endpoints, execution roles and maintenance windows before choosing a tool. OpsCenter can organize OpsItems but is not an automatic root-cause engine.

A useful incident record links alarm, trace, deployment, affected resources and runbook outcome. Repeated notifications without an owner or acceptance criteria are noise. Add an operations drill that checks both recovery and what evidence remains when a node is replaced.

Scenario and rationale

A release produces intermittent checkout failures, but the team only has instance CPU alarms. Add request error/latency and business-outcome metrics, correlated traces and structured logs containing deployment identifiers. Use a runbook with explicit investigation and rollback gates, followed by a post-incident review.

Reject more CPU alarms as the entire fix: dependency failures can occur while CPU is normal. Reject auto-restarting every instance whenever latency rises: it can erase evidence and amplify the incident. Prefer bounded automation for a diagnosed, reversible failure.

Practice drill

Given a timeline of a deployment, queue-age increase and downstream timeout, reconstruct the probable dependency sequence. Write one user-impact alarm, one diagnostic query and one runbook with owner/approval/rollback. Specify retention, sensitive-data handling and what cannot be audited in an SSH tunnel. Tabletop a failed rollback before proposing a sandbox exercise.

References

Return to Domain 3. The drill is proposed study work, not a claim of a completed deployment.