AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 65“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

Project 2: Container CI/CD Platform with ECS or EKS

TechLearningPro’s exam-prep services and API gateways ship as containers. Project 1 (lesson 64) proved a highly available three-tier footprint; this project proves you can **build,

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

Project 2: Container CI/CD Platform with ECS or EKS

AWS Cloud & DevOps Engineering · Lesson 65 · Production Projects and Interview

Lesson Overview

TechLearningPro’s exam-prep services and API gateways ship as containers. Project 1 (lesson 64) proved a highly available three-tier footprint; this project proves you can build, scan, push, deploy, observe, and roll back those containers with a production-shaped pipeline. You will pick a primary path of Amazon ECS on AWS Fargate (simpler control plane, excellent for most TechLearningPro services) and document when Amazon EKS is the better choice (Kubernetes ecosystem, multi-cluster portability, advanced scheduling). The portfolio artifact is a reproducible repo: Dockerfile → ECR → CI → blue/green or rolling deploy → CloudWatch → failure drills → destroy.

Continuity: Docker and ECS from lessons 16–17, EKS from 18 and 62, ECR supply chain from 19, pipelines from 26–28, deployment strategies from 34, and DevSecOps from 61. Tag Project=tlp-lesson65. Budgets before clusters; cleanup after demos.

Learning Objectives

State a business problem and F/NFRs for a containerized TechLearningPro service.
Choose ECS/Fargate as the primary runtime and justify when EKS wins instead.
Draw an end-to-end architecture from git push to healthy tasks behind a load balancer.
Structure a monorepo or app repo with infra/, app/, pipelines/, and docs/adr/.
Define IaC for VPC wiring, ECS cluster/service, task definition, ALB, and IAM roles.
Build multi-stage Docker images and push immutable tags to Amazon ECR.
Wire CI for lint, unit test, image build, vulnerability scan, and gated deploy.
Implement rolling or blue/green deployment with a documented rollback path.
Inject secrets via Secrets Manager or SSM Parameter Store—never bake secrets into images.
Instrument health checks, container insights / metrics, logs, and deploy alarms.
Execute at least two failure tests (bad image, failed health check, IAM denial).
Estimate cost drivers (Fargate vCPU/GB-hours, ALB, NAT, ECR storage) as illustrative ranges with pricing-page dates.
Produce deploy and destroy runbooks with evidence screenshots or CLI outputs.
Package portfolio deliverables suitable for interviews and PRRs (lesson 63).
Write ADRs for ECS-vs-EKS and for deployment strategy selection.
Apply least-privilege task execution and task roles.
Explain network placement (private subnets, egress via NAT or endpoints).
Connect supply-chain scanning gates from lesson 61 to the pipeline.
Contrast CodePipeline versus GitHub Actions for this workload without inventing APIs.
Prepare a three-minute interview walkthrough of the project.

Prerequisites

Lessons 16–19, 26–28, 34, 61–64 concepts completed or reviewed.
Sandbox AWS account with billing alerts; IAM permission to create ECS/ECR/ALB/IAM (or assume a lab role).
Docker locally or CodeBuild/GitHub-hosted runners for builds.
Optional: EKS familiarity for the comparison ADR—full EKS lab is optional, not required for primary path.

Detailed Core Concepts

Business problem

TechLearningPro needs a repeatable path to ship a containerized Enrollment API (create/list course enrollments) to AWS with security scanning, zero-secret-in-image discipline, and one-command rollback. Manual SSH deploys and “latest” tags are unacceptable for exam-season traffic.

Functional requirements (FR)

HTTP API behind an Application Load Balancer.
Immutable image tags (git SHA or build ID).
Automated deploy on merge to main after green checks.
Structured logs and request metrics.
Rollback within minutes without rebuild when last-known-good image exists.

Non-functional requirements (NFR)

Availability across ≥2 AZs; deploy without prolonged downtime; least-privilege IAM; encrypted traffic to ALB (ACM); private task networking; budget alert; full destroyability; evidence for PRR.

