Question 1

What is Amazon ECS?

Accepted Answer

Elastic Container Service is AWS's native container orchestrator. You define tasks in a task definition, run them as standalone tasks or as a service that maintains a desired count behind a load balancer, on either EC2 capacity you manage or Fargate serverless capacity. It integrates directly with IAM, VPC, ALB and CloudWatch. The framing to give is that ECS trades Kubernetes's portability and ecosystem for a much simpler operational model with deep AWS integration. That is a legitimate engineering trade-off, and saying so is better than treating Kubernetes as automatically superior.

Question 2

What is the difference between ECS and EKS?

Accepted Answer

ECS is AWS-proprietary, simpler to operate, with no control plane to manage and native AWS integration. EKS is managed Kubernetes — you get the full Kubernetes API, ecosystem and portability, at the cost of more concepts, a control-plane charge, version upgrades and a steeper learning curve. The decision criterion is team and portability, not capability: choose EKS if you have Kubernetes expertise, need its ecosystem, or want workloads portable across clouds; choose ECS if the team is small and everything is on AWS. Naming the control-plane hourly charge for EKS is the concrete cost difference.

Question 3

What is AWS Fargate?

Accepted Answer

Fargate is serverless compute for containers, used by both ECS and EKS. You specify CPU and memory per task or pod and AWS provisions the underlying capacity — there are no EC2 instances to patch, scale or bin-pack. Billing is per vCPU-second and GB-second of allocated resources. The trade-off is cost per unit versus operational burden: Fargate costs more per vCPU-hour than a well-utilised EC2 instance, but you pay for exactly what you request and eliminate node management. For low utilisation or spiky workloads it is often cheaper overall.

Question 4

When would you choose EC2 launch type over Fargate?

Accepted Answer

When you need GPUs or specialised instance types, very large or unusual CPU-memory ratios, privileged containers or host-level access, daemon-style workloads on every host, sustained high utilisation where reserved EC2 is cheaper, or persistent local storage beyond what Fargate offers. Naming a specific capability Fargate lacks is what makes this answer concrete rather than a preference. The cost crossover is the other real driver: at consistently high utilisation with a Savings Plan, EC2 capacity is meaningfully cheaper per unit of compute.

Question 5

What is an ECS task definition?

Accepted Answer

A task definition is an immutable, versioned blueprint describing one or more containers: image, CPU and memory, port mappings, environment variables and secrets, logging configuration, volumes, the task role and the execution role. Revisions are created rather than edited. The immutability and revision model is what makes deployment and rollback clean — a service points at a revision, and rolling back is pointing at the previous one. The two-role distinction, task role versus execution role, is the follow-up interviewers usually ask.

Question 6

What is the difference between the ECS task role and the task execution role?

Accepted Answer

The task execution role is used by the ECS agent to pull the image from ECR, fetch secrets and write logs — it is infrastructure-level. The task role is assumed by the application code inside the container to call AWS APIs. They should be separate and minimally scoped. Conflating the two is the common mistake and it leads to giving application code the ability to pull any image or read any secret. Being able to state which role does what, and that the application should never use the execution role, is the point of the question.

Question 7

What ECS network modes exist?

Accepted Answer

awsvpc gives each task its own ENI with a private IP and security group — required for Fargate and recommended for EC2. bridge uses Docker's bridge with dynamic port mapping. host shares the host network stack. none disables networking. awsvpc is the modern default because it gives task-level security groups. Task-level security groups are the reason awsvpc matters: with bridge mode, all tasks on an instance share the instance's security group, so you cannot express per-service network policy. The constraint is ENI limits per instance, which caps task density.

Question 8

How does ECS service discovery work?

Accepted Answer

Through AWS Cloud Map, which registers task IPs in a Route 53 private hosted zone so services resolve each other by DNS name and records are updated as tasks start and stop. The alternative is ECS Service Connect, which provides a managed proxy with service-to-service discovery, retries and telemetry. Service Connect is the newer and generally better answer because DNS-based discovery suffers from client-side caching, so a client can keep resolving a terminated task. Naming that caching problem is what shows you have hit it in production.

Question 9

How do you scale an ECS service?

Accepted Answer

Service auto scaling adjusts the desired task count using target tracking on average CPU, average memory or ALB request count per target; step scaling on custom CloudWatch metrics; or scheduled scaling. On EC2 launch type you also need cluster capacity to scale, which capacity providers with managed scaling handle. The two-layer scaling on EC2 launch type is the point candidates miss: scaling tasks does nothing if there is no instance capacity to place them on. Capacity providers with managed scaling solve that, and Fargate removes the problem entirely.

