Amazon DOP-C02: Containers and Serverless Operations — Study Guide

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Part of the AWS DevOps Engineer Professional DOP-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

Overview

Containers and serverless change how you operate, scale, and release applications on AWS. This section connects the operational primitives across Amazon ECS, AWS Fargate, Amazon EKS, Amazon ECR, AWS Lambda, and Amazon API Gateway so you can design safe deployments, enforce image governance, tune concurrency, and make consistent choices between EC2- and Fargate-based capacity. It focuses on task and pod scheduling models, health checks and deployment controls, traffic shifting, cross-account image distribution, and performance features such as API caching and Lambda provisioned concurrency.

Amazon ECS and AWS Fargate

ECS task definitions declare one or more containers and all the runtime configuration needed by the scheduler. Key elements include CPU/memory reservations and limits, portMappings, environment variables and secrets (from AWS Secrets Manager or Systems Manager Parameter Store), Linux parameters and ulimits, logConfiguration (awslogs, firelens, etc.), ephemeralStorage size (for Fargate, 20–200 GB), and volumes (including EFS). Use the task execution role for image pulls and log drivers; use the task role for application AWS API access. Container healthCheck defines command, interval, timeout, retries, and startPeriod. Combined with dependsOn (condition=HEALTHY), health checks enforce startup ordering for sidecars.

ECS services maintain desired task count and optionally register tasks with an ALB/NLB. Service deploymentConfiguration controls rolling updates with minimumHealthyPercent and maximumPercent. The deployment circuit breaker (enabled/rollback) can automatically revert failed rollouts when tasks fail health checks. Service autoscaling integrates with Application Auto Scaling for CPU/memory-based target tracking or ALB RequestCountPerTarget. Service discovery (AWS Cloud Map) and ECS Service Connect simplify service-to-service traffic.

Cluster types and capacity:

EC2 launch type runs tasks on self-managed EC2 instances. Use Auto Scaling groups, placement constraints/strategies, and any networkMode (bridge/host/awsvpc). Daemon tasks and specialized AMIs (e.g., Bottlerocket) are supported.
Fargate launch type is serverless compute for containers. It uses awsvpc networking only, giving each task its own ENI and security group. No daemon tasks; you rely on sidecars or service-native integrations (e.g., FireLens). Platform versions gate features (check release notes for EFS, ephemeral storage, and exec support). Fargate Spot reduces cost for interruptible tasks. Choose CPU/memory in supported pairs (e.g., 0.25 vCPU/0.5–2 GB through 16 vCPU/120 GB). When running in private subnets, add VPC interface endpoints for ECR (api and dkr), CloudWatch Logs, and S3 gateway endpoint to pull images and ship logs without NAT.

Fargate and EFS: define an EFS volume in the task definition and mount with TLS; prefer EFS access points for least-privilege and identity enforcement. This supports stateful needs like shared configs, model weights, or intermediate files without baking them into images.

Container health checks, rolling updates, and blue/green:

Health checks happen at multiple layers: container (CMD-based), ECS task (aggregated container statuses), and load balancer target health (HTTP/TCP). Align intervals and thresholds so ECS can gracefully replace unhealthy tasks before ALB deregisters targets.
Rolling updates are the ECS default. Tune minHealthy/maxPercent to control surge and capacity safety.
Blue/green uses CodeDeploy with ECS (deploymentController type CODE_DEPLOY). CodeDeploy manages two target groups behind the ALB, shifts test traffic to the green set (AfterAllowTestTraffic), runs automated checks (for example via Lambda), then shifts production traffic. Tie CloudWatch alarms to rollback on 5XX spikes, latency, or custom metrics. This pattern isolates failures and provides fast reversions with near-zero downtime.

Image governance with ECR:

Scanning: enable scan-on-push and adopt Amazon Inspector enhanced scanning for continuous CVE coverage and SBOMs. Gate deployments on vulnerability severity using pipeline checks.
Lifecycle policies expire old image tags by count/age and tag prefix. Combine with tag immutability to block accidental overwrites.
Encryption: use ECR-managed encryption or a customer-managed KMS key with appropriate key policy.
Cross-account: attach repository resource policies to grant pull/push from other accounts or CI roles. Use ECR replication rules to copy images across Regions/accounts for locality and blast-radius reduction. PrivateLink (VPC endpoints) allows image pulls without internet.