Primary path: ECS on Fargate

Amazon ECS orchestrates tasks and services. AWS Fargate removes EC2 capacity management. TechLearningPro chooses Fargate for Enrollment API because: small team, no custom kube controllers, AWS-native IAM/ALB integration, lower ops tax than EKS for a single service.

Alternate path: EKS — when to choose it

Choose Amazon EKS when you need Kubernetes APIs, Helm/GitOps (lesson 62), multi-tenant cluster economics, sidecars/service mesh patterns already standardized on k8s, or workforce already skilled in Kubernetes. Do not choose EKS “for resume only”—document the ops cost (control plane, add-ons, upgrades).

Service selection rationale

Concern	ECS/Fargate	EKS
Ops complexity	Lower	Higher
Portability	AWS-centric	Kubernetes ecosystem
Networking	awsvpc / ALB target groups	CNI, Ingress/Gateway
Scaling	Service Auto Scaling	HPA/KEDA/cluster autoscaler
Fit for this project	Primary	Comparison ADR + optional stretch

Repo structure

text
tlp-enrollment-cicd/
  app/                 # application source + Dockerfile
  infra/terraform/     # or cdk/ — cluster, service, ALB, IAM, ECR
  pipelines/           # buildspec or GitHub Actions workflows
  docs/adr/
  docs/runbooks/
  evidence/            # screenshots, scan reports (no secrets)
  README.md

IaC approach

Terraform (lessons 30–31) or CDK (33): remote state, modules for network (reuse Project 1 VPC if available), ECS service module, IAM module. Never store state locally for portfolio demos intended as “production-shaped.”

Security baseline

Task execution role (pull ECR, write logs, read secrets); task role (app AWS API calls only); no *:*; image scanning on push; pipeline OIDC to AWS (GitHub Actions) or CodeBuild service role; WAF optional for public ALB (lesson 42).

CI/CD baseline

Stages: checkout → test → build → scan → push → deploy → smoke. Fail pipeline on critical CVEs per org policy (lesson 61). Prefer OIDC federation over long-lived access keys.

Monitoring baseline

ALB target health; ECS service CPU/memory; application log group; alarm on 5xx and unhealthy host count; deploy notification on failure.

Cost drivers

Fargate vCPU and memory hours; ALB hours and LCUs; NAT Gateway (largest surprise if present); ECR storage; CodeBuild minutes or Actions minutes. Quote only with pricing-page retrieval dates or mark illustrative.

Architecture and Design Diagrams

mermaid
flowchart LR
  Dev[Developer push] --> Git[GitHub / CodeCommit]
  Git --> CI[CI: test build scan]
  CI --> ECR[Amazon ECR]
  CI --> Deploy[Deploy stage]
  Deploy --> ECS[ECS Service Fargate]
  Users[Learners / admins] --> ALB[ALB + ACM]
  ALB --> ECS
  ECS --> Logs[CloudWatch Logs]
  ECS --> SM[Secrets Manager / SSM]
  ECS --> DB[(Optional data store)]

mermaid
flowchart TB
  subgraph Decision
    NeedK8s{Need Kubernetes APIs / GitOps / mesh?}
    NeedK8s -->|No| ECSPath[ECS on Fargate primary]
    NeedK8s -->|Yes| EKSPath[EKS + GitOps path]
  end

mermaid
sequenceDiagram
  participant P as Pipeline
  participant E as ECR
  participant S as ECS Service
  participant A as ALB
  P->>E: Push image:gitsha
  P->>S: Update task definition
  S->>S: Start new tasks
  A->>S: Health checks
  alt Healthy
    S->>S: Drain old tasks
  else Unhealthy
    S->>S: Stop rollout / revert task def
  end

Technical Explanation

Build and supply chain