Question 10

What is an ECS capacity provider?

Accepted Answer

A capacity provider tells ECS where to place tasks — a Fargate provider, a Fargate Spot provider, or an Auto Scaling group for EC2 capacity with managed scaling that adds and removes instances based on task demand. A capacity provider strategy can split tasks across providers by weight and base. The strategy is how you mix Fargate and Fargate Spot: a base of on-demand tasks for reliability plus a weighted share on Spot for cost. Managed scaling with a target capacity below 100% deliberately keeps spare room so tasks can start without waiting for an instance.

Question 11

What is Fargate Spot?

Accepted Answer

Fargate Spot runs tasks on spare capacity at a large discount, with two minutes of notice before interruption via a SIGTERM and a task state change event. It suits fault-tolerant, restartable workloads and can be mixed with on-demand Fargate through a capacity provider strategy. The design requirement is handling SIGTERM and being safely restartable, and the mixing strategy — a base of on-demand plus a weighted Spot share — is what makes it usable for services rather than only batch. Fargate Spot is Linux-x86 only, which is a real constraint.

Question 12

What is Amazon EKS and what does AWS manage?

Accepted Answer

EKS is managed Kubernetes: AWS runs the control plane — API server, etcd, scheduler, controller manager — across multiple AZs, handles its availability and patching, and charges an hourly cluster fee. You manage worker capacity via managed node groups, self-managed nodes, Fargate profiles or Auto Mode. The compatibility point is that EKS runs upstream Kubernetes, so standard manifests, Helm charts and operators work unchanged, which is the portability argument. Naming EKS Auto Mode, which manages nodes and core add-ons for you, shows currency.

Question 13

What is an EKS managed node group?

Accepted Answer

A managed node group provisions and manages EC2 worker nodes for you — creating the Auto Scaling group and launch template, handling graceful node drains during updates, and applying AMI updates on request — while you keep control over instance types, scaling bounds and taints. The graceful drain during upgrade is the operational value: nodes are cordoned and drained respecting PodDisruptionBudgets rather than terminated abruptly. Self-managed nodes give more control but you implement that lifecycle yourself.

Question 14

What is IRSA and what problem does it solve?

Accepted Answer

IAM Roles for Service Accounts maps a Kubernetes service account to an IAM role via an OIDC provider registered for the cluster, so pods get temporary AWS credentials scoped to that role. Without it, pods inherit the node instance role, meaning every pod on the node shares the same AWS permissions. The node-role inheritance problem is the substance: the least-privileged pod would otherwise have the same access as the most privileged. EKS Pod Identity is the newer, simpler alternative that avoids the OIDC trust policy complexity, and naming it shows currency.

Question 15

How does the Kubernetes Cluster Autoscaler differ from Karpenter?

Accepted Answer

The Cluster Autoscaler scales predefined node groups up and down when pods cannot be scheduled. Karpenter provisions nodes directly from EC2 based on pending pod requirements, choosing instance types and sizes dynamically, consolidating underutilised nodes, and typically responding faster with better bin-packing. Karpenter's consolidation — actively replacing several underused nodes with fewer better-sized ones — is the cost feature that the Cluster Autoscaler lacks. It is now the recommended approach on EKS and is a strong signal of current knowledge.

Question 16

What is Amazon ECR?

Accepted Answer

Elastic Container Registry is AWS's managed container image registry with per-repository IAM, image scanning for vulnerabilities, lifecycle policies to expire old images, immutable tags, cross-region and cross-account replication, and a pull-through cache for upstream public registries. Two features worth naming: immutable tags, which prevent a tag being moved so a deployed digest cannot silently change; and the pull-through cache, which protects builds from Docker Hub rate limits and outages while bringing third-party images under your scanning and policy.

Question 17

How do you handle secrets in ECS and EKS?

Accepted Answer

In ECS, reference Secrets Manager or Parameter Store values in the task definition so the execution role fetches them at start and injects them as environment variables. In EKS, use the Secrets Store CSI driver with the AWS provider to mount secrets as files, with IRSA controlling access. Avoid plain environment variables in the definition. The Kubernetes-specific point is that native Secrets are only base64-encoded in etcd unless you enable envelope encryption with KMS, so describing them as encrypted is wrong. Preferring Secrets Manager with the CSI driver keeps rotation and audit in one place.

