Lesson 370 · AWS Learning Path

AWS 370: Build, test, approve, deploy, observe, and roll back an application

Anil Jalela · Published Jun 30, 2026 · 5 min read

Why this lesson matters

This capstone joins source, build, test, approval, immutable artifacts, progressive deployment, observation, rollback, audit, and cleanup into one traceable release. The goal is not a green pipeline icon. It is proof that one reviewed revision produced one verified artifact, reached the intended target safely, and could recover without hiding damage.

Lab safety and architecture

Use only an owner-approved sandbox account and Region, never production. Set a budget alert and four-hour teardown timer. The complete evidence-only track uses supplied execution records and costs nothing. A live implementation may use CodePipeline, CodeConnections or another approved source, CodeBuild, an encrypted S3 artifact store, CodeDeploy or a native target deployment, CloudWatch, EventBridge/SNS, CloudTrail, and KMS.

The pipeline service role orchestrates only required actions. Each action role is scoped to its resources. The build role must not be an administrator; the deployment role should not modify source. Encrypt the artifact bucket with a KMS key whose policy allows the exact pipeline/action principals. Block public access, version artifacts as required, log access, and define retention.

Build once and promote

Capture the commit ID before build. Pin the build image or record its digest, lock dependencies, isolate untrusted pull-request builds, and avoid printing secrets. Run formatting/lint, unit tests, integration or contract tests, dependency and secret scanning, infrastructure policy checks, and artifact malware/image scanning as applicable.

Package once. Calculate SHA-256, generate SBOM/provenance, and promote the identical object or image digest between stages. Rebuilding after approval creates a different artifact even from the same source. Record source ID, artifact digest, build ID, configuration version, target revision, and pipeline execution ID as one release manifest.

A manual approval is a risk control only when the approver can see useful evidence and is independent under the organization policy. Include change summary, test links, artifact digest, risk, deployment method, alarm dashboard, rollback criteria, expiry, and accountable owner. Never place secrets in approval text or notification links.

Deploy, observe, and recover

Choose one target already learned: Lambda alias, ECS blue-green, or EC2 Auto Scaling refresh. Define canary/linear increments, observation intervals, target-specific health, user synthetic transaction, alarms, timeout, and automatic rollback. Entry conditions can stop deployment when the environment is already unhealthy; success conditions can evaluate post-deployment health. Confirm current feature support for the pipeline and action type.

Rollback must identify a known-good immutable artifact and compatible configuration. Keep previous artifacts available and test their permissions and capacity. Traffic or code rollback does not reverse state, so use backward-compatible data changes, idempotency, and compensating procedures. Prefer a forward fix when old code cannot safely read new state.

Observe release-scoped error rate, latency percentiles, saturation/throttles, target health, queue age, dependency outcomes, and a business SLI. Define alarm missing-data behavior. A pipeline can report success before delayed failures appear, so bake time must cover the known detection window.

Live execution procedure

1. Record caller, account alias, Region, budget, tags, start time, and teardown deadline.
2. Validate source review and commit; store expected commit ID.
3. Start one execution with a unique client token. Do not restart blindly.
4. Inspect build logs and reports; match the output digest to the release manifest.
5. Verify automated gates and artifact encryption before approval.
6. Approve only the exact execution after reviewing evidence and rollback readiness.
7. Watch deployment events, target health, alarms, and synthetic user result through bake time.
8. Release a controlled harmless defect that triggers the chosen alarm.
9. Prove rollback using alias/task/image identity and restored user SLI, not status alone.
10. Export redacted evidence and perform dependency-ordered cleanup.

Useful inspection commands:

git rev-parse HEAD
aws codepipeline get-pipeline --name PIPELINE --region ap-south-1
aws codepipeline get-pipeline-state --name PIPELINE --region ap-south-1
aws codepipeline list-pipeline-executions --pipeline-name PIPELINE --max-results 10 --region ap-south-1
aws codebuild batch-get-builds --ids BUILD_ID --region ap-south-1
aws cloudwatch describe-alarms --alarm-names ALARM --region ap-south-1
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=PutApprovalResult --region ap-south-1

Treat CLI state as control-plane evidence. Correlate timestamps and IDs with target runtime and user evidence. Redact account IDs, ARNs, repository URLs, artifact locations, approver identity, logs, and parameters.

Failure matrix

Exercise at least sixteen cases: wrong branch, superseded execution, source permission, dependency tampering, test failure, scanner threshold, missing report, build timeout, KMS deny, artifact mutation, expired/rejected approval, self-approval policy violation, deployment-role deny, target capacity shortage, false health check, alarm missing data, controlled application regression, rollback artifact unavailable, incompatible database state, and cleanup dependency.

For each record detection stage, stop behavior, artifact identity, customer exposure, event/log/alarm evidence, recovery owner, recovery time, and prevention. Never weaken a gate merely to make the pipeline green.

Cost and cleanup

Estimate pipeline executions, build minutes/compute, artifact storage and requests, KMS calls, deployment target overlap, load balancing, logs, metrics, traces, NAT/data transfer, notifications, and retained evidence. Failed retries can dominate a small lab bill.

Stop executions, restore the known-good target, then delete only tagged lab resources in dependency order: deployment, pipeline/webhook or connection use, build project/cache, artifacts and versions per policy, logs/alarms/events, roles/policies, KMS grant/key schedule only if exclusively owned, and target infrastructure. Verify inventories, ENIs, buckets, target groups, log groups, alarms, and cost explorer later because billing data lags.

Acceptance

Submit architecture and trust boundaries, release manifest, pipeline definition, gate reports, digest continuity, approval record, deployment timeline, release-scoped dashboard, controlled-failure and recovery evidence, sixteen-case matrix, cost estimate, and two-pass cleanup inventory. Pass requires separation of duties, one artifact promoted, no exposed secret, meaningful automated gates, measured user recovery, acknowledged stateful limits, and zero unowned lab resource.

Official sources

• CodePipeline concepts
• CodePipeline stage conditions
• CodePipeline manual approvals
• CodeBuild build specification
• CodePipeline security