Multi-stage Dockerfile: build stage compiles/tests; runtime stage is minimal distroless or slim base. Pin base digests when your org requires it. Scan with ECR native scanning or a third-party scanner your pipeline already supports—verify current scanner APIs in docs; do not invent flags.

Task definition essentials

CPU/memory pair must be a valid Fargate combination (confirm current valid pairs in AWS docs). Environment variables for non-secrets; secrets via secrets mapping from Secrets Manager/SSM. Health check command or ALB health path /health.

Deployment strategies

Rolling (default ECS): gradual replacement; simple. Blue/green with CodeDeploy for ECS: separate target groups, traffic shift, automatic rollback on CloudWatch alarms—stronger for exam-season. Record ADR-6501 for the choice.

Rollback

Keep previous task definition revision. Pipeline or runbook: update-service to prior revision (use current AWS CLI syntax from docs). Evidence: screenshot of healthy targets after rollback drill.

Networking

Tasks in private subnets; ALB in public (or internal-only for private APIs). Egress: VPC endpoints for ECR/Logs/Secrets reduce NAT cost—cite lesson 50. Security groups: ALB→tasks on app port only; tasks→AWS APIs via endpoints or NAT.

IAM

Separate execution role vs task role. Pipeline role may ecs:UpdateService, iam:PassRole only for the specific roles, ecr:PutImage on the project repo. Deny iam:CreateUser and broad * in SCPs if Organizations is in play (lesson 48).

Observability hooks for lesson 68

Emit correlation IDs; use awslogs driver; optional X-Ray/OpenTelemetry (lessons 38–39). This project must leave enough telemetry for Project 5.

EKS comparison (conceptual)

If stretching to EKS: ECR same; deploy via Deployment+Service+Ingress or AWS Load Balancer Controller; GitOps (Argo CD/Flux) per lesson 62; IRSA instead of task roles. Portfolio can stop at a written comparison if budget forbids a second control plane.

Practical Implementation or Design Walkthrough

Problem

Deliver a build-to-deploy Enrollment API platform on ECS/Fargate with scanning and rollback evidence.

Steps

Enable budget alert; plan tags Project=tlp-lesson65.
Create ECR repository; enable scan-on-push (confirm console/API name in current docs).
Author app + Dockerfile; local docker build smoke test.
Terraform/CDK: VPC (or data source), ECS cluster, task definition, service, ALB, listeners, target group, IAM, log group.
Pipeline: GitHub Actions OIDC or CodePipeline+CodeBuild; stages listed above.
First deploy; hit /health and a business route.
Failure test A: deploy intentionally broken image; show ALB/ECS refuse unhealthy; rollback.
Failure test B: remove secret permission; show task fail to start; restore IAM; document.
Capture evidence pack; write ADR-6501 (ECS vs EKS) and ADR-6502 (rolling vs blue/green).
Destroy: pipeline off; terraform destroy / CDK destroy; verify Cost Explorer tag trend; sworn cleanup statement.

Suggested terraform layout (illustrative names)

modules/ecs_service, modules/alb, modules/ecr, envs/lab. Exact resource attributes must match current provider docs—do not copy stale argument names from memory without verification.

Enterprise Real-World Scenarios

Exam-season freeze

Marketing wants daily deploys; SRE freezes to hotfixes only. Pipeline still builds and scans; deploy stage requires manual approval.

“Just use latest”

Engineer tags :latest and breaks rollback. Fix: immutable tags + deny mutable overwrite policy where supported.

EKS resume pressure

Candidate builds EKS for one static API and burns budget on unused nodes. Fix: ADR chooses ECS; EKS reserved for multi-service platform later.

Secrets in ENV in task def plaintext

Secret appears in console and CloudTrail-adjacent views. Fix: Secrets Manager ARNs in task definition secrets block.

NAT bill shock

Private tasks pull images via NAT. Fix: ECR interface/gateway endpoints; measure before/after.

Best Practices

