25 AWS interview questions

Listen for: A strong answer starts with the request path: client, DNS, ALB listener, target group, health checks, security groups, app logs, and metrics. They should mention checking target health reason codes, ALB access logs, CloudWatch metrics, timeouts, container or instance resource pressure, and whether the app binds to the expected port.

Red flag: They immediately restart instances or change random security group rules without looking at logs or target health.

Listen for: Look for OIDC federation from GitHub Actions, GitLab, or another CI system into an IAM role, with a trust policy scoped to repository, branch, or environment. They should understand temporary credentials, least privilege deployment policies, auditability in CloudTrail, and why access keys in secrets managers are still a risk.

Red flag: They propose creating an IAM user with administrator access and saving the access key in the CI tool.

Listen for: They should reason about private subnet egress: route table default route to a NAT gateway or NAT instance, network ACLs, security group outbound rules, DNS resolution, and whether the package repo is public or reachable through VPC endpoints. Bonus if they mention SSM Session Manager for access instead of SSH bastions.

Red flag: They say every instance that needs internet access should be moved to a public subnet.

Listen for: Good candidates compare operational behavior, not just definitions. They should discuss encryption with KMS, IAM access control, rotation support, retrieval at runtime versus deploy time, accidental exposure in logs or task definitions, caching, and appropriate use cases such as low-change configuration in Parameter Store and database credentials in Secrets Manager.

Red flag: They treat environment variables as a secure secret store because they are not visible to users.

Listen for: They should inspect CloudWatch Logs and metrics for duration, init duration, memory use, errors, throttles, and downstream latency. Strong signals include understanding cold starts, package size, VPC networking effects, SDK retries, connection reuse, memory-to-CPU scaling, and using AWS X-Ray or OpenTelemetry traces to isolate the slow dependency.

Red flag: They only increase timeout and memory without first identifying whether the delay is inside Lambda or a downstream service.

Listen for: Listen for multiple layers: S3 Block Public Access at account and bucket level, bucket policies with explicit principals, IAM least privilege, Access Analyzer, CloudTrail data events when needed, server-side encryption, and avoiding public ACLs. They should understand that static website hosting and public assets require deliberate exceptions.

Red flag: They rely only on bucket naming or assume S3 buckets are private in all cases.

Listen for: A strong answer covers remote state locking in S3 and DynamoDB or Terraform Cloud, provider pinning, module boundaries, import strategy for manually created resources, plan review, drift detection, and separating environments. They should avoid rewriting everything and instead propose safe, incremental cleanup with clear ownership and CI checks.

Red flag: They suggest deleting the state file and re-running apply to recreate the environment.

Listen for: They should inspect task events, stopped task reasons, container exit codes, CloudWatch logs, health check grace periods, ALB target group health, CPU and memory limits, environment variables, IAM task role permissions, and image architecture. Improvement ideas may include deployment circuit breakers, blue/green with CodeDeploy, rollback alarms, and realistic container health checks.

Red flag: They assume Docker working locally proves the ECS task definition and AWS runtime configuration are correct.

Listen for: Look for trade-offs around execution model, traffic pattern, latency sensitivity, runtime limits, deployment complexity, team skills, portability, autoscaling, networking, observability, and operational overhead. They should distinguish event-driven or bursty Lambda use cases from long-running services on ECS and multi-team Kubernetes needs on EKS.

Red flag: They pick EKS by default because it is more flexible, without justifying the operational cost.

Listen for: Good answers separate immediate mitigation from longer-term fixes. They should mention Performance Insights, slow query analysis, connection pooling with RDS Proxy or PgBouncer, indexes, query plans, instance sizing, read replicas for read-heavy paths, application retry behavior, and backpressure. They should be careful with failovers and schema changes during incidents.

Red flag: They immediately scale the database instance without checking queries, connections, or application behavior.

Listen for: They should describe account separation by environment or domain, IAM roles instead of users, permission boundaries or SCPs, cross-account role assumption, short-lived credentials, resource-level policies, tagging conditions where appropriate, and Access Analyzer or IAM Access Advisor for review. Strong candidates balance least privilege with maintainability and incident access needs.

Red flag: They propose using one shared admin role across all accounts to avoid permission issues.

Listen for: They should discuss log retention policies, structured logging, sampling for high-volume events, metric filters versus custom metrics, avoiding noisy debug logs in production, central log accounts, OpenSearch only when justified, and trace sampling with X-Ray or OpenTelemetry. They should preserve incident usefulness while reducing unnecessary ingestion and storage.

Red flag: They recommend disabling most logs without asking which signals are needed for incidents and compliance.

Listen for: A strong answer includes inventory, dependency mapping, tagging, documenting current behavior, importing resources into Terraform or modeling with AWS CDK v2, validating plans, applying small changes, and using backups or snapshots before risky operations. They should know imports do not magically make configuration correct and drift must be resolved carefully.

Red flag: They want to recreate all resources from scratch in production to make the IaC clean.

