AWS Interview Questions

Identity and Access Management Strategy

In a technical interview, you will likely be asked how to securely manage service-to-service communication. The foundational principle here is the 'Principle of Least Privilege,' which dictates that every identity must possess only the minimum permissions necessary to perform its intended task. When you configure IAM roles for compute instances, you must avoid using hardcoded security keys, as these are static and prone to leakage. Instead, leverage instance profiles that dynamically inject temporary security tokens into the environment. This works by having the service assume a role, which grants a temporary STS session token that automatically rotates. This decoupling of credentials from your application logic ensures that even if an underlying process is compromised, the blast radius is restricted to the specific actions authorized by that role. Always prioritize managed policies over inline policies for better versioning and reusability across your environment.

# Example of attaching an IAM Role to an instance profile via infrastructure code
resource "aws_iam_role" "app_role" {
  name = "web_server_role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{ Action = "sts:AssumeRole", Effect = "Allow", Principal = { Service = "ec2.amazonaws.com" } }]
  })
}

Designing for High Availability

High availability is not a checkbox but a structural design choice meant to eliminate single points of failure. When interviewers ask about designing for uptime, focus on how compute and database resources are distributed across multiple Availability Zones (AZs). By spreading resources across physically isolated data centers, you ensure that a local power or network issue in one facility does not take your entire application offline. To achieve this, you must use load balancers that sit in front of your auto-scaling groups, actively performing health checks to identify and shift traffic away from unhealthy nodes. The reason this works is that the control plane manages the health of the entire fleet, constantly reconciling the desired state with the actual state. When you architect for failure, you ensure that the system can automatically recover from localized outages without manual intervention, thereby maintaining service continuity for end users at all times.

# Defining an Auto Scaling Group across multiple subnets for resilience
resource "aws_autoscaling_group" "web_fleet" {
  vpc_zone_identifier = ["subnet-az1", "subnet-az2"]
  min_size            = 2
  max_size            = 5
  target_group_arns   = [aws_lb_target_group.main.arn]
}

Scalable Data Storage Patterns

Choosing the right storage architecture involves understanding the trade-offs between consistency, availability, and latency. Relational databases are the gold standard for transactional integrity, ensuring that complex queries remain performant through proper indexing and normalization. However, as your read load grows, you will reach the physical limits of a single primary node. The standard strategy here is to implement read replicas, which offload query pressure from the main database. This works because read replicas asynchronously replicate data, allowing the main instance to focus exclusively on write operations. When interviewers question how to handle massive write volumes, suggest horizontal partitioning or shifting to a NoSQL approach. By distributing the data across a partition key, you eliminate the bottleneck of a single disk or CPU. This pattern scales linearly with your data requirements, ensuring that your storage layer never becomes the primary constraint of your application performance.

# Provisioning an RDS instance with a read replica for improved read performance
resource "aws_db_instance" "primary" {
  allocated_storage = 20
  engine            = "postgres"
  instance_class    = "db.t3.medium"
}
resource "aws_db_instance" "replica" {
  replicate_source_db = aws_db_instance.primary.identifier
  instance_class      = "db.t3.medium"
}

Event-Driven Architecture

Transitioning from monolithic request-response cycles to event-driven architectures is a key indicator of seniority. The core objective is decoupling producers from consumers, which allows each part of your system to evolve independently. Using a message queue as an intermediary allows your application to handle traffic spikes by buffering incoming requests that the backend can then process at a controlled rate. The mechanism works by placing a persistent store between the service that sends the event and the worker that processes it, effectively smoothing out load spikes that would otherwise crash a synchronously coupled system. When you discuss this in an interview, emphasize how this pattern increases system fault tolerance; if the processing service fails, the messages remain safely queued until the service is restored, ensuring no data loss occurs during periods of instability.

# Creating a Simple Queue Service to buffer incoming requests
resource "aws_sqs_queue" "task_queue" {
  name                      = "processing-queue"
  message_retention_seconds = 86400 # Retain for 24 hours
  visibility_timeout_seconds = 30   # Time for worker to process
}

Security at the Network Perimeter

The final layer of defense for any architecture is the network perimeter. Interviewers will test your understanding of how to protect sensitive subnets. The secret is to use security groups as stateful firewalls around compute instances, while using Network Access Control Lists (NACLs) as stateless sub-level traffic filters. Security groups are stateful, meaning that if you allow an inbound request, the response is automatically permitted regardless of outbound rules. This works because the underlying infrastructure tracks the flow state of individual packets. Conversely, NACLs are stateless, meaning you must explicitly define both inbound and outbound rules for every traffic flow. By layering these defenses, you create a "defense-in-depth" strategy where the compromise of one perimeter does not lead to total system exposure. This structure provides fine-grained control over which services can talk to each other, ensuring that internal microservices are isolated from the public internet.

# Defining a security group rule that restricts access to port 443
resource "aws_security_group" "web_sg" {
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Interview questions

All AWS interview questions →

Check yourself

Take the full AWS quiz →