Prefer Fargate ECS unless Kubernetes requirements are real.
Immutable image tags only.
Separate execution and task roles.
Scan and gate on severity policy.
Private subnets for tasks.
Health checks that reflect app readiness, not just process up.
Alarm-gated blue/green when downtime risk is high.
OIDC for CI; no long-lived keys in git.
Remote state + locking for IaC.
Document rollback with a timed drill.
Tag everything for FinOps.
Budget before apply.
Destroy after portfolio capture unless intentionally retained under budget.
Link ADRs from README.
Reuse Project 1 network when it reduces cost and complexity.

Common Mistakes and Anti-Patterns

Choosing EKS for a single CRUD API without ops plan.
Baking AWS keys into images.
Public tasks with open security groups.
No health check; deploy “succeeds” while serving 500s.
Pipeline with admin credentials.
Forgetting log group retention → cost and noise.
Skipping scan gates “to go faster.”
One giant terraform root with no modules or envs.
No failure tests in the portfolio.
Inventing CodeDeploy hook names instead of reading current docs.

Troubleshooting and Design Review

Symptom	Cause	Action
Tasks stop immediately	Bad image, secrets permission, health check	Describe tasks/stopped reason; fix IAM/image
ALB 502/503	No healthy targets	Check SG, port, health path
Cannot pull from ECR	Execution role / endpoints / DNS	Fix role + VPC endpoints
Deploy hangs	Circuit breaker / failed stability	Read events; roll back revision
High NAT cost	Image/layer pulls via NAT	Add endpoints; reduce churn
Scan not blocking	Gate not wired	Fail build on policy

Interview Questions and Answers

Q1: Why ECS over EKS here? A: Lower ops for a single AWS-centric service; EKS when k8s APIs/GitOps/mesh justify cost.
Q2: Execution vs task role? A: Execution = agent (ECR/logs/secrets); task = application AWS calls.
Q3: How do you roll back? A: Redeploy previous task definition revision; blue/green auto-rollback on alarms if configured.
Q4: How are secrets injected? A: Secrets Manager/SSM referenced from task definition—not ENV plaintext.
Q5: What fails closed in CI? A: Tests, critical vulns, unsigned/unscanned images per policy.
Q6: Network placement? A: Tasks private; ALB public or internal; tighten SGs.
Q7: Cost surprises? A: NAT, ALB always-on, idle Fargate services left up.
Q8: Immutable tags? A: Traceability and reliable rollback.
Q9: When blue/green? A: Need traffic shift + automated rollback evidence.
Q10: OIDC? A: Short-lived cloud credentials from GitHub identity.
Q11: Portfolio proof? A: Diagram, IaC, scan report, failure+rollback evidence, destroy proof.
Q12: Link to lesson 61? A: Supply-chain gates sit in the same pipeline.
Q13: Link to lesson 62? A: EKS/GitOps alternate path when k8s is chosen.
Q14: Observability minimum? A: Logs, ALB metrics, unhealthy host alarm.
Q15: What do you tell FinOps? A: Tags, budgets, destroy idle labs, endpoints vs NAT.

Hands-On Exercises

Exercise: Build-to-deploy Enrollment API on ECS/Fargate

Deliverable: Working pipeline evidence, IaC, ADRs (ECS vs EKS; deploy strategy), two failure tests, cost+cleanup notes, portfolio README.

Challenge ADR

Accept a 30-day freeze to rolling deploys only during exam season; schedule blue/green ADR revisit after season ends.

Lab evidence checklist

architecture diagram, Terraform/CDK, pipeline config, scan report, rollback evidence, ADRs; budget/cleanup confirmation.

Narrative: A broken image nearly reached learners; alarm-gated rollback and immutable tags saved the release train

A broken image nearly reached learners; alarm-gated rollback and immutable tags saved the release train.

Continuity

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Deep dive: ADR template (TechLearningPro)

text
# ADR-NNNN: Title
Date:
Status: Proposed | Accepted | Deprecated | Superseded by ADR-XXXX
Context:
Decision:
Consequences:
Evidence / links:

Deep dive: Portfolio README skeleton

text
TechLearningPro Project — Lesson 65
- Problem / NFRs
- Architecture (diagram + service rationale)
- Repo layout
- Deploy / destroy
- Security checklist
- Observability
- Failure tests
- Cost notes (illustrative; verify pricing)
- ADRs

Deep dive: Budget and tagging

Create or verify a budget with email/SNS subscriber before any apply. Tag Project=tlp-lesson65, Owner=<you>, Environment=lab. Screenshot Cost Explorer filtered by tag after destroy to prove idle cost returned near zero (allow for delayed billing).

Extended enterprise scenario: acquisition pressure

Leadership wants the lab promoted as “production-ready marketing copy.” Refuse without PRR evidence from lesson 63, WAR risks from lesson 58, and failure-test artifacts from this lesson.

Extended enterprise scenario: disputed decision

Two senior engineers disagree on the primary architecture choice. Run a timeboxed RFC, record ADR with revisit date, and keep the rejected alternative documented so interviews and audits see the trade-off—not silence.

Extended practice scenario 1 — 65 container ci/cd with ecs or eks

Confirm AWS Budgets alerts exist for the sandbox; tag every resource Project=tlp-lesson65. Do not proceed without a budget subscriber.

In a timed drill for Container CI/CD with ECS or EKS at TechLearningPro, implement or design the core lab with a partner observing. The observer's job is to stop any step that invents API flags, hardcodes secrets, invents pricing numbers presented as current quotes, or skips budget and cleanup. After the drill, rewrite your ADR in ten lines: context, decision, consequences. Attach evidence: architecture diagram, Terraform/CDK, pipeline config, scan report, rollback evidence, ADRs, and destroy confirmation for any lab resources.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Finally, teach back the lesson overview paragraph from memory, then check against the text. Gaps become flashcards. Premium courses finish when you can operate under time pressure without treating Container CI/CD with ECS or EKS as a mystery.

Extended practice scenario 2 — 65 container ci/cd with ecs or eks

Document the lesson's primary architecture decision in a ten-line ADR: context, decision, status, consequences.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 3 — 65 container ci/cd with ecs or eks

Map identity paths: who can create/modify the resources in this lesson; which IAM roles are least privilege.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 4 — 65 container ci/cd with ecs or eks

Design observability: CloudWatch metrics/alarms or equivalent signals that prove the control works.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 5 — 65 container ci/cd with ecs or eks

Run or design a negative test: denied access, misconfiguration, or failed dependency—capture evidence.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 6 — 65 container ci/cd with ecs or eks

Estimate cost dimensions for this lesson's activities. Label figures illustrative; verify pricing pages with dates.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 7 — 65 container ci/cd with ecs or eks

Produce a cleanup checklist and execute destroy for any billable lab resources created for lesson 65.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 8 — 65 container ci/cd with ecs or eks

Cross-link prior course lessons that this design depends on; list two failure modes inherited from those layers.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 9 — 65 container ci/cd with ecs or eks

Security review: encryption at rest/in transit, public exposure checks, CloudTrail visibility for management events.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 10 — 65 container ci/cd with ecs or eks

Reliability review: failure injection, rollback path, how detection and recovery work.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 11 — 65 container ci/cd with ecs or eks

Performance review: throughput, latency, or scaling limits relevant to Container CI/CD with ECS or EKS at TechLearningPro.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 12 — 65 container ci/cd with ecs or eks

Write a runbook section for on-call: symptoms, first three diagnostic steps, escalation, rollback.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 13 — 65 container ci/cd with ecs or eks

Config/compliance angle: which controls must be true before production promotion.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 14 — 65 container ci/cd with ecs or eks

Multi-account consideration: how this workload sits in landing-zone OU boundaries from lessons 48–49 and 67.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 15 — 65 container ci/cd with ecs or eks