Amazon EKS Compute Models

EKS separates the managed control plane from your data plane choices:

Managed node groups (MNGs) provision and lifecycle-manage EC2 worker nodes. They integrate with launch templates for AMI choice (Amazon Linux 2, Bottlerocket), instance types, and bootstrap parameters. MNGs handle rolling updates with surge capacity and automated cordon/drain for minimal disruption. Use node taints/tolerations to steer specific workloads. Combine with the Cluster Autoscaler (or Karpenter) to rightsize node capacity based on pending pods.

Self-managed nodes give full control over bootstrap and OS but add operational overhead; they’re typically reserved for special kernels or niche hardware.

EKS on Fargate runs pods without managing nodes. Fargate profiles map namespaces/labels to Fargate. Each pod gets its own ENI (awsvpc), simplifying network isolation. Limitations include no DaemonSets, no host networking/volumes, and constraints on privileged workloads. Observability agents (e.g., Fluent Bit) must run as sidecars or use managed log collection. This model is ideal for spiky, small-footprint, or multi-tenant workloads that benefit from per-pod isolation and pay-per-pod economics.

Operational add-ons:

VPC CNI, CoreDNS, and kube-proxy are managed add-ons; pin versions compatible with the cluster version and upgrade deliberately.
IAM Roles for Service Accounts (IRSA) enforces least-privilege AWS access per pod and replaces node-role credential sharing.
Load balancing via the AWS Load Balancer Controller supports ALB/NLB for Services and Ingress; ensure proper IAM and security group rules, especially when mixing MNG and Fargate.
Persistent storage via CSI drivers (EBS for per-pod block, EFS for shared POSIX). For Fargate, EFS is the typical option for shared state.

AWS Lambda Operations and Concurrency

Packaging and configuration:

Deployment packages can be ZIP archives (with language runtime) or container images up to 10 GB. ZIP is lighter for small code; images unify tooling with container-based builds.
Layers encapsulate shared libraries across functions; keep them minimal and versioned. A function can include up to five layers.
Versions are immutable snapshots; aliases are stable pointers to versions and can carry weights for traffic shifting.
Ephemeral storage defaults to 512 MB and can be raised to 10,240 MB for builds, temp files, or ML inference caches. Choose x86_64 or arm64 for cost/performance trade-offs. Use environment variables for configuration and integrate with Secrets Manager or Parameter Store.

Traffic shifting and safety:

Use CodeDeploy for canary/linear shifts with automated rollback on CloudWatch alarms (e.g., 5XX, latency, or custom app metrics). Alternatively, set alias weights directly for simple A/B routing.
Use structured logging to CloudWatch Logs and create metric filters to derive operation/version/code-dimensioned metrics without changing metrics instrumentation. Enable X-Ray for end-to-end latency tracing.

Concurrency controls:

Unreserved concurrency draws from the account’s regional pool. Spiky traffic can starve other functions.
Reserved concurrency caps a function’s maximum concurrency and guarantees capacity for it by carving from the regional pool; this provides isolation from noisy neighbors.
Provisioned concurrency keeps execution environments initialized for a version/alias, virtually eliminating cold starts and stabilizing latency. Scale provisioned concurrency with Application Auto Scaling by time-of-day or metrics.
Throttling occurs when a function hits its concurrency limit; synchronous callers get 429 errors, while asynchronous invocations are retried with exponential backoff and can dead-letter after configured attempts. For poll-based sources like SQS, Lambda increases concurrency with queue depth; ensure reserved/provisioned concurrency and downstream capacity match the maximum inflight messages to avoid backlog growth.

API Gateway Design and ECR Cross-Account Access

API Gateway REST APIs versus HTTP APIs:

REST APIs provide the richest feature set: request/response mapping (VTL), usage plans and API keys, authorizers, WAF, and stage-level caching. Choose REST APIs when you need advanced transformations, API keys with quotas, or mature ecosystem integrations.
HTTP APIs are lower latency and cost with simpler routing to Lambda and HTTP backends (including ALB/NLB/private integrations). They support JWT authorizers and IAM but lack many REST features, including stage-level caching and VTL transformations. Choose HTTP APIs for straightforward proxying with minimal overhead.

Stages and throttling:

