Day 5 - Week 7 Wrap-Up — Cementing It with 12 Container Scenario Questions

Over the week we looked at nearly every building block of the container domain, from ECS, EKS, Fargate, Karpenter, and IRSA to Service Connect. Now we see how the SAP exam actually combines these blocks into a single question. The exam's container questions do not ask about single-service knowledge but about combinations of blocks. "Multi-account + EKS + cost + hybrid" appears in a single question at the same time, and keyword matching alone does not get you even half. The key is how Domain 1 (organizational complexity and reliability), Domain 2 (architecture and resilience), and Domain 3 (security and cost) branch out on the common foundation of containers.

This article is the time to cement the week through 12 scenario questions. Each question demands not simple fact-checking but branching judgment. The pattern where changing a single sentence of the same scenario moves the correct answer to a different option is typical of SAP, and the explanations spell out those branch points. At the end, we organize the whole Week 7 mapping on one page.

Week 7 at a Glance — Decision Tree

Q1. Starting a container workload
     │
     ├─ Is simple deployment and zero operations the top priority?
     │     └─ Yes → App Runner
     │     └─ No  → below
     │
     ├─ K8s standard compatibility / multi-cloud portability?
     │     └─ Yes → EKS
     │     └─ No  → ECS
     │
     ▼
Q2. Choosing the data plane
     │
     ├─ Minimal operational burden? → Fargate
     ├─ Bin packing / high density? → EC2 Launch Type
     └─ On-premises? → Anywhere

Q3. Node autoscaling (EKS)
     ├─ Fast scaling / bin packing / automatic Spot? → Karpenter
     └─ Simple ASG-based? → Cluster Autoscaler

Q4. Per-Pod permissions
     ├─ Reuse permissions across multiple clusters? → Pod Identity
     ├─ OIDC standard compatibility? → IRSA
     └─ A single node-level permission is OK? → Instance Profile (anti-pattern)

Q5. Cost optimization
     ├─ 24/7 steady load → EC2 + Compute SP
     ├─ Variable + zero operations → Fargate Spot + Compute SP
     ├─ Short and frequent → Lambda
     └─ ARM compatible → Graviton +20% savings

Q6. Service-to-service communication
     ├─ Full mesh (mTLS, canary) → App Mesh
     ├─ Lightweight mesh for ECS → Service Connect
     └─ Discovery only → Cloud Map

Once this tree is drawn in your head, you can check as you solve the 12 questions which branch your own answer diverged on.

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

A global fintech deploys the same K8s workload to three environments: AWS, GCP, and on-premises. On AWS it wants to reduce the burden of operating the control plane (etcd backup, version upgrades), and it must be able to apply the same manifests as they are to the other environments. What is the most suitable combination?

• AECS Fargate + Capacity Provider
• BEKS + Managed Node Group (or EKS Auto Mode)
• CApp Runner + GitHub automatic deployment
• DECS Anywhere

Question 2

A company operates 30 EKS clusters. Pods in each cluster must access S3 and DynamoDB with least privilege per Pod. What is the method that makes it easy to reuse the same IAM Role across all clusters?

• AGrant permissions to the EC2 Instance Profile
• BIRSA (IAM Roles for Service Accounts)
• CEKS Pod Identity
• DInject the Access Key Secret through Pod environment variables

Question 3

An EKS cluster with variable traffic. It must satisfy all of the following: (1) scale-out within 1 minute, (2) optimal instance type chosen each time according to Pod requests, (3) automatic handling of Spot mix, (4) automatic consolidation when node utilization is low. Which tool is suitable?

• ACluster Autoscaler + ASG
• BHorizontal Pod Autoscaler only
• CKarpenter
• DEKS Managed Node Group + Spot Allocation

Question 4

An ECS Fargate back-office API. An average of 5 Tasks is enough, but it spikes to 30 Tasks during campaigns. A 1-year commitment is possible, and some Task interruption is tolerable. What is the cost-optimal configuration?

• AFARGATE On-Demand 100% + EC2 Instance Savings Plans
• BFARGATE_SPOT 100%
• CA Compute Savings Plans commitment for 5 Tasks + Capacity Provider (base=2 FARGATE + FARGATE_SPOT 80%)
• DEC2 Launch Type + Reserved Instance

Question 5

A media startup wants automatic build, deployment, and an HTTPS endpoint from a single code push, with no operational burden. Sidecars, service mesh, and advanced VPC integration are unnecessary. Which service is most suitable?