Interview drill: explain Container CI/CD with ECS or EKS at TechLearningPro to a hiring manager in three minutes without inventing APIs.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 16 — 65 container ci/cd with ecs or eks

Pair review: partner stops any invented CLI flags, hardcoded secrets, or fake current prices.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 17 — 65 container ci/cd with ecs or eks

FinOps continuity from lesson 47: idle resources, data transfer, and when to decommission lab stacks.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 18 — 65 container ci/cd with ecs or eks

DR continuity from lesson 45 and 68: recoverability must survive the change you are shipping.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 19 — 65 container ci/cd with ecs or eks

Produce evidence pack: diagrams, configs, test results, cleanup proof.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 20 — 65 container ci/cd with ecs or eks

Challenge constraint: tighter monthly budget—what do you sequence differently?

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 21 — 65 container ci/cd with ecs or eks

Challenge constraint: stricter compliance—what evidence gates promotion?

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 22 — 65 container ci/cd with ecs or eks

Challenge constraint: shorter maintenance window—what pre-staging changes?

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 23 — 65 container ci/cd with ecs or eks

Teach-back: recite the Lesson Overview paragraph, then check against the text; flashcard gaps.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 24 — 65 container ci/cd with ecs or eks

Dress rehearsal: tabletop under a timer with observer notes.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Extended practice scenario 25 — 65 container ci/cd with ecs or eks

Final synthesis note: one paragraph connecting Container CI/CD with ECS or EKS at TechLearningPro to TechLearningPro production ownership.

Builds on Project 1 (lesson 64) and feeds Project 5 observability (lesson 68). Next: Project 3: Serverless Event-Driven Order Platform.

Compliance evidence pack for auditors / platform leads

Budget configs, tagging proof (Project=tlp-lesson65), architecture diagram, ADR, negative-test evidence, encryption settings notes, CloudTrail/Config references where applicable, pricing-page retrieval dates for any dollar claims, cleanup confirmation.

Glossary drill

Review every bold term introduced in Detailed Core Concepts and Interview Q&A. Write one sentence definitions from memory; correct against the lesson. Unfamiliar AWS console navigation becomes a lab note, not a guess. Focus terms: task definition, Fargate, target group, OIDC, image digest, circuit breaker.

Budget and cleanup sworn statement

I verified budgets remain enabled with alert subscribers. I deleted or scheduled deletion for orphan lab resources from lesson 65 named ____. I labeled every savings or cost figure with pricing-page retrieval dates or marked it illustrative. Signed ________ date ________.

Interview story to memorize

Craft a 60-second story: TechLearningPro needed Container CI/CD with ECS or EKS; you chose a design with explicit trade-offs; you proved it with tests; you governed cost with budgets and tags; you left an ADR so the next engineer does not reverse the decision blindly. Mention ECS vs EKS trade-off in one sentence.

Self-assessment rubric

Area	Weight
Conceptual accuracy and service selection	20%
Working design/lab and reproducibility	25%
Security and least-privilege	20%
Reliability, observability, troubleshooting	20%
Documentation, ADR, cleanup	15%

Final synthesis before summary

Mastery of Container CI/CD with ECS or EKS at TechLearningPro is not logo recognition—it is owning failure modes, cost meters, identity boundaries, and the written decision that keeps TechLearningPro coherent under change.

Extended facilitation script (print for guild leads)

Open with the business consequence (enrollment API down during checkout of a course). Ask: How do we know a deploy is bad before all tasks flip? Where are secrets? What is the destroy path? Demand ADR-6501 on the table. End by scheduling Project 5 telemetry wiring.

Lesson Summary

Project 2 proves TechLearningPro can ship containers with ECS/Fargate as the primary path—immutable images, scanned pipelines, least-privilege roles, rollback drills, and destroyable IaC—while documenting when EKS is the better choice. Tag Project=tlp-lesson65.

Next: Project 3: Serverless Event-Driven Order Platform.