Question 18

How do you expose a service running on ECS or EKS?

Accepted Answer

On ECS, register the service with an Application Load Balancer target group, with awsvpc mode giving IP targets. On EKS, the AWS Load Balancer Controller provisions an ALB for an Ingress or an NLB for a Service of type LoadBalancer, using IP target mode to route directly to pods. IP target mode is the detail that matters: it routes to pod IPs directly rather than through a node port, removing a hop and giving accurate health checks. Naming the AWS Load Balancer Controller rather than the in-tree cloud provider is the current answer.

Question 19

How do you do a zero-downtime deployment on ECS?

Accepted Answer

Rolling update with minimumHealthyPercent and maximumPercent controlling surge and availability, requiring a load-balancer health check and a deregistration delay longer than the slowest request, plus the application handling SIGTERM. For stronger control, CodeDeploy blue/green shifts traffic between two target groups with automatic rollback on alarm. The SIGTERM requirement is the application-side half people forget: without graceful shutdown, every deploy and every scale-in drops in-flight requests. Blue/green with CodeDeploy adds a validation hook and instant rollback, which is what regulated environments want.

Question 20

What is AWS App Runner?

Accepted Answer

App Runner builds and runs containerised web applications and APIs directly from source or a container image, handling load balancing, TLS, autoscaling including scale to zero, and deployment, with no infrastructure configuration at all. It sits above ECS Fargate in abstraction, comparable to Cloud Run. The trade-off is limited control — no sidecars, restricted networking options and fewer knobs — so it suits straightforward web services and not complex architectures.

Question 21

What is the difference between an ECS task and a service?

Accepted Answer

A task is one running instantiation of a task definition, which may run once and exit — suitable for batch jobs. A service maintains a desired number of tasks, replaces failed ones, integrates with a load balancer, and handles rolling deployments. Using RunTask for batch and a service for long-running workloads is the distinction. Scheduled tasks via EventBridge are the ECS answer to cron, which is worth naming since people otherwise reach for a Lambda that then hits the 15-minute limit.

Question 22

How does logging work for containers on AWS?

Accepted Answer

ECS uses log drivers configured in the task definition — awslogs sends stdout and stderr to CloudWatch Logs, awsfirelens routes through Fluent Bit to any destination such as OpenSearch, S3 or a third party. On EKS, Fluent Bit as a DaemonSet or the CloudWatch Container Insights add-on collects node and pod logs. FireLens is worth naming because CloudWatch Logs ingestion is expensive at high volume, and routing to S3 or a cheaper destination is a real cost decision. Structured JSON logging is the practice that makes any of these searchable.

Question 23

How do you monitor containers on AWS?

Accepted Answer

Container Insights collects cluster, service, task and pod-level metrics for both ECS and EKS. CloudWatch metrics cover service CPU and memory utilisation and running task count. For EKS, Amazon Managed Service for Prometheus with Managed Grafana handles application metrics. Alert on task or pod restart rate, pending placement, and SLO burn rate. Alerting on tasks failing to place — insufficient capacity, no matching instance, ENI limits — is the specific signal that catches scaling problems before users do. Restart rate is the other, since a crash-looping container can hide behind a healthy desired count.

Question 24

An ECS task fails to start. How do you diagnose it?

Accepted Answer

Read the stopped-task reason in the console or API, which usually names the cause directly: image pull failure from a missing execution role permission or wrong ECR path, insufficient CPU or memory on any instance, no ENI capacity in awsvpc mode, a failed health check, or a container exiting immediately. Then check the container logs for exit codes. The stopped reason field is the single most useful thing and many candidates never mention it. ENI exhaustion in awsvpc mode is the non-obvious one — instances have a limited number of ENIs, which caps task density independently of CPU and memory.

Question 25

A pod is stuck in Pending on EKS. What do you check?

Accepted Answer

kubectl describe pod and read the Events. Usual causes are insufficient CPU or memory on any node, a node selector, affinity or taint no node satisfies, an unbound PersistentVolumeClaim, or IP address exhaustion in the VPC CNI. Check the autoscaler or Karpenter logs for why capacity was not added. IP exhaustion is the EKS-specific cause: the VPC CNI assigns real VPC IPs to pods, so a small subnet limits pod count. Prefix delegation, which assigns /28 prefixes rather than individual IPs, is the mitigation and is a strong detail to name.