• AECS Fargate + ALB
• BEKS + ArgoCD
• CApp Runner
• DElastic Beanstalk

Question 6

A fintech runs 30 ECS Fargate microservices. (1) mTLS for all communication, (2) 5% traffic canary for new versions, (3) per-service circuit breakers. What is the most suitable combination?

• AALB Weighted Target Group + ACM Public Certificate
• BAWS App Mesh + ACM Private CA
• CCloud Map only
• DRoute 53 Weighted Routing

Question 7

Between microservices in an ECS Cluster: (1) automatic service discovery, (2) automatic Envoy sidecar injection, (3) automatic CloudWatch metrics, (4) minimal operational burden. Weighted canary is unnecessary. Which service is suitable?

• AApp Mesh
• BECS Service Connect
• CCloud Map + manual client LB
• DALB per Service

Question 8

A manufacturer runs industrial gateway container workloads at 100 factories. Some factories lose internet for days at a time. The control plane must operate autonomously inside the factory. Which service is most suitable?

• AECS Anywhere
• BEKS Anywhere
• CAWS Outposts
• DSnowball Edge

Question 9

Upgrading EKS 1.22 → 1.24. What is the most accurate procedure?

• AUpgrade the Control Plane from 1.22 to 1.24 in one step
• BUpgrade the node groups to 1.24 first, then the Control Plane
• CUpgrade the Control Plane in stages 1.22 → 1.23 → 1.24, checking node group and Addon compatibility at each step, and install the EBS CSI Driver Addon (required from 1.23+)
• DCreate a new 1.24 cluster and migrate the workloads

Question 10

An EKS Pod has enough CPU and memory, but new Pods can no longer be scheduled. It looks like it hit a limit other than node resources. What is the solution with the least operational burden?

• AReplace the node group with a larger instance
• BEnable VPC CNI Prefix Delegation
• CReplace with the Calico CNI
• DConfigure Custom Networking

Question 11

A SaaS has a machine learning inference workload (average 100ms, 50,000 calls per hour, 3GB memory). What is the cost-optimal compute?

• ALambda
• BFargate On-Demand
• CFargate Spot
• DEC2 + Reserved Instance

Question 12

A company runs EC2 and Fargate at the same time and plans to move workloads from EC2 to Fargate during migration. It wants a 1-year commitment discount, but it must apply to both services and the discount must be maintained during the migration. Which commitment?

• AEC2 Instance Savings Plans
• BCompute Savings Plans
• CStandard Reserved Instance
• DConvertible Reserved Instance

The SAP-Specific Perspective — Viewing Containers Through Multi-Account, Multi-Region, 7R, and the WA 6 Pillars

The SAP exam's container domain is not simply "which service do you use" but is combined with SAP-specific perspectives. Multi-account, Multi-Region, 7R migration, and the Well-Architected 6 Pillars are layered one at a time onto the same EKS and ECS scenarios, so keyword matching alone does not yield the answer.

Multi-Account — Containers on Top of Organizations, SCP, and Control Tower

Large enterprises operate EKS and ECS clusters separated by account: dev, staging, and prod each in their own account, and the data team and payments team in theirs. How to share ECR images and how to tie IAM Roles together cross-account at that point are favorite SAP scenarios.

Three core patterns:

1. ECR Cross-Account Pull: Push all images to the ECR of a central "shared-services" account, and the ECS Task Execution Role or EKS Node Role in other accounts pulls cross-account. Allow the other accounts' principals with the ECR Repository Policy.
2. IRSA Cross-Account: The EKS cluster is in account A and the S3 bucket is in account B. The IAM Role that IRSA maps chains into a Role in account B with sts:AssumeRole.
3. Enforcing container policy with SCPs: Enforce guardrails such as "EKS clusters must have IAM Roles Anywhere disabled" or "ECS Task Definitions may only allow the awslogs driver" across all accounts with Organizations SCPs.

🎯 Scenario: "A company operates 30 accounts on top of Control Tower. dev, staging, and prod each have their own EKS cluster, and container images are built and deployed only from the central account. The operations team wants to enforce that EKS Pods in all accounts cannot pull images directly from the external internet. Which combination?" — The answer is central account ECR + Repository Policy allowing cross-account pull + SCP blocking external registries + VPC Endpoints (ECR, S3) in each account. An SCP is a guardrail that enforces denial of IAM permissions, and a VPC Endpoint makes traffic flow only inside AWS.

Multi-Region — Active/Active vs Active/Passive Container Architecture