Listen for: Look for discovery before standardization: account inventory, AWS Organizations structure, Control Tower or landing zone review, central CloudTrail and Config, identity via IAM Identity Center, guardrails with SCPs, VPC and DNS mapping, risk ranking, and stakeholder alignment. Strong candidates create a phased plan that avoids breaking product teams.

Red flag: They start by enforcing a single architecture everywhere without understanding existing workloads or constraints.

Listen for: They should propose clear account boundaries, federated access, CI/CD role assumption, SCP guardrails, permission boundaries, standardized VPC patterns, centralized audit logs, and reusable IaC modules or CDK constructs. Listen for self-service with paved roads, not ticket-driven bottlenecks, and exception handling for unusual workloads.

Red flag: They make the security team a manual approval gate for every normal deployment.

Listen for: Strong answers use predefined recovery objectives, customer impact, dependency health, data consistency risks, runbook confidence, and failback complexity. They should discuss Route 53 health checks, Global Accelerator, multi-region data replication, feature flags, read-only modes, and communication. They should know failover can make incidents worse if untested.

Red flag: They always fail over immediately because multi-region exists.

Listen for: Listen for tagging standards, account-level ownership, budgets and anomaly detection, workload rightsizing, Graviton evaluation, Savings Plans or reservations coordination, lifecycle policies, storage class choices, and architecture reviews during design. Strong candidates frame cost as an engineering signal alongside reliability and performance, not a finance-only cleanup exercise.

Red flag: They only propose monthly reports naming the teams that spent the most.

Listen for: They should cover Kubernetes scheduling requests and limits, pod disruption budgets, affinity rules, Cluster Autoscaler or Karpenter configuration, node group instance types, Spot interruption handling, VPC CNI IP exhaustion, storage constraints, and observability with metrics-server, Container Insights, or Prometheus. Strong answers connect AWS infrastructure limits with Kubernetes behavior.

Red flag: They blame Kubernetes itself and recommend moving everything to EC2 without diagnosing scheduling or autoscaling.

Listen for: Strong candidates contain first: disable or rotate credentials, revoke sessions where possible, isolate affected roles, preserve evidence, and review CloudTrail, GuardDuty, IAM Access Analyzer, VPC Flow Logs, and unusual API calls. They should identify blast radius, check persistence mechanisms, coordinate communications, and avoid destroying evidence too early.

Red flag: They delete users and resources immediately without preserving logs or understanding scope.

Listen for: They should evaluate operational burden, feature fit, lock-in, compliance, failure modes, skill availability, scaling needs, observability, and exit strategy. Examples might compare MSK versus self-managed Kafka, OpenSearch Service versus operating clusters, or RDS versus PostgreSQL on EC2. Strong answers include migration and ownership implications.

Red flag: They always choose managed services or always choose open source as a rule.

Listen for: Look for a clear tenancy model: pooled versus siloed accounts, tenant IDs in auth and data paths, IAM and KMS boundaries, API Gateway or ALB with ECS/Lambda, RDS or DynamoDB partitioning, centralized audit logs, deployment strategy, and tenant-aware observability. Strong candidates explain isolation trade-offs and migration paths.

Red flag: They only add a tenant_id column and assume that solves isolation, security, and operations.

Listen for: They should use services such as SQS, SNS, EventBridge, Lambda, Step Functions, ECS workers, and DynamoDB idempotency records where appropriate. Listen for dead-letter queues, replay strategy, visibility timeouts, backoff, poison message handling, exactly-once skepticism, downstream rate limits, and business-level idempotency keys.

Red flag: They claim SQS or Lambda guarantees exactly-once processing and no duplicates.

Listen for: Strong designs use S3 with scoped access, presigned URLs or Transfer Family when appropriate, S3 event notifications, Lambda/ECS/Glue processing, Step Functions orchestration, KMS encryption, malware or schema validation, quarantine prefixes, Lake Formation or IAM controls, and Athena/Glue Data Catalog. They should cover audit trails and failure handling.

Red flag: They put all partners into one shared IAM user or one writable bucket prefix.

Listen for: They should separate multi-AZ from multi-region. Expect ALB, Auto Scaling or ECS across subnets, RDS Multi-AZ, backups, Route 53 or Global Accelerator, replication patterns, runbooks, health checks, and tested failover. Strong answers discuss data consistency, DNS TTLs, recovery objectives, and which components are active-active versus active-passive.

Red flag: They say enabling Multi-AZ automatically protects the full application from a regional outage.

Listen for: Look for AWS Organizations, account vending, IAM Identity Center, centralized logging, Config, GuardDuty, Security Hub, networking patterns, DNS strategy, CI/CD federation, IaC standards with Terraform/OpenTofu or CDK v2, reusable modules, and guardrails. Strong candidates design self-service workflows and documented paved paths rather than a central bottleneck.

Red flag: They propose one large shared account because it is simpler at the beginning.