Question 26

How does the Amazon VPC CNI work and what is its main constraint?

Accepted Answer

The VPC CNI assigns pods real IP addresses from the VPC subnet via ENIs attached to the node, so pods are routable within the VPC and security groups and flow logs apply directly. The constraint is IP consumption — pod density per node is limited by ENIs and IPs per instance type, and subnets can exhaust. Prefix delegation dramatically increases density by allocating /28 prefixes per ENI instead of single addresses. Security groups for pods is the other feature worth naming, since it allows per-pod network policy enforced by AWS rather than by an overlay.

Question 27

How do you upgrade an EKS cluster safely?

Accepted Answer

Check deprecated API usage against the target version first; upgrade the control plane, then core add-ons — VPC CNI, CoreDNS, kube-proxy — then node groups, respecting the version skew policy. Use managed node groups so drains respect PodDisruptionBudgets, test in a non-production cluster, and stay within the supported version window. Checking deprecated APIs before upgrading is the step that prevents workloads breaking, and EKS surfaces it through cluster insights. Falling out of the supported window forces an extended-support charge and eventually an unplanned upgrade, which is worse than a planned one.

Question 28

What is a PodDisruptionBudget and why does it matter on EKS?

Accepted Answer

A PDB declares the minimum number or percentage of pods that must remain available during voluntary disruptions such as node drains during upgrades or scale-in. Managed node groups and Karpenter respect it, so without one an upgrade can evict all replicas of a service simultaneously. The counterpart failure is a PDB that is too strict — minAvailable equal to the replica count — which blocks drains entirely and stalls a cluster upgrade indefinitely. That the same mechanism can cause both an outage and a stuck upgrade is what makes it a good question.

Question 29

What are requests and limits, and what happens when a container exceeds each?

Accepted Answer

A request is what the scheduler reserves; a limit is the runtime ceiling. Exceeding a CPU limit causes throttling — the container is slowed. Exceeding a memory limit causes an OOM kill and restart, because memory is incompressible. On Fargate you specify task-level CPU and memory rather than per-container requests. The CPU-versus-memory asymmetry is the substance. Exit code 137 in a restarting container means OOM-killed, and recognising that immediately is what shows operational experience rather than theory.

Question 30

What is Amazon ECS Anywhere and EKS Anywhere?

Accepted Answer

ECS Anywhere lets you register on-premises or other-cloud servers as ECS capacity managed by the AWS control plane. EKS Anywhere is a distribution you run entirely on your own infrastructure, with EKS Connector providing visibility from the AWS console. The driver is a consistent operating model across a hybrid estate — one control plane and one deployment mechanism rather than two. The distinction matters: ECS Anywhere keeps the control plane in AWS, while EKS Anywhere runs everything locally.

Question 31

How do you optimise container costs on AWS?

Accepted Answer

Right-size task CPU and memory from actual utilisation, since over-requesting is pure waste on Fargate and hurts bin-packing on EC2; use Fargate Spot or EC2 Spot for fault-tolerant work; use Graviton-based tasks for better price-performance; apply Compute Savings Plans, which cover Fargate as well as EC2; enable Karpenter consolidation on EKS; and scale to zero where the workload allows. That Compute Savings Plans cover Fargate and Lambda as well as EC2 is the detail people miss, and it makes committing far less risky when the architecture is changing. Graviton on Fargate is typically a straightforward 20% saving for interpreted runtimes.

Question 32

What is the difference between a sidecar and an init container?

Accepted Answer

An init container runs to completion before the application container starts, used for setup such as running migrations or waiting for a dependency. A sidecar runs alongside for the lifetime of the pod or task, used for logging agents, proxies or credential helpers. ECS supports both patterns through container dependencies in the task definition, using conditions like START, COMPLETE and HEALTHY. Knowing that ECS can express ordering, rather than assuming it is a Kubernetes-only concept, is a good signal.

Question 33

What is AWS App Mesh or a service mesh, and when is it worth it?

Accepted Answer

A service mesh provides mutual TLS, fine-grained traffic management such as canaries and retries, and consistent telemetry through sidecar proxies. It is worth the complexity when you have enough services that per-service implementations of these have become inconsistent — typically tens of services across multiple teams. The honest cost is sidecar latency, memory per pod and a substantial operational learning curve. For a handful of services a mesh is a net negative, and ECS Service Connect covers much of the discovery and telemetry need with far less complexity.

Question 34

How do you handle persistent storage for containers on AWS?

Accepted Answer

EFS for shared POSIX filesystems mountable by many tasks or pods simultaneously, supported by both ECS and Fargate. EBS via the CSI driver on EKS for single-writer block storage. FSx for high-performance or Windows workloads. S3 for object data through the SDK or Mountpoint. Fargate ephemeral storage is temporary. The ReadWriteOnce constraint on EBS is what forces EFS when several replicas need shared read-write access. Naming that a zonal EBS volume pins a pod to an AZ — quietly undermining multi-AZ availability — is the detail that shows real experience.

Question 35

What is the difference between ECS Service Connect and a load balancer?

Accepted Answer

A load balancer is a separate network component with its own endpoint, health checks and cost, suited to ingress. Service Connect provides service-to-service communication inside the cluster through a managed sidecar proxy, with logical service names, automatic retries, connection draining and per-service telemetry, without provisioning load balancers between internal services. The cost and simplicity benefit is real: an internal load balancer per service adds hourly charges and configuration for every service pair. Service Connect also gives client-side load balancing and retries, which DNS-based discovery does not.

Question 36

How do you secure containers on AWS?

Accepted Answer

Scan images in ECR and block deployment of vulnerable ones; use minimal or distroless base images; run as a non-root user with a read-only root filesystem; give each task or pod its own least-privileged role via task roles or IRSA; use awsvpc mode with task-level security groups; keep secrets in Secrets Manager; and enable GuardDuty runtime monitoring for containers. Per-task IAM is the highest-value item because it prevents the workload from having more AWS access than it needs — the container security equivalent of least privilege. GuardDuty runtime monitoring is the current detection layer worth naming.

Question 37

What is a container health check and how does it differ from an ALB health check?

Accepted Answer

A container health check defined in the task definition or a Kubernetes liveness probe determines whether the container itself is healthy, and failing it restarts the container. An ALB health check determines whether the target should receive traffic, and failing it removes the target without restarting anything. The dangerous misconfiguration is a liveness probe that checks a downstream dependency: when the database blips, every replica restarts simultaneously, turning a partial outage into a total one. Liveness should test the process; readiness is where dependency checks belong.

Question 38

How would you migrate a monolith running on EC2 to containers on AWS?

Accepted Answer

Containerise it first and run it unchanged on ECS Fargate if it is stateless and HTTP-based. Then fix what breaks: externalise session state to ElastiCache, local file writes to S3 or EFS, and configuration to Parameter Store; add graceful shutdown; and shorten startup. Only then consider decomposition — the container move and the decomposition are separate projects. Separating "containerise" from "break into microservices" is the mature answer, because teams that attempt both simultaneously usually fail. Choosing ECS Fargate as the lowest-friction first landing place, rather than starting with Kubernetes, is the pragmatic sequencing.

Question 39

What is the ECS agent and what happens if it stops?

Accepted Answer

The ECS agent runs on each EC2 container instance, registers it with the cluster, receives task placement instructions and reports task state. If it stops, the instance is marked disconnected: running tasks keep running but ECS cannot place new tasks on it, stop tasks, or report accurate state. The symptom — tasks appear healthy but deployments will not progress on that instance — is confusing unless you know to check agent connectivity. Using the ECS-optimised AMI, which runs the agent under a supervisor that restarts it, avoids most of these cases.

Question 40

Design a production container platform on AWS for 30 microservices.

Accepted Answer

Separate accounts per environment with a shared VPC or Transit Gateway. EKS with managed node groups or Karpenter, or ECS Fargate if the team prefers simplicity, in private subnets across three AZs. IRSA or task roles per service with least privilege. ECR with scanning, immutable tags and lifecycle policies, plus a pull-through cache. AWS Load Balancer Controller with an ALB per environment routing by host or path, WAF attached. Secrets from Secrets Manager, config from Parameter Store. GitOps or CodePipeline for delivery with blue/green and automated rollback. Container Insights and Managed Prometheus for observability with SLO-based alerting, PodDisruptionBudgets, and Compute Savings Plans plus Spot for the burst capacity. The closing scenario. The senior markers are per-service IAM rather than a shared node role, immutable image tags with digest-based deployment, and sizing capacity so an AZ loss is survivable — the three places real platforms most often fall short.

AWS ECS, EKS & Fargate Interview Questions and Answers

How to use this set