AWS Compute and Networking Questions

Covers design and operational knowledge of Amazon Web Services compute and network components. Candidates should understand Amazon Elastic Compute Cloud instances including instance families, sizing considerations, and pricing models such as on demand, reserved, and spot instances. Knowledge of Amazon Machine Images and launch templates, network interfaces, security groups, route tables, and Virtual Private Cloud architecture including public and private subnets, NAT gateways, and peering is expected. Expect questions on load balancing options including Application Load Balancer and Network Load Balancer, autoscaling groups and policies for availability and cost optimization, and hybrid connectivity patterns such as VPN and Direct Connect. Candidates should also be able to reason about high level multi tier application architectures on AWS, security and networking trade offs, and common infrastructure as code and automation approaches used to provision and manage these resources.

EasyTechnical

123 practiced

Explain how an Auto Scaling Group (ASG) operates. Describe instance lifecycle states, the role of health checks and lifecycle hooks, differences between target-tracking, step-scaling, and simple scaling policies, and how ASGs integrate with load balancers and Launch Templates.

Sample Answer

An Auto Scaling Group (ASG) automatically manages a fleet of EC2 instances to maintain desired capacity and availability by launching or terminating instances based on policies and health. For an SRE, ASGs are core building blocks for scalable, resilient infrastructure.

Instance lifecycle states (common):- Pending → Pending:Wait (if lifecycle hook) → InService — instance is starting and then serving traffic.- Standby — removed from rotation but retained.- Terminating:Wait (if lifecycle hook) → Terminating → Terminated.- Others: Pending:Proceed / Terminating:Proceed for hooks.

Health checks & lifecycle hooks:- Health checks: EC2 status checks and ELB/ALB target-group health checks. ASG uses configured checks to mark instances Unhealthy and replace them automatically.- Lifecycle hooks: pause instance transitions (launch or terminate) to run custom actions (bootstrap, drain connections, run config management, snapshot logs). Hooks send notifications to SNS/SQS/Lambda and must be completed or timed out; they’re essential for safe drain/cleanup and zero-downtime deploys.

Scaling policy types:- Target-tracking: simplest for SREs—ASG adjusts capacity to maintain a metric at a target (e.g., keep average CPU at 40% or maintain ALB request count per target). Good for steady-state SLO-driven scaling.- Step-scaling: reacts to CloudWatch alarms with stepped adjustments (e.g., +2 instances if CPU >70% for 5m, +5 if >90%). Useful for handling different severity levels and sudden load increases.- Simple scaling (legacy): single alarm triggers a fixed change with a cooldown. Less flexible; mostly replaced by target-tracking or step policies.

Integration with load balancers and Launch Templates:- Load balancers: ASG registers instances with ELB/ALB target groups; ALB health checks are preferred for application-level readiness. ASG respects target-group health before marking InService. During termination, with lifecycle hooks, you can deregister and wait for connection drain.- Launch Templates: store AMI, instance type, EBS, security groups, IAM role, user-data, and networking. ASGs reference Launch Templates (or Launch Configs) for consistent, versioned instance launches; you can perform instance refreshes or controlled rollouts by updating the template and triggering replacements.

SRE best practices:- Use ALB health checks and lifecycle hooks to drain and avoid request loss.- Prefer target-tracking for SLO-aligned metrics; use step-scaling for burst control.- Configure cooldowns and instance warm-up to avoid flapping.- Enable termination protection selectively and use capacity rebalance/instance refresh for graceful rolling updates.- Monitor scaling actions, CloudWatch alarms, and include observability for boot failures and lifecycle hook timeouts.

HardTechnical

78 practiced

Discuss security and operational implications of using AWS Resource Access Manager (RAM) to share subnets or VPC resources across accounts in a centralized networking model. How would you ensure least privilege, maintain isolation, detect misconfigurations, and audit inter-account traffic when using Transit Gateway and shared subnets?

Sample Answer

Overview: Sharing VPC subnets or a centralized Transit Gateway via AWS RAM reduces VPC sprawl and simplifies IP management, but it expands blast radius and demands strong controls for least privilege, isolation, detection, and auditing. As an SRE I’d treat RAM-sharing as a cross-account platform service with strict guardrails, automation, and observability.

Least privilege- Use IAM and RAM principals minimally: create one dedicated “networking-platform” AWS Organization unit and a small set of IAM roles/principals allowed to accept or manage resource shares. Avoid sharing broad account or root principals.- Use Service Control Policies (SCPs) to restrict who can create/accept shares and disallow creating attachments that bypass approved Transit Gateway route tables.- Tag-based and condition-based policies: require tags like Owner=Networking and allow AcceptShare only if resource tags match.- Limit API scope: create an automation pipeline (CI/CD) that performs share/attach actions; human approvals via IAM role assumption, not direct console access.