Multi-Region patterns for container workloads fall into two branches.

ECR Cross-Region Replication is the foundation of both patterns. A push to one Region is automatically replicated to the ECR of another Region, so the DR Region can use the images immediately. EKS has no cross-region replication of its own, so the standard pattern is to synchronize workload manifests to both Regions with GitOps (ArgoCD, Flux).

The data layer is the hardest part. Choose among DynamoDB Global Tables (multi-region, active-active), Aurora Global Database (asynchronous, < 1 second lag), and S3 Cross-Region Replication (asynchronous) according to the workload's consistency requirements.

📚 Case: During the major us-east-1 outage in December 2021, companies with a Multi-Region Active/Active structure (some of Netflix and Stripe) automatically shifted traffic to us-west-2 and minimized the impact. Companies that ran ECS in a single Region only suffered service outages from as short as 4 hours to as long as 9 hours. When SAP emphasizes "RTO within 5 minutes even for a single-Region failure," Active/Active + Route 53 Health Check is the standard answer.

🔍 Going deeper: The cost of Multi-Region containers cannot be ignored. Running the same workload in two Regions roughly doubles infrastructure cost. To reduce this, lower the activity level with Pilot Light (only the DB and minimal infrastructure on standby) or Warm Standby (running at a small scale). If the RTO/RPO requirement tolerates minutes, Pilot Light is cost-efficient; if the RTO is in seconds, Active/Active.

The Place of Containers in the 7R Migration Strategies

The AWS migration 7R framework is as follows.

Containers are the core tool of Replatform and Refactor. Wrapping a monolithic .war file in a Tomcat container and putting it on ECS is Replatform, and splitting the monolith into 30 microservices and putting them on EKS is Refactor.

🎯 Scenario: "A company is moving an on-premises monolithic Java application (.war + Tomcat) to AWS. It wants to minimize code changes while reducing operational burden. Which 7R strategy and service combination?" — The answer is Replatform + ECS Fargate. Wrap Tomcat + .war in a Dockerfile to containerize it and put it on ECS Fargate. EC2 Rehost leaves the operational burden as is, and EKS Refactor involves large code changes.

⚠️ Pitfall: "Lift & Shift = ECS Fargate" is a wrong-answer pattern. Containerization is Replatform, not Lift & Shift. Lift & Shift is moving without changes, while containerization requires at least writing a Dockerfile and changing the image build.

Mapping Container Decisions to the Well-Architected 6 Pillars

💡 Related theory: The WA 6 Pillars are a tradeoff framework, and one decision affects several Pillars. For example, going with Karpenter Spot 100% scores ⭐⭐⭐ on cost efficiency but drops to ⭐ on reliability. When the SAP exam explicitly says "both cost and reliability," a balanced configuration such as base=2 + Spot 80% becomes the answer. An answer that maximizes only one Pillar is almost always wrong.

Week 7 Comparison Matrix — When Two Services Look Confusingly Alike

Week 7 Summary at a Glance

Orchestration   ──► ECS (AWS-proprietary) / EKS (K8s standard) / App Runner (PaaS)
Data plane      ──► EC2 Launch / Fargate / Fargate Spot / Anywhere
Scalers         ──► HPA (Pod) / Karpenter (Node, recommended) / Cluster Autoscaler
Pod permissions ──► IRSA (OIDC) / Pod Identity (multi-cluster)
Discovery, mesh ──► Cloud Map (registry) / Service Connect (ECS) / App Mesh (full)
Hybrid          ──► ECS Anywhere (control in AWS) / EKS Anywhere (control on-premises) / Outposts
Cost levers     ──► Fargate Spot (-70%) + Compute SP (-66%) + Graviton (-20%)
Upgrades        ──► EKS one minor at a time, nodes ±1, EBS CSI required from 1.23+

Preview of Next Week

Week 8 is advanced serverless. We cover advanced Lambda (layers, extensions, Provisioned Concurrency), Step Functions (workflow orchestration), EventBridge (event routing), DLQ and retry strategies, and event-driven microservice architecture. The Lambda vs Fargate vs EC2 branch judgment we saw today becomes the starting point of Week 8. What happens one level above ECS and EKS (or one level lighter) is next week's theme.

Over the week we have seen all the building blocks of the container domain. If you have developed the sense of immediately eliminating one or two of the four options on the exam, that is enough. The rest is training to narrow the answer candidates by breaking down two or three keywords of the scenario, and that translates directly into points on the next mock exam and the real exam.