AWS ECS Fargate Interview Questions

With the Fargate launch type, AWS provisions and manages the compute infrastructure (the underlying EC2 instances/servers) for you. You specify the CPU and memory your task needs, and Fargate runs the containers without you having to provision, patch, or scale EC2 instances. You still manage your container images, IAM roles, and VPC/subnet networking. Contrast this with the EC2 launch type, where you register and manage your own container instances.

AWS Fargate is a serverless compute engine for containers. When you launch an ECS task on Fargate, AWS provisions and manages the underlying compute infrastructure on your behalf, so the component you no longer provision, patch, or scale is the EC2 instance (server) that hosts the containers. You specify the container-level CPU and memory requirements for the task, and Fargate handles the rest. This is the core distinction from the EC2 launch type, where you own and manage the cluster's EC2 instances directly.

This statement is true. AWS Fargate is a serverless compute engine for containers that works with Amazon ECS. You define each task's CPU and memory requirements, and Fargate allocates the necessary compute capacity and runs the task without you provisioning, patching, or scaling any EC2 instances. This serverless model is the defining difference between Fargate and the ECS EC2 launch type, where you manage the container instances yourself.

The statement is false. AWS Fargate is a serverless compute engine for containers. When used with Amazon ECS, you specify only the CPU and memory each task needs, and AWS provisions and manages the underlying compute infrastructure. There are no EC2 instances for you to manage, which is the defining difference from the EC2 launch type.

'Serverless' here means the servers that run your containers are abstracted away: with Fargate you never provision, patch, or scale the EC2 instances that host ECS tasks. You declare each task's vCPU and memory, and AWS allocates and manages the compute capacity behind the scenes. The term describes who operates the server infrastructure, not the absence of servers.

AWS Fargate is called 'serverless' because it abstracts away the underlying server infrastructure. Instead of launching and managing EC2 instances in your ECS cluster, you define the CPU and memory your task needs and AWS handles the rest. The question is open-ended and has no fixed set of options, so it remains a short-answer question.

Fargate is serverless compute for ECS: AWS owns and maintains the underlying host machines, so you never provision, patch, or scale the EC2 instances that run your containers. The other three remain your responsibility under Fargate: you still author the task definition, supply the container image, and assign the IAM task role that the containers use.

True. Fargate is a serverless compute engine: AWS provisions the underlying capacity on demand and bills you for the vCPU and memory configured for each task while it runs. Because there is no EC2 instance in your account to keep warm, there is no idle-host charge.

True. Fargate is the serverless compute option for ECS. You define the container image and the vCPU and memory your task needs, and AWS provisions the underlying infrastructure, handles host OS patching, and scales the capacity. You never have to launch or maintain EC2 instances yourself. The EC2 launch type, by contrast, requires you to manage those hosts.

Fargate is a serverless launch type, so there are no underlying EC2 instances to manage. AWS requires you to declare the task's total CPU and memory at the task-definition level, and the values must come from Fargate's fixed supported combinations (e.g., 0.5 vCPU / 1 GB, 1 vCPU / 2 GB, etc.). Specifying cpu and memory at the task level using Fargate-supported value combinations is correct. Mapping a hostPort for every containerPort defined in each container is wrong because Fargate enforces the awsvpc network mode, where hostPort is not used — the container port maps directly to the ENI. Defining a placementStrategy so Fargate can choose an optimal host is wrong because placement strategies are an EC2-launch-type concept for selecting which container instance to schedule on; Fargate provisioning is fully managed. Setting the privileged flag to true for containers that need elevated permissions is wrong because privileged containers are not supported on Fargate at all.

With the ECS EC2 launch type you provision, patch, and maintain the EC2 instances and their host operating system yourself. With the Fargate launch type AWS takes over that responsibility: it provisions the underlying compute capacity and manages (patches, secures, and scales) the host OS and virtualization layer, so you only specify per-task CPU and memory requirements. The expected answer should name the underlying servers/instances and/or the host operating system — not a network mode such as awsvpc, which is available in both launch types and is not itself a management responsibility AWS takes on.

Fargate tasks support only the awsvpc network mode. In this mode, ECS attaches a dedicated elastic network interface with its own private IP address to each task, so the task gets VPC-native networking and can use security groups directly. The other ECS network modes (bridge, host, and none) are not available on Fargate.

Fargate only supports the awsvpc network mode. That mode gives each task its own ENI with a dedicated private IP, so security groups and VPC routing are applied per task. The bridge and host network modes, which are commonly used with the EC2 launch type, are not available with Fargate because there is no shared host network namespace to attach to.

Fargate tasks require the awsvpc network mode; bridge, host, and none are not supported on Fargate. With awsvpc, each task receives its own ENI and private IP. Because the task must not have a public IP, it must be placed in a private subnet. To pull from ECR and reach the third-party API on the public internet, that private subnet needs a route through a NAT gateway (or NAT instance) in a public subnet. Setting the task definition networkMode to bridge and attaching a NAT gateway to the VPC is invalid because bridge is not supported by Fargate. Setting the task definition networkMode to host and enabling public IP assignment on the task is invalid because host is not supported by Fargate. Setting the task definition networkMode to none and configuring a VPC peering connection to a shared services VPC is invalid because none is not supported by Fargate and does not provide outbound connectivity. Setting the task definition networkMode to awsvpc and assigning each task an elastic network interface (ENI) in a private subnet with a route to a NAT gateway is the only configuration that satisfies all constraints.

Fargate supports only the awsvpc network mode, so a bridge-mode task definition must be changed to awsvpc. Under awsvpc, each task gets its own elastic network interface with a private IP address, so there is no shared host network namespace and no host-level port mapping to rely on. The bridge and host modes depend on the Docker daemon running on a host EC2 instance, which Fargate does not expose, so keeping either one is not possible. The none mode would leave the task with no network connectivity at all, so it cannot serve traffic.

Fargate mandates the awsvpc network mode, under which each task is assigned its own elastic network interface (ENI) with a private IP. AWS automatically provisions and manages these ENIs on Fargate, so there is no per-instance ENI constraint. On the EC2 launch type, however, each awsvpc task consumes one of the ENIs available to the host EC2 instance, so the maximum number of concurrently running awsvpc tasks is limited by that instance type's ENI limit.

AWS Fargate provisions and attaches a dedicated elastic network interface (ENI) for each running Fargate task. This ENI is placed in the subnets you select in your task definition or service configuration, and it receives a private IP address from that subnet's range. Because each task gets its own ENI, its networking (security groups, routing, and IP visibility) is isolated at the task level rather than shared on a host ENI as it would be with the EC2 launch type. A correct answer must name the ENI (elastic network interface) as the mechanism.

Fargate requires the awsvpc network mode, so each task gets its own elastic network interface in the subnets you specify. CPU and memory are set at the task level in the task definition, and the values must match one of the supported task-size combinations. Host network mode and privileged containers are not available on Fargate because there is no host instance you manage, so those two statements are false.

ECS Fargate uses two distinct IAM roles per task. The task execution role (specified via executionRoleArn) is assumed by the Fargate infrastructure (the ECS agent) to perform setup-time actions on behalf of the container: pulling the container image from ECR, retrieving secrets referenced in the container definition's secrets field from Secrets Manager to inject as environment variables, and writing logs to CloudWatch Logs via the awslogs log driver. The task role (specified via taskRoleArn) is assumed by the application code running inside the container at runtime, and is used for the application's own AWS API calls — in this case, reading and writing objects in S3. The statement that the task execution role must include ECR pull permissions, secretsmanager:GetSecretValue, and CloudWatch Logs write permissions; the task role must include S3 read/write permissions is correct because it assigns ECR, Secrets Manager, and CloudWatch Logs permissions to the execution role and S3 permissions to the task role. The statement that the task role must include all of the above permissions (ECR, Secrets Manager, CloudWatch Logs, and S3) because the container performs every operation is wrong because the task role does not handle image pulls, secret injection, or log shipping — those are infrastructure-side operations. The statement that the task execution role must include ECR and S3 permissions; the task role must include Secrets Manager and CloudWatch Logs permissions is wrong because S3 access is an application-level operation (task role), while Secrets Manager retrieval and CloudWatch logging are infrastructure-side (execution role). The statement that the task execution role must include only ECR pull permissions; the task role must include Secrets Manager, CloudWatch Logs, and S3 permissions is wrong because it omits Secrets Manager and CloudWatch Logs permissions from the execution role, which are required for the agent to inject the secret and ship logs.

Fargate supports only the awsvpc network mode. In awsvpc, each task gets its own ENI with a dedicated private IP and its own network namespace, so there is no shared host network namespace and no dynamic host port mapping as in bridge mode. The ALB target group must therefore use target type ip and register each task's ENI private IP on the container port. The instance target type applies only to EC2-backed ECS, where targets are host instance IDs reached through dynamic host ports. Registering host instances or an Auto Scaling group does not work for Fargate tasks, and tasks do not share the host network namespace.

Fargate supports only the awsvpc network mode, so every task gets a dedicated elastic network interface (ENI) with its own private IP address and attachable security groups. Because of this, bridge mode with dynamic host port mapping does not apply, since that is an EC2-launch-type networking concept. host network mode is not supported on Fargate at all, because each task runs in its own isolated network namespace.

In awsvpc mode, every container in a task shares the task's single elastic network interface and therefore one network namespace. Containers in the same task can reach each other on localhost using the ports they listen on, just as containers do in host mode. Communication between different tasks is different: those tasks have separate ENIs and private IPs, so they must reach each other by IP address or through service discovery.

A strong answer must cover all four requirements with a consistent design. Fargate uses awsvpc networking, so each task gets its own ENI and private IP, which means private subnets must be sized for at least 80 IPs per deployment and headroom beyond that (a /24 gives 251 usable addresses). The ALB sits in public subnets behind an Internet Gateway, while tasks in private subnets reach the internet through a NAT Gateway and have no public IPs. Security groups should reference each other by group ID (ALB to task on 8080, and a task self-reference for gRPC) rather than hardcoding IPs, because task IPs change on every deployment. The target group must use target type 'ip' because awsvpc tasks are not registered by instance ID, and the protocol version should be set for gRPC. Cloud Map private DNS gives services a runtime way to find each other's task IPs without hardcoded addresses or a second internal ALB.

Fargate platform version 1.4.0 consolidated networking onto a single task ENI: all traffic—application data, ECR image pulls, CloudWatch Logs delivery, and Secrets Manager/SSM Parameter Store API calls—now egresses through the awsvpc ENI attached to the task and is therefore governed by the task's own security group and subnet route table. In platform version 1.3.0, Fargate provisioned additional Fargate-managed ENIs for these control-plane operations; those ENIs were not subject to the task's security group, so a restrictive egress rule that only allowed TCP 443 to the ALB would still permit image pulls and secret fetches. Under 1.4.0, the same restrictive rule blocks outbound 443 to ECR and Secrets Manager endpoints (which are not the ALB), producing the ResourceInitializationError. The claim that platform version 1.4.0 introduced stricter IAM evaluation for task execution roles, requiring an explicit sts:AssumeRole permission that 1.3.0 did not enforce, is wrong because no new sts:AssumeRole requirement was introduced. The claim that platform version 1.4.0 mandates VPC endpoints for ECR and Secrets Manager when tasks run in private subnets, whereas 1.3.0 could route these calls through the NAT Gateway transparently, is wrong because 1.4.0 can still use a NAT Gateway; VPC endpoints are an optimization, not a requirement—the real blocker is the security group, not the route. The claim that platform version 1.4.0 changed the default Docker network mode from bridge to awsvpc for Fargate tasks, causing the task security group to apply to traffic that was previously unfiltered, is wrong because Fargate has always required awsvpc network mode; 1.4.0 did not change the Docker network mode.

This is an open design question, so it stays a short-answer item graded against its keywords rather than a single keyed choice. A strong answer must show Fargate-specific depth: awsvpc gives each task its own ENI, which makes per-tenant isolation a network-layer control enforced by subnets and security groups. It must pick a cost mechanism that does not hurt availability, namely Fargate Spot via a capacity provider strategy paired with SIGTERM draining, deregistration delay, and healthCheckGracePeriodSeconds, plus Compute Savings Plans for the on-demand baseline. Discovery should use Cloud Map, observability should use Container Insights and FireLens, and security should separate the execution role from the task role and inject Secrets Manager secrets through the task definition. The answer must also name the trade-offs it accepts, such as Spot interruption risk and subnet sizing overhead.