Stages bind a specific deployment to a URL path. Configure stage variables, logging, and throttling at the stage. Apply usage plans (REST) to enforce per-API key throttles and quotas. Throttling settings include rate and burst; they combine with account-level limits, so ensure aggregate traffic does not exceed regional quotas. Enable access logging with structured JSON and integrate WAF to inspect and block malicious requests.

Caching (REST APIs only):

Stage-level cache reduces backend load and latency; set TTLs per method, enable encryption, and consider cache key parameters/headers for correctness. Invalidate caches after deployments that change response shapes or behavior.

Private connectivity:

Choose endpoint type: edge-optimized (REST, global via CloudFront), regional, or private (VPC endpoints). Private integrations with VPC Link connect to NLB/ALB backends in VPCs without public exposure.

ECR cross-account access:

Use repository resource policies to grant pull/push to principals in other accounts (CI/CD or runtime roles). If using a customer-managed KMS key, extend key policy accordingly. For multi-account distribution, define ECR replication rules to target destination accounts/Regions and validate image integrity with tag immutability and digest pinning in deployments.

Practical Problem Scenario

Spotify is modernizing a playlist microservice stack to reduce latency variation during peak releases and to tighten their image supply chain across multiple AWS accounts.

Standardize image build and governance

Implement ECR repositories with scan-on-push and Amazon Inspector enhanced scanning. Add tag immutability and lifecycle policies to retain the latest N versions per branch and prune drift. Configure cross-Region/account replication from the build account to prod and staging accounts. Why: Inspector ensures continuous CVE coverage, immutability prevents tag hijacking, and replication localizes pulls to reduce deployment latency and blast radius.

Serve stateless APIs on ECS with Fargate

Define ECS task definitions with awslogs and FireLens for structured logs and metrics. Enable container healthCheck and align ALB target group health checks. Mount an EFS volume for shared read-only configuration via an access point. Run services on Fargate with capacity provider strategy mixing Fargate and Fargate Spot for cost efficiency. Why: Fargate removes node management and isolates tasks per-ENI; EFS avoids baking configs into images and supports atomic rollbacks of configuration.

Safe deployments with blue/green and automated tests

Switch ECS services to a CodeDeploy deployment controller. Configure two target groups on the ALB. Use a canary shift with AfterAllowTestTraffic to invoke a Lambda test runner that exercises critical endpoints within 5 minutes. Attach CloudWatch alarms on 5XX and p90 latency to trigger rollback. Why: CodeDeploy blue/green isolates risk, the test hook validates the green environment before full cutover, and alarms give automated, objective rollback.

Latency-sensitive operations on Lambda with stabilized cold starts

For a tokenization helper API, package the function as a ZIP with slim dependencies. Create a version/alias and enable provisioned concurrency sized to peak. Drive provisioned concurrency via Application Auto Scaling with a daily schedule that tracks release windows. Use CodeDeploy canary (10%/15 minutes) for alias-based traffic shifting tied to CloudWatch alarms. Why: Provisioned concurrency eliminates cold starts during surges; alias canaries enable gradual exposure with fast rollback.

Expose external APIs via API Gateway and secure private backends

Front the Lambda and ECS ALB with API Gateway. Use HTTP APIs for the Lambda proxy to minimize cost/latency. Use REST API for the ECS ALB path that needs request/response mapping and stage caching for heavy read endpoints. Apply WAF web ACLs and stage throttling; enable structured access logs. Why: Matching API types to needs optimizes cost and capabilities; caching reduces load; WAF and throttling add protection under event spikes.

Cross-account runtime pulls without internet

In runtime VPCs, add interface endpoints for ECR (api, dkr) and CloudWatch Logs, and an S3 gateway endpoint. Attach ECR repository resource policies to allow the prod account’s task execution roles to pull. Use a customer-managed KMS key with cross-account key policy for image encryption at rest. Why: Private image pulls avoid NAT costs and egress risks; explicit resource/key policies enforce least-privilege cross-account access.

This design reduces operational toil (no nodes to manage), provides deterministic latency via provisioned concurrency and ALB health–aligned rollouts, and enforces image provenance end-to-end with ECR scanning, replication, and immutability.

← Security · All domains · High Availability →

Practice these questions → · Timed practice on ExamRoll.io →