Maintain isolation- Centralize routing with Transit Gateway route tables and enforce per-caller route tables to limit which attached accounts can reach each other. Use route table associations and propagation carefully (no default “propagate everything”).- Keep security boundaries: shared subnets should host only network services (NAT, firewalls, Transit Gateway attachments). Avoid sharing subnets that host tenant workloads — prefer VPC sharing for ENIs only when necessary and document ownership.- Use Security Groups and NACLs owned by the resource-account (not the consumer) where possible; require consumers to request service endpoints or use specific peering patterns.- Leverage AWS Network Firewall or third-party NGFW in the shared VPC to enforce East-West policies between accounts.

Detect misconfigurations- Enforce AWS Config rules: detect open route propagation, unauthorized Transit Gateway attachments, VPC peering/VPNs created outside approved patterns, or changes to shared-subnet tags.- Automate drift detection: Periodic scans comparing actual route tables, security groups, and RAM shares against a desired-state manifest stored in Git; trigger remediation playbooks (Lambda/Step Functions) on drift.- Use GuardDuty for cross-account threat detection and configure housekeeping to forward findings to a central security account.- Monitor CloudTrail management events for AcceptResourceShareInvitation, CreateTransitGatewayRoute, ModifyTransitGateway, and attachment operations; alert on unexpected principals.

Audit inter-account traffic- Enable VPC Flow Logs at shared-subnet ENI level and for Transit Gateway attachments; send logs to a centralized, immutable S3 bucket and stream to a SIEM (e.g., ELK, Splunk) for enrichment and long-term retention.- Use Transit Gateway Flow Logs (CloudWatch Logs) and AWS Network Manager telemetry where available to capture inter-VPC traffic patterns.- For deeper inspection, mirror traffic using Traffic Mirroring to IDS/packet-capture appliances (in shared subnets) for high-risk flows.- Correlate Flow Logs + CloudTrail + GuardDuty in the SIEM and create detections for lateral movement, unexpected cross-account flows, data exfil patterns, or policy violations; integrate with PagerDuty for SRE on-call alerts.

Operational controls & automation- Provision sharing via IaC (Terraform/CloudFormation) modules, with pull-request reviews and automated policy checks (terratest, Conftest).- Implement automated acceptance workflow: only the networking account runs the accept operation; consumer accounts cannot self-attach without an approved ticket.- Periodic audits: run least-privilege reviews of IAM roles that can manage RAM; monthly scans of route tables and security groups; quarterly tabletop exercises for cross-account incident response.

Trade-offs & mitigations- Centralization simplifies ops but increases dependency: mitigate with SLOs for the networking platform, runbooks, and redundancy (multi-AZ, multi-region).- Flow Logs and mirroring increase cost and storage: sample or scope logs to sensitive subnets and rely on aggregated metrics for the rest.

Example quick checklist to present in interview:- SCP + IAM + tag conditions to restrict RAM operations- Transit Gateway route table per customer group; no global propagation- Centralized NGFW + Traffic Mirroring for inspection- VPC Flow Logs + Transit Gateway logs → central SIEM- AWS Config rules & automated remediation playbooks- IaC + PR workflow for any share/attach operationThis combination preserves least privilege, maintains logical isolation, surfaces misconfigurations quickly, and provides an auditable trail of inter-account traffic.

MediumTechnical

83 practiced

Write a concise Terraform (HCL) snippet that demonstrates creating an aws_autoscaling_group with a mixed_instances_policy that uses a launch template, sets on_demand_base_capacity to 2, and uses spot allocation strategy 'capacity-optimized'. You do not need full provider blocks, but include the main resource configuration pieces and key attributes.

Sample Answer

To create an Auto Scaling Group that uses a launch template and a mixed_instances_policy with on-demand base capacity 2 and spot allocation strategy "capacity-optimized", you can use the following concise Terraform HCL snippet.

hcl

resource "aws_launch_template" "app" {
  name_prefix   = "app-lt-"
  image_id      = "ami-0123456789abcdef0"
  instance_type = "t3.medium"

  lifecycle {
    create_before_destroy = true
  }

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name = "app-instance"
      Env  = "prod"
    }
  }
}

resource "aws_autoscaling_group" "app_asg" {
  name                      = "app-asg"
  min_size                  = 2
  max_size                  = 10
  desired_capacity          = 4
  vpc_zone_identifier       = ["subnet-aaa", "subnet-bbb"]
  health_check_type         = "EC2"
  launch_template {
    id      = aws_launch_template.app.id
    version = "$Latest"
  }

  mixed_instances_policy {
    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.app.id
        version            = "$Latest"
      }
    }

    instances_distribution {
      on_demand_allocation_strategy            = "prioritized"
      on_demand_base_capacity                  = 2
      on_demand_percentage_above_base_capacity = 50
      spot_allocation_strategy                 = "capacity-optimized"
      spot_instance_pools                      = 2
    }
  }

  tag {
    key                 = "Name"
    value               = "app-asg"
    propagate_at_launch = true
  }
}

Key points:- on_demand_base_capacity = 2 reserves two on-demand instances; remaining capacity can be spot.- spot_allocation_strategy "capacity-optimized" selects the most available spot pools for lower interruption risk.Edge cases:- Ensure IAM/permissions, subnets, and AMI are correct.- Consider lifecycle and termination policies when mixing instance types.Alternative:- Use launch_template overrides to specify multiple instance_types for diversified spot pools.

MediumTechnical

72 practiced

An EKS cluster using the AWS VPC CNI begins failing to create new pods due to IP exhaustion. Explain root causes including ENI/IP limits per instance, difference between ENI-per-pod and prefix-delegation models, and mitigation strategies such as adding secondary CIDRs, enabling prefix delegation, switching CNI, or adjusting node sizes.

Sample Answer

Root cause summary- The AWS VPC CNI assigns every pod an IP from the VPC. Pod creation fails when nodes run out of attachable IP addresses. Two main resource limits cause exhaustion: number of ENIs (elastic network interfaces) attachable to an EC2 instance and number of IPv4 addresses per ENI (both depend on instance type and subnet sizing).

ENI/IP limits (practical impact)- Each instance type has a max ENIs and max IPv4 addresses per ENI (example: t3.medium allows 3 ENIs and 6 IPv4 addresses per ENI → ~12 pod IPs). The total pod IP capacity per node = sum of (IPs per ENI) across attachable ENIs minus the primary address(s) used by the host. Exceed that and kubelet can't assign IPs for new pods.

ENI-per-pod vs prefix-delegation- ENI-per-pod (classic AWS VPC CNI): CNI attaches additional ENIs to host and allocates one or more IPs per ENI for pods. Limited by ENI count and IPs-per-ENI; many small instance types exhaust quickly.- Prefix Delegation (PD): CNI requests larger /28-/24 prefixes from the subnet and delegates many IPs to a single ENI. That greatly increases pod density per node and reduces ENI exhaustion because each ENI can hold many secondary IPs in a contiguous block.

Mitigation strategies- Add secondary CIDRs: Expand VPC address space (add secondary CIDR or move to larger CIDR) so there are more IPs available overall; required when VPC subnets are saturated.- Enable prefix delegation: In EKS, enable awsvpc CNI prefix-delegation (requires VPC and AMI/kernel support). This increases pod-per-node capacity without changing instance types.- Switch CNI or use alternative networking: Use CNI plugins that implement NAT or overlay (Calico in IP-in-IP, Cilium with tunneling) so pods use an internal CIDR and do not consume VPC IPs. Trade-offs: added hop, possible MTU/tuning, observability differences.- Adjust node sizes / instance types: Move to instances with higher ENI/IP limits (e.g., m5.2xlarge vs t3.medium) or use fewer larger nodes to raise overall capacity.- Autoscaling and bin-packing: Use cluster-autoscaler tuned to node sizes, and use PodDensity limits or affinity to avoid hotspotting.- Short-term fixes: Cordon nodes with no capacity, drain and replace with larger ones; delete unused pods/Daemons; scale down low-priority workloads.

Operational recommendations- Monitor IP consumption: alert on per-subnet available IPs, per-node ENI/secondary IP usage, and CNI logs. Metrics: aws_vpc_cni_assigned_ips, available_ips in subnet, node pod.capacity.- Capacity planning: map instance types → pod IP capacity, and use that for autoscaling/instance selection.- Test PD and alternate CNI in staging for observability and performance impacts before production cutover.

Example action plan1. Quickly add nodes with a larger instance type and cordon small nodes.2. Add a secondary VPC CIDR if subnets exhausted.3. Enable prefix-delegation on CNI and migrate workload, or evaluate overlay CNI for long-term if VPC-IP model unacceptable.4. Implement monitoring and alerts to prevent recurrence.

EasyTechnical

83 practiced

Describe the primary differences between Application Load Balancer (ALB), Network Load Balancer (NLB), and Classic Load Balancer (CLB). Include appropriate use cases for HTTP(S), TCP/UDP, TLS termination, client IP preservation, and for scenarios requiring advanced Layer 7 routing.

Unlock Full Question Bank

Get access to hundreds of AWS Compute and Networking interview questions and detailed answers.

Join thousands of developers preparing for their dream job.