AWS Interview Questions and Answers 2026 (70 Questions)

These AWS interview questions cover what cloud engineer and solutions architect interviews in 2026 actually probe: IAM and multi-account governance, VPC networking, compute, storage, databases, serverless and containers, infrastructure as code, observability, encryption, resilience and cost. Interviewers rarely stop at "what is S3"; they ask why a private instance cannot reach the internet, how you would stop a bucket from leaking data, and what you would do when a Region goes dark. The 70 questions below move from fundamentals to architecture and finish with fourteen real-world AWS scenario based questions.

How to use this guide:

• Freshers and junior cloud engineers are usually tested on the fundamentals, IAM, VPC, EC2 and S3 sections. Be able to draw a VPC with public and private subnets from memory.
• Mid-level AWS cloud engineer interview rounds add Auto Scaling, load balancers, RDS, Lambda, containers, CloudFormation, CloudWatch and at least two troubleshooting scenarios.
• AWS solutions architect interview rounds push on policy evaluation, multi-account design, DR strategy, cost trade-offs and whiteboard designs such as a three-tier application.
• For every answer, say the one-line answer first, then the mechanism, then a trade-off. Quote limits as "the default quota is X, adjustable".

Contents

• Fundamentals and IAM (Q1–Q7)
• VPC networking (Q8–Q14)
• EC2, Auto Scaling and load balancing (Q15–Q23)
• S3 and storage (Q24–Q29)
• RDS, Aurora and DynamoDB (Q30–Q34)
• Lambda, containers and messaging (Q35–Q39)
• IaC, observability, KMS and secrets (Q40–Q47)
• Route 53, CloudFront and edge security (Q48–Q49)
• Architecture, DR, cost and multi-account (Q50–Q54)
• AI on AWS (Q55–Q56)
• Real-world scenario questions (Q57–Q70)
• Key takeaways
• Interview preparation checklist
• FAQ

Fundamentals and IAM

1. What are Regions, Availability Zones and edge locations, and why do they matter for design?

Answer: A Region is a geographic area (for example Mumbai or Hyderabad) containing multiple Availability Zones. An AZ is one or more discrete data centres with independent power and networking, linked to the other AZs by low-latency connections. Edge locations are points of presence for CloudFront, Route 53 and Global Accelerator. Design consequence: spread workloads across at least two AZs to survive a data-centre failure, and add a second Region only when the business must survive a Regional event. Most services are Regional; IAM, Route 53 and CloudFront are global.

2. What is the shared responsibility model, and how does it differ between public, private and hybrid cloud?

Answer: AWS is responsible for security of the cloud: facilities, hardware, the hypervisor and the managed-service software. You are responsible for security in the cloud: identities, data, network configuration, encryption choices and, for EC2, the guest OS and patches. The line moves with the service: on Lambda you own only code, configuration and permissions. A public cloud is shared multi-tenant infrastructure you rent; a private cloud is dedicated infrastructure you run or lease; hybrid connects the two, usually with VPN or Direct Connect, so some workloads stay on premises for latency, licensing or regulation.

3. What are IAM users, groups, roles and policies, and what policy types exist?

Answer: A user is a long-lived identity with credentials; a group is a collection of users for attaching policies; a role is an identity with no long-term credentials that a person, service or another account assumes to get temporary credentials from STS. Policies are JSON documents of Effect, Action, Resource and optional Condition. The types you should name are identity-based policies (AWS managed, customer managed and inline), resource-based policies (bucket policies, KMS key policies, SQS queue policies, role trust policies), permissions boundaries, Organizations SCPs and RCPs, and session policies passed when assuming a role.

4. How does an application on EC2 get AWS credentials without storing access keys?

Answer: You attach an IAM role to the instance through an instance profile. The SDK on the instance fetches short-lived credentials from the Instance Metadata Service, and they rotate automatically. Require IMDSv2, which uses a session token obtained with a PUT request, because it blocks the classic server-side request forgery path to the metadata endpoint. The same pattern exists elsewhere: ECS task roles, EKS Pod Identity or IRSA for pods, and execution roles for Lambda.

5. How does AWS evaluate a request when several policies apply?

Answer: Everything starts as an implicit deny. An explicit Deny in any applicable policy wins. Otherwise the request needs an Allow, and every guardrail in the path must also permit it: SCPs and RCPs set the maximum for accounts in an organization, a permissions boundary caps an identity, and a session policy caps a session. Within one account, identity-based and resource-based Allows are combined (either can grant). Across accounts, both sides must allow: the caller's identity policy must permit the action and the resource policy (or the target role's trust policy) must trust the caller.

6. What is a permissions boundary and when would you use one?

Answer: A permissions boundary is a managed policy attached to a user or role that sets the maximum permissions its identity policies can grant. It grants nothing on its own. The classic use is safe delegation: you let developers create roles for their Lambda functions, but only if every new role carries a boundary that excludes IAM administration, billing and other teams' resources. Enforce it with a condition on iam:CreateRole that requires the boundary ARN, otherwise developers can create unbounded roles and escalate.

7. How should humans sign in to AWS in a multi-account company, and how do you protect the root user?

Answer: Use IAM Identity Center connected to the corporate identity provider (for example Microsoft Entra ID or Okta). Users get permission sets mapped to accounts, sign in once and receive temporary credentials for the console and CLI. Joiners and leavers are handled in the identity provider, not in dozens of AWS accounts. For the root user, enable MFA, do not create root access keys, keep the credentials in a controlled process and use it only for the few tasks that require it. For any remaining IAM users, enforce MFA with a policy condition on aws:MultiFactorAuthPresent.

VPC networking

8. What is a VPC, why do we create subnets, and how many IP addresses does AWS reserve per subnet?

Answer: A VPC is your logically isolated network in a Region, defined by one or more CIDR blocks. Subnets carve that range into pieces that each live in one AZ; you create them to separate tiers (public load balancers, private application servers, isolated databases) and to spread across AZs. IPv4 subnets can range from /28 to /16. AWS reserves five addresses in every subnet: the network address, the VPC router (base plus one), the DNS server (base plus two), one reserved for future use (base plus three) and the last address. Default quotas: five VPCs per Region and 200 subnets per VPC, both adjustable. Never overlap CIDRs with on-premises or future peered VPCs.

9. What is a route table, and what does the main route table contain by default?

Answer: A route table is a set of rules that decides where traffic from a subnet goes, using longest-prefix match. Each subnet is associated with exactly one route table; if you do not associate one explicitly, it uses the VPC's main route table. By default the main route table has only the local route for the VPC CIDR, so all subnets can talk to each other and nothing else. A subnet is "public" only because its route table has 0.0.0.0/0 pointing to an internet gateway. Private subnets typically route 0.0.0.0/0 to a NAT gateway, and endpoint, peering or transit gateway routes are added as needed.

10. Internet gateway, NAT gateway and NAT instance: what is the difference?

Answer: An internet gateway is a horizontally scaled VPC component that allows two-way internet traffic for resources with public IPs. A NAT gateway lets resources in private subnets start outbound connections (patches, external APIs) while blocking unsolicited inbound traffic. A NAT instance is an EC2 instance doing NAT that you patch, scale and fail over yourself (and whose source/destination check you disable), which is why managed NAT gateways replaced it. A zonal NAT gateway lives in one AZ, so you run one per AZ; AWS now also offers a regional mode that expands across AZs automatically and needs no public subnet, though it does not support private NAT.

Production consideration: NAT gateways charge per hour and per GB processed. Heavy traffic to S3 or DynamoDB through NAT is a common bill surprise; gateway endpoints fix it (see Q12).

11. Security groups versus network ACLs: how do they differ?

Answer: Security groups are stateful, attached to network interfaces, support allow rules only, and can reference other security groups (for example "allow 5432 from the app-tier SG"). Return traffic is allowed automatically. Network ACLs are stateless, attached to subnets, support allow and deny rules evaluated in number order, and need explicit rules for return traffic on ephemeral ports. Use security groups as the main control and NACLs as a coarse subnet-level backstop, for example to block a known bad CIDR quickly.

12. What are VPC endpoints, and how do gateway endpoints, interface endpoints and PrivateLink differ?

Answer: VPC endpoints let resources reach AWS services without traversing the internet. Gateway endpoints exist only for S3 and DynamoDB; they are route-table targets using the service's prefix list and have no additional charge. Interface endpoints are elastic network interfaces with private IPs in your subnets, powered by AWS PrivateLink, and support many AWS services plus your own or partner services. PrivateLink also exposes your own service, behind a Network Load Balancer, to other VPCs or accounts without peering. Endpoint policies restrict what is reachable through an endpoint.

13. VPC peering versus Transit Gateway: when do you use each, and what are peering's prerequisites?

Answer: VPC peering is a one-to-one private connection between two VPCs, in the same or different accounts and Regions. Prerequisites: non-overlapping CIDRs, an accepted peering request, routes in both VPCs' route tables, and security groups that allow the traffic. Peering is not transitive, so ten VPCs needing full connectivity means many connections. Transit Gateway is a Regional hub that VPCs, VPNs and Direct Connect attach to, with its own route tables for segmentation (for example production cannot reach development). Use peering for a few VPCs with heavy traffic between them; use Transit Gateway once you have many VPCs, hybrid connectivity or a need for central inspection.

14. How do you connect an on-premises data centre to AWS?

Answer: Two main options. AWS Site-to-Site VPN creates IPsec tunnels over the internet to a virtual private gateway or transit gateway; it is quick to set up and each connection has two tunnels for redundancy. AWS Direct Connect is a dedicated private link through a Direct Connect location, giving more consistent latency and bandwidth for steady, heavy traffic, but it takes longer to provision. Many enterprises run Direct Connect as primary with VPN as backup. For DNS across the boundary, Route 53 Resolver inbound and outbound endpoints forward queries both ways.

EC2, Auto Scaling and load balancing

15. What are the main EC2 instance families, and how do you choose one?

Answer: Families are grouped by purpose: general purpose (M, and burstable T), compute optimised (C), memory optimised (R, X), storage optimised (I, D) and accelerated computing (P and G for GPUs, Inf and Trn for AWS Inferentia and Trainium). The name encodes the family, generation, optional attributes and size: in m7g.large, "g" means AWS Graviton (Arm). Choose by the bottleneck: profile CPU, memory, network and disk, start with a current-generation general-purpose type, then right-size with CloudWatch data and Compute Optimizer recommendations.

16. Compare On-Demand, Savings Plans, Reserved Instances, Spot and Dedicated options.

Answer: On-Demand is pay-per-second with no commitment. Savings Plans trade a 1- or 3-year commitment to a dollar-per-hour spend for lower rates; AWS currently lists four types: Compute (EC2 across families and Regions, Fargate and Lambda), EC2 Instance (one family in one Region), Database, and SageMaker AI. Reserved Instances commit to an instance configuration and, when zonal, can reserve capacity. Spot uses spare capacity at a steep discount but can be reclaimed with a two-minute interruption notice, so it suits stateless, fault-tolerant work. Dedicated Hosts and Dedicated Instances give single-tenant hardware for licensing or compliance, and On-Demand Capacity Reservations reserve capacity in an AZ without a discount.

17. What is an AMI, and what is the difference between EBS-backed and instance store-backed instances?

Answer: An AMI is a template containing a root volume snapshot, launch permissions and block device mappings used to launch instances. EBS-backed instances boot from an EBS volume that persists independently, so they can be stopped and started, resized and snapshotted. Instance store volumes are physically attached disks that are fast but ephemeral: data is lost on stop, hibernation or termination. By default the root EBS volume is deleted on termination because its DeleteOnTermination flag is true; set it to false, or keep data on a separate volume, if the data must survive. You cannot convert an instance store-backed root into an EBS-backed one in place; you rebuild from an EBS-backed AMI.

18. What EBS volume types exist, and when would you use each?

Answer: SSD types: gp3 (general purpose, the usual default, with IOPS and throughput set independently of size), gp2 (older general purpose with IOPS tied to size), io2 Block Express and io1 (Provisioned IOPS for latency-sensitive databases; io2 also supports Multi-Attach). HDD types: st1 (throughput-optimised for logs and big data) and sc1 (cold, lowest cost); HDD volumes cannot be boot volumes. Magnetic standard is previous generation. Migrating gp2 to gp3 is usually a no-downtime change through Elastic Volumes and often lowers cost.

19. What is vertical versus horizontal scaling, and how do you change an instance's type?

Answer: Vertical scaling makes one instance bigger; horizontal scaling adds more instances behind a load balancer. Vertical is simple but has a ceiling and needs a restart; horizontal needs stateless design but gives elasticity and resilience. To change the type of an EBS-backed instance, stop it, change the instance type (checking architecture, virtualisation and driver compatibility, such as ENA and NVMe for Nitro types), and start it. The public IPv4 address changes on stop/start unless you use an Elastic IP. In an Auto Scaling group, change the launch template instead and run an instance refresh.

20. What are the components of EC2 Auto Scaling and its scaling policies?

Answer: Components: a launch template (AMI, instance type, security groups, user data, IAM role), an Auto Scaling group (subnets across AZs, minimum, maximum and desired capacity, health checks) and scaling policies. Policies: target tracking (keep average CPU or requests per target near a value, the usual choice), step scaling (different adjustments for different alarm breaches), simple scaling (older, one adjustment then cooldown), scheduled scaling (known patterns such as office hours) and predictive scaling (forecasts from history). Lifecycle hooks and warm pools handle bootstrap and start-up time.

21. What types of Elastic Load Balancer exist, and how do ALB and NLB differ?

Answer: Current-generation types are Application Load Balancer (layer 7, HTTP/HTTPS and gRPC, content-based routing, WAF integration, Lambda targets), Network Load Balancer (layer 4, TCP/UDP/TLS, very high throughput, static IPs per AZ, preserves source IP, the front door for PrivateLink services) and Gateway Load Balancer (layer 3, inserts third-party firewalls and inspection appliances transparently). Classic Load Balancer is previous generation, and AWS recommends migrating off it. Choose ALB for web apps and microservices, NLB for non-HTTP protocols, extreme performance or fixed IPs, and GWLB for appliance fleets.

22. How do you configure host-based and path-based routing on an ALB, and can an ALB invoke Lambda?

Answer: Create target groups for each service, then add listener rules on the HTTPS listener with conditions such as host header (api.example.com to the API target group, admin.example.com to the admin group) or path pattern (/orders/* to the orders service). Rules are evaluated in priority order with a default action at the end; you can also match on headers, query strings and source IPs, and return fixed responses or redirects. Yes, an ALB target group can be of type Lambda, which is a simple way to expose a function over HTTP without API Gateway when you do not need API Gateway features such as usage plans.

23. How do load balancer health checks and Auto Scaling replace unhealthy instances?

Answer: The load balancer's target group health check decides whether to send traffic to a target. Auto Scaling by default uses EC2 status checks only, so an instance with a crashed application but a running OS stays in service. Turn on ELB health checks for the Auto Scaling group so targets that fail the load balancer check are terminated and replaced automatically. Set a health check grace period long enough for boot and warm-up, and make the health endpoint check real dependencies lightly, otherwise one slow database can make every instance "unhealthy" at once and trigger a replacement storm.

If you would rather practise these designs on real accounts with a trainer reviewing your VPCs and IAM policies, Cloudsoft's AWS training in Hyderabad runs as classroom batches in Ameerpet and live online.

S3 and storage

24. What are the S3 storage classes, and which is the default?

Answer: S3 Standard is the default. Other classes: S3 Express One Zone (single-AZ, single-digit millisecond access, uses directory buckets), S3 Intelligent-Tiering (moves objects between access tiers automatically, no retrieval fees, small per-object monitoring fee), S3 Standard-IA and S3 One Zone-IA (infrequent access, millisecond retrieval, 30-day minimum and retrieval fees), S3 Glacier Instant Retrieval (rarely accessed, millisecond access, 90-day minimum), S3 Glacier Flexible Retrieval (minutes to hours, 90-day minimum) and S3 Glacier Deep Archive (lowest cost for archives retrieved in hours, 180-day minimum). Reduced Redundancy Storage still exists but AWS recommends not using it. One Zone-IA and Express One Zone are not resilient to the loss of an AZ.

25. How do S3 lifecycle rules and Intelligent-Tiering reduce cost, and what are the traps?

Answer: Lifecycle rules transition objects to cheaper classes after a set age and expire them, including noncurrent versions and incomplete multipart uploads. Intelligent-Tiering suits data with unknown or changing access because it moves objects itself. Traps: minimum storage durations and minimum billable object sizes (128 KB for IA classes) can make tiering small or short-lived objects more expensive; Glacier classes add per-object metadata overhead; and transition requests cost money per object, so millions of tiny files may be better compacted first. Use Storage Class Analysis or S3 Storage Lens before designing rules.

26. How do you secure access to an S3 bucket?

Answer: Layer the controls. New buckets block public access and have ACLs disabled by default (Object Ownership set to bucket owner enforced); keep both, and turn on Block Public Access at the account or organization level so a bucket-level change cannot reopen it. Grant access with IAM policies and bucket policies, not ACLs. Restrict network paths with conditions such as aws:SourceVpce and require TLS with aws:SecureTransport. Detect problems with IAM Access Analyzer, AWS Config and Amazon Macie, and log requests with CloudTrail data events.

27. How can you encrypt data in S3?

Answer: All new objects are encrypted at rest by default with SSE-S3 (S3-managed keys). For more control use SSE-KMS with a customer managed key, which adds key policies, CloudTrail records of key use and the ability to revoke access by changing the key policy; enable S3 Bucket Keys to reduce KMS request costs. DSSE-KMS applies two layers of KMS-based encryption for stricter compliance needs, SSE-C uses keys you supply on every request, and client-side encryption encrypts before upload. Enforce the choice with default bucket encryption plus a bucket policy that denies uploads without the expected encryption header. In transit, require HTTPS.

28. What are the S3 object size and bucket limits, and what drives S3 pricing?

Answer: Objects can be from 0 bytes up to 50 TB. A single PUT uploads up to 5 GB; larger objects need multipart upload (parts from 5 MB), and the console uploads up to 160 GB. By default an account can create up to 10,000 general purpose buckets, and you can request more through Service Quotas. A bucket has no size limit or object-count limit, and bucket names and Regions cannot be changed after creation. Pricing is driven by GB-month per class, requests, retrieval fees, data transfer out and optional features such as replication.

Interview tip: Older question banks say "5 TB" and "100 buckets"; quoting current numbers shows you keep up.

29. How do versioning, replication and Object Lock protect data?

Answer: Versioning keeps prior versions so overwrites and deletes can be undone; a delete adds a delete marker rather than removing data. Replication (same-Region or cross-Region) copies objects asynchronously to another bucket, optionally in another account, with Replication Time Control for a predictable replication SLA. By default, deletes in the source add a delete marker only in the source, which protects the replica from malicious deletion. Object Lock adds write-once-read-many retention in governance or compliance mode, plus legal holds, which is what regulators and ransomware-resilience designs ask for. Combine versioning with lifecycle expiry of noncurrent versions so the bill does not grow forever.

RDS, Aurora and DynamoDB

30. What is RDS Multi-AZ, how does it differ from a read replica, and is the standby in the same AZ?

Answer: RDS supports engines such as MySQL, PostgreSQL, MariaDB, Oracle, SQL Server and Db2, plus Aurora. A Multi-AZ DB instance deployment keeps one synchronous standby in a different AZ; it serves no reads and exists only for automatic failover, during which the DNS endpoint moves to the standby. A Multi-AZ DB cluster deployment has two readable standbys across three AZs. Read replicas use asynchronous replication, can be in other Regions, serve read traffic and can be promoted manually, but they are not a high-availability substitute because of replication lag and the manual promotion step. Use Multi-AZ for availability and read replicas for read scaling or cross-Region DR.

31. What backup options does RDS have, how do you restore, and can you stop an RDS instance?

Answer: Automated backups take daily snapshots plus transaction logs, enabling point-in-time restore within the retention period (up to 35 days). Manual snapshots persist until you delete them and can be copied across Regions and shared across accounts. AWS Backup can manage both centrally with cross-account and cross-Region copies. Every restore creates a new DB instance with a new endpoint, so you either repoint the application or rename instances. Yes, you can stop an RDS instance to save compute cost; it restarts automatically after seven days, and you still pay for storage and backups while it is stopped.

32. How does Aurora differ from standard RDS?

Answer: Aurora is AWS's MySQL- and PostgreSQL-compatible engine with a distributed storage layer that keeps six copies of data across three AZs and grows automatically. It supports up to 15 low-lag Aurora Replicas sharing the same storage, fast failover, backtracking (MySQL), fast cloning, Aurora Serverless v2 for variable load and Aurora Global Database for cross-Region replication with typical lag under a second and promotion of a secondary Region in about a minute. Standard RDS is simpler and can be cheaper for small, steady workloads. Choose Aurora when you need fast failover, many readers or a cross-Region DR story.

33. How do you design a DynamoDB table, and what are its capacity modes?

Answer: Design from access patterns, not entities. Pick a partition key with high cardinality so traffic spreads evenly, and a sort key to model one-to-many queries and ranges. Add global secondary indexes for other access patterns (local secondary indexes must be created with the table). Items can be up to 400 KB. Capacity modes are on-demand (pay per request, good for unknown or spiky load) and provisioned (set read and write capacity, optionally with auto scaling, cheaper for steady load). Add point-in-time recovery, TTL for expiring data, Streams for change data capture, DAX for microsecond read caching and global tables for multi-Region active-active writes.

34. How do you choose between RDS, Aurora, DynamoDB, Redshift and ElastiCache?

Answer: Match the data model and access pattern. Relational data with joins and transactions goes to RDS or Aurora. Key-value or document access at any scale with single-digit millisecond latency goes to DynamoDB. Analytics over large historical data with SQL goes to Redshift (a columnar data warehouse), often fed from S3 data lakes queried with Athena. Caching and session stores go to ElastiCache (Valkey, Redis OSS or Memcached engines). Graph data fits Neptune, and time series fits Timestream. Avoid forcing one database onto every pattern, but also avoid running engines a small team cannot operate.

Lambda, containers and messaging

35. When is Lambda a good fit, and what are its key limits?

Answer: Lambda suits event-driven, short-lived, stateless work: API backends, S3 or queue processing, scheduled jobs and glue between services. Key limits from the current quotas page: up to 15 minutes per invocation, 128 MB to 10,240 MB of memory (CPU scales with memory), 512 MB to 10,240 MB of /tmp, 6 MB synchronous request and response payloads, 1 MB for asynchronous invocations, 250 MB unzipped deployment package or 10 GB container images, and a default of 1,000 concurrent executions per Region, which can be raised. For deeper serverless coverage, see these AWS serverless interview questions.

36. What causes Lambda cold starts, and how do concurrency settings work?

Answer: A cold start happens when Lambda must create a new execution environment: download code, start the runtime and run initialisation code. It is worse with large packages, heavy frameworks and slow init logic. Mitigations: keep packages small, move expensive setup into init so it is reused, use provisioned concurrency for latency-sensitive paths, and SnapStart where the runtime supports it. Reserved concurrency sets aside and caps concurrency for one function, protecting downstream databases; provisioned concurrency keeps environments initialised. Functions attached to a VPC use Hyperplane ENIs, so VPC attachment no longer adds the large per-invocation delay it once did, but the function needs NAT or endpoints to reach AWS services.

37. ECS, EKS and Fargate: how do you choose?

Answer: Amazon ECS is AWS's own container orchestrator: simpler, deeply integrated with IAM, ALB and CloudWatch, with services, task definitions and task roles. Amazon EKS is managed Kubernetes: choose it when you need the Kubernetes API, its ecosystem (Helm, operators, Argo CD) or portability. Fargate is a serverless compute engine for both, so you run tasks or pods without managing nodes; EC2 capacity gives more control, GPUs, daemon workloads and often lower cost at scale. EKS Auto Mode lets AWS manage nodes, scaling, load balancer integration and storage drivers for you. Go deeper with these Kubernetes interview questions.

38. How do you push and pull images to ECR, and expose an ECS service behind an ALB?

Answer: Authenticate Docker to ECR with aws ecr get-login-password --region ap-south-1 | docker login --username AWS --password-stdin <account>.dkr.ecr.ap-south-1.amazonaws.com, tag the image with the repository URI and an immutable tag (commit SHA), then docker push. Turn on scan on push and immutable tags. For ECS, the task definition references the image and a task execution role (pulls the image, writes logs) plus a task role (application permissions). Create a service with awsvpc networking in private subnets, attach it to an ALB target group of type IP, and let the service register and deregister tasks during deployments. Docker fundamentals are covered in these Docker interview questions.

39. SQS, SNS and EventBridge: what is the difference?

Answer: SQS is a queue for decoupling producers and consumers: consumers poll, messages are retained up to 14 days (4 by default), the maximum message size is now 1 MiB, and FIFO queues give ordering and deduplication per message group. SNS is pub/sub push: one message fans out to many subscribers such as SQS queues, Lambda, HTTP endpoints, email and SMS. EventBridge is an event bus with content-based rules, schema registry, SaaS integrations, archive and replay, and a scheduler. A common pattern is SNS or EventBridge fan-out to several SQS queues, each with a dead-letter queue, so each consumer scales and fails independently.

IaC, observability, KMS and secrets

40. What are CloudFormation stacks, change sets and StackSets?

Answer: A template (YAML or JSON) declares resources, parameters, conditions and outputs. A stack is a deployed instance of a template managed as one unit; if an update fails, CloudFormation rolls back. Change sets preview exactly what an update will add, modify or replace before you execute it, which matters because some property changes replace resources. StackSets deploy one template across many accounts and Regions in a single operation, and with service-managed permissions they deploy automatically to new accounts in an OU. Protect critical resources with DeletionPolicy: Retain or Snapshot, stack policies and termination protection.

41. What is drift in CloudFormation, and how do you detect and handle it?

Answer: Drift is when a resource's actual configuration differs from the template, usually because someone changed it in the console. Run drift detection on the stack (or a StackSet); each resource is reported as IN_SYNC, MODIFIED, DELETED or NOT_CHECKED, with a property-level diff. To fix it, either update the template to match reality and redeploy, or redeploy the template to overwrite the manual change. Prevent drift by removing console write access in production, running deployments only from pipelines and using AWS Config rules to alert on out-of-band changes.

42. CloudFormation, CDK or Terraform: how do you choose?

Answer: CloudFormation is AWS-native, with managed state, rollback and StackSets. AWS CDK lets you define infrastructure in TypeScript, Python, Java, C# or Go with reusable constructs, and synthesises CloudFormation templates, so you get programming-language abstractions with CloudFormation's deployment engine. Terraform is multi-cloud with a large provider ecosystem but you manage state (typically S3 with locking) yourself. Many enterprises standardise on Terraform for landing zones and multi-cloud, and use CDK for application teams. Terraform depth is in these Terraform interview questions.

43. Which CloudWatch metrics are available for EC2, and how do you set alerts and notifications?

Answer: By default EC2 publishes hypervisor-level metrics: CPU utilisation, network in/out, disk operations for instance store, EBS metrics, status check failures (instance, system and attached EBS) and CPU credit metrics for T instances, at 5-minute intervals (1-minute with detailed monitoring). Memory and disk-space usage are not visible to the hypervisor, so install the CloudWatch agent to collect them along with logs. Create CloudWatch alarms on metrics or metric math, send them to SNS topics for email, chat or paging, and trigger actions such as Auto Scaling or EC2 recover. Use composite alarms to reduce noise, and Logs Insights to query logs during incidents.

44. What does CloudTrail record, and how do you set it up across Regions and accounts?

Answer: CloudTrail records API activity: who called what, when, from where and with what result. Event history shows the last 90 days of management events in each Region for free. For durable audit logs create a trail that applies to all Regions, delivering to a central S3 bucket in a log-archive account, with log file validation, KMS encryption and Object Lock where required. In an organization, create an organization trail from the management account or a delegated administrator so every member account is covered and cannot turn it off. Data events (S3 object-level, Lambda invokes) are optional and billed separately. Alert on sensitive calls such as StopLogging with EventBridge rules.

45. How does AWS KMS work, and how does key rotation work?

Answer: KMS manages keys that never leave its HSMs unencrypted. Services use envelope encryption: KMS generates a data key, the data is encrypted with the data key, and the data key is stored encrypted under your KMS key. Access is controlled by key policies (mandatory), IAM policies and grants, and every use is logged in CloudTrail. For customer managed symmetric keys with KMS-generated material, you can enable automatic rotation (default every 365 days, with a configurable rotation period) and also trigger on-demand rotation. AWS managed keys rotate every year automatically. Rotation changes only the key material; the key ID stays the same and old ciphertext still decrypts. Asymmetric, HMAC and custom key store keys need manual rotation by creating a new key and moving an alias.

46. Secrets Manager versus Systems Manager Parameter Store: when do you use each?

Answer: Secrets Manager is built for credentials: automatic rotation (with ready-made rotation for supported databases such as RDS), cross-Region replication and resource policies for cross-account access, charged per secret and per API call. Parameter Store holds configuration and secrets as String, StringList or SecureString (encrypted with KMS), with standard parameters at no extra charge, but rotation is your job. Common practice: database passwords and API keys in Secrets Manager, feature flags and non-secret config in Parameter Store. Applications fetch at start-up and cache, rather than calling on every request.

47. How would you build a CI/CD pipeline for AWS deployments?

Answer: On AWS-native tooling: CodePipeline orchestrates stages, CodeBuild builds and tests, and CodeDeploy deploys to EC2, ECS (blue/green with traffic shifting) or Lambda (canary or linear). Source can be GitHub, GitLab or Bitbucket through AWS CodeConnections (previously CodeStar Connections). Many teams instead use GitHub Actions or Jenkins with OIDC federation into an IAM role, so no long-lived keys sit in the CI system. Elastic Beanstalk is still available for teams that want a managed platform for a PHP, Java or Python app with RDS, but most new designs choose ECS or Lambda.

Route 53, CloudFront and edge security

48. What routing policies does Route 53 support?

Answer: Simple (one resource), weighted (split traffic by proportion, useful for canaries), latency (send users to the Region with the lowest latency), failover (active-passive with health checks), geolocation (by user's continent or country), geoproximity (by distance to resources, with a bias to shift traffic), IP-based (by the client's source IP ranges) and multivalue answer (up to eight healthy records chosen at random). Health checks can monitor endpoints, other health checks or CloudWatch alarms. Use alias records to point the zone apex to an ALB, CloudFront or S3 website endpoint without a charge for alias queries to AWS resources.

49. How do CloudFront, WAF and Shield protect and speed up a website?

Answer: CloudFront caches content at edge locations, terminates TLS close to users and connects to origins (S3, ALB, any HTTP server) over the AWS backbone. For a private S3 origin use Origin Access Control so the bucket stays non-public and only that distribution can read it. AWS WAF attaches to CloudFront, ALB or API Gateway and filters requests with managed rule groups (common exploits, known bad inputs, bot control) and rate-based rules. AWS Shield Standard protects every customer against common network and transport-layer DDoS at no extra cost; Shield Advanced adds response team access, cost protection and advanced detection for high-risk applications.

Real-world example: A retailer's festive sale serves assets from CloudFront, rate-limits checkout with WAF and lets only CloudFront's managed prefix list reach the ALB.

Architecture, DR, cost and multi-account

50. What are the six pillars of the AWS Well-Architected Framework?

Answer: Operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. Operational excellence is about running and improving workloads (IaC, runbooks, small reversible changes). Security covers identity, detection, data protection and incident response. Reliability covers recovering from failure and scaling to demand. Performance efficiency is choosing the right resources and reviewing them as technology changes. Cost optimization is delivering value at the lowest price point. Sustainability minimises the environmental impact of running workloads. The Well-Architected Tool lets teams run reviews against these pillars and track improvement plans.

51. What are RTO and RPO, and what DR strategies does AWS describe?

Answer: Recovery Time Objective is how long the business can tolerate being down; Recovery Point Objective is how much data loss it can tolerate, measured in time. AWS's DR whitepaper describes four strategies with decreasing RTO/RPO and increasing cost: backup and restore (back up data and redeploy infrastructure from IaC when needed), pilot light (data replicated live, core infrastructure provisioned but application servers switched off), warm standby (a scaled-down but fully working copy that can take traffic immediately, then scales up), and multi-site active/active (full capacity serving traffic in more than one Region). Hot standby is the active/passive variant at full capacity.

Strategy	Running in DR Region	Relative RTO/RPO	Relative cost
Backup and restore	Backups only	Hours	Lowest
Pilot light	Data stores, core infra	Tens of minutes	Low
Warm standby	Scaled-down full stack	Minutes	Medium
Multi-site active/active	Full stack serving traffic	Near zero	Highest

Production consideration: Replication protects against infrastructure loss, not corruption or deletion. Every strategy still needs point-in-time backups, and a DR plan that has never been tested does not exist.

52. What are the main cost optimisation levers on AWS?

Answer: Visibility first: cost allocation tags, AWS Budgets with alerts, Cost Explorer, Cost Anomaly Detection and the Cost and Usage Report (Data Exports) analysed in Athena or QuickSight. Then the levers: right-size with Compute Optimizer, switch off non-production at night with schedules, buy Savings Plans for the steady baseline, use Spot for interruptible work, move to Graviton where possible, tier storage with lifecycle rules, delete unattached EBS volumes, old snapshots and idle load balancers, and reduce data transfer (gateway endpoints instead of NAT for S3, CloudFront in front of origins, keeping chatty services in one AZ where resilience allows). Make cost a shared metric with engineering teams, not just a finance report. More on this in these FinOps interview questions.

53. How do AWS Organizations, SCPs and RCPs support a multi-account strategy?

Answer: Separate accounts are the strongest isolation boundary on AWS for blast radius, quotas, billing and permissions. Organizations groups accounts into organizational units (for example Security, Infrastructure, Workloads and Sandbox) with consolidated billing. Service control policies set the maximum permissions for IAM users and roles in member accounts (for example deny leaving the organization, deny disabling CloudTrail, deny Regions you do not use). Resource control policies set the maximum permissions on resources (for example S3 buckets and KMS keys can only be accessed by principals in your organization). Neither grants permissions, neither affects the management account, and SCPs do not restrict service-linked roles. Declarative policies such as backup, tag and EC2 policies enforce configuration. Keep the management account empty of workloads.

54. What does AWS Control Tower add on top of Organizations, and how do you plan a migration?

Answer: Control Tower sets up and governs a landing zone: it creates the organization structure, a log archive account and an audit account, centralised CloudTrail and Config, IAM Identity Center, and an Account Factory for vending new accounts with a standard baseline. Controls (previously called guardrails) are preventive (implemented with SCPs or RCPs), detective (AWS Config rules) or proactive (CloudFormation hooks that check resources before they are created). For migration planning, classify each application using the 7 Rs (retire, retain, rehost, relocate, repurchase, replatform, refactor), use AWS Application Migration Service for lift-and-shift of servers and AWS DMS (with the Schema Conversion tooling) for database moves, and migrate in waves into accounts the landing zone has already vended.

Interview tip: Old lists still ask about Cloud9, CodeStar and Snowball: Cloud9 and Snowball Edge are closed to new customers, and CodeStar projects were discontinued in July 2024.

AI on AWS

55. Which AWS services would you consider for an AI workload, at a high level?

Answer: Amazon Bedrock gives API access to foundation models from several providers, plus Knowledge Bases for RAG, Guardrails and model evaluation. Amazon Bedrock AgentCore provides the runtime, memory, identity, gateway and observability building blocks to run agents in production; the older Bedrock Agents is now "Bedrock Agents Classic" and closed to new customers from 30 July 2026, with AgentCore recommended for new builds. Amazon SageMaker AI covers training, tuning and hosting your own models. Pre-trained services such as Textract, Transcribe and Rekognition solve specific tasks without model work. Each area has its own guide: Amazon Bedrock interview questions, Bedrock AgentCore interview questions, SageMaker AI interview questions and AWS AI services interview questions.

56. How would you run an AI application on AWS securely and economically?

Answer: Treat the model call like any other dependency. Call Bedrock from private subnets through an interface VPC endpoint, give each application a narrowly scoped role that allows only the model IDs it uses, encrypt prompts, documents and vector stores with customer managed KMS keys, and log invocations for audit. At organization level, Organizations now offers a Bedrock policy type to enforce Guardrails across accounts, and an AI services opt-out policy to control data use by AWS AI services. For cost, alarm on token usage, cache repeated answers and route simple requests to smaller models. The AWS guide for AI and Forward Deployed Engineers walks through this architecture end to end.

Interview tip: If you want to take AWS skills into building AI systems inside customer environments, that is the work Cloudsoft's FDE PRO program trains for.

Real-world scenario questions

57. Scenario: you cannot SSH or RDP to an EC2 instance. How do you troubleshoot?

Answer: Work along the path from your laptop to the process, one layer at a time, and avoid changing several things at once.

What I would check:

1. Instance state and status checks. A failed system check points to AWS hardware (stop/start moves it to a new host); a failed instance check points to the OS (kernel, full disk, bad fstab). Use the serial console or get-console-output.
2. Addressing: does it have a public IP or Elastic IP, and did the IP change after a stop/start?
3. Subnet route table: is there a route to an internet gateway, or are you meant to come in over VPN/Direct Connect?
4. Security group inbound rule for port 22 or 3389 from your current IP, and network ACL rules in both directions including ephemeral ports.
5. OS level: is sshd running, is a host firewall blocking, is the right key in authorized_keys for the right user?
6. Try Session Manager or EC2 Instance Connect Endpoint, which do not need an open inbound port.

Production consideration: Stop depending on SSH: use Session Manager with logged sessions. Linux-side checks are covered in these Linux commands interview questions.

58. Scenario: the key pair for a Linux instance is lost, or a Windows administrator password is unknown. What do you do?

Answer: You cannot change an instance's key pair from the console after launch, because the key is just a public key placed in authorized_keys at first boot. If the SSM Agent is running and the instance has a role, connect with Session Manager and add a new public key or reset the Windows password directly. Otherwise run the AWSSupport-ResetAccess Automation runbook, which uses EC2Rescue to inject a new SSH key (Linux) or re-enable password decryption (Windows); it stops the instance and creates a backup AMI first.

What I would check:

1. Is the root volume EBS-backed? Instance store data is lost on stop.
2. Is an Elastic IP attached, or will the public IP change?
3. Manual fallback: stop the instance, detach the root volume, attach it to a helper instance in the same AZ, edit authorized_keys, reattach and start.

Production consideration: Make this a non-event by using Session Manager and short-lived EC2 Instance Connect keys instead of shared key pairs.

59. Scenario: instances in a private subnet cannot reach the internet or S3. What would you check?

Answer: Private subnets have no internet route by design, so the question is which path they are supposed to use and where it breaks.

What I would check:

1. The private subnet's route table: is 0.0.0.0/0 pointing to a NAT gateway, and is that NAT gateway available?
2. For a zonal NAT gateway: is it in a public subnet whose route table points to the internet gateway, with an Elastic IP?
3. Security group outbound rules and NACL rules for return traffic on ephemeral ports.
4. For S3: is there a gateway endpoint associated with this route table, and does the endpoint policy or bucket policy (for example an aws:SourceVpce condition) allow the request? Remember gateway endpoints only serve the same Region.
5. Use VPC Reachability Analyzer and VPC Flow Logs to confirm where packets are dropped.

Production consideration: Add gateway endpoints for S3 and DynamoDB in every VPC by default; it removes a failure point and NAT data charges.

60. Scenario: how would you prevent an S3 data leak across a company with many accounts?

Answer: Use preventive controls at organization level, then detective controls, then response, so no single bucket owner's mistake becomes a breach.

What I would check:

1. Block Public Access enforced at organization or account level, with an SCP denying changes to it except by a break-glass role.
2. An RCP or bucket policies restricting access to principals in the organization (aws:PrincipalOrgID) and, for sensitive buckets, to specific VPC endpoints.
3. IAM Access Analyzer for external and public access findings, Macie for sensitive data discovery, AWS Config rules and Security Hub controls for public buckets.
4. CloudTrail data events on sensitive buckets, GuardDuty S3 protection for unusual access, and alerts to the security team.
5. Pre-signed URLs with short expiry for sharing, instead of making objects public.

Production consideration: Consider an Indian bank: static marketing content may genuinely need public read through CloudFront with OAC, while customer KYC documents must never be public. Make the exceptions explicit and reviewed.

61. Scenario: design a highly available three-tier web application on AWS.

Answer: Spread every tier across at least two AZs, keep only the load balancer public, and make the application tier stateless so Auto Scaling can replace instances freely.

Users
  |
Route 53 --> CloudFront + WAF
  |
ALB (public subnets, AZ-a / AZ-b)
  |
App tier: ASG or ECS service (private subnets)
  |            \
  |             ElastiCache (sessions, cache)
  |
Aurora / RDS Multi-AZ (isolated DB subnets)

S3 (static assets, via CloudFront OAC)
NAT or endpoints for outbound; KMS everywhere

What I would check:

1. Security groups chained: ALB SG to app SG to DB SG, nothing open to the world except 443 on the ALB.
2. Sessions out of the instances (ElastiCache or DynamoDB), uploads to S3.
3. Target tracking scaling, ELB health checks, CloudWatch alarms and dashboards, centralised logs.
4. Backups, a tested restore, and the whole stack in IaC so it can be recreated in another Region.

Production consideration: State the RTO/RPO you are designing for. A multi-AZ design handles AZ loss; a Regional outage needs one of the DR strategies in Q51.

62. Scenario: the monthly AWS bill has jumped sharply. How do you investigate?

Answer: Find which service, account, Region and usage type changed before guessing, then decide whether it is legitimate growth, waste or abuse.

What I would check:

1. Cost Explorer grouped by service, then linked account, Region and usage type, daily granularity, compared with the previous period.
2. Usual suspects: NAT gateway data processing, inter-AZ or internet data transfer, forgotten GPU or large instances, unattached EBS volumes and snapshots, CloudWatch Logs ingestion, S3 request spikes, Lambda in a retry loop.
3. Resources in Regions nobody uses, or many new instances: check CloudTrail for who created them; compromised credentials often mine crypto in unusual Regions.
4. Expiring Savings Plans or Reserved Instances that silently moved usage to On-Demand.

Production consideration: Prevent the repeat with budgets per account and team, mandatory cost tags enforced by tag policies, SCPs denying unused Regions, and a weekly cost review owned by engineering.

63. Scenario: an application in account A must read objects from a bucket and call an API in account B. How do you set up cross-account access?

Answer: Prefer role assumption. In account B, create a role whose trust policy allows the specific role from account A (not the whole account root, unless you then control it on A's side), and whose permissions allow only the needed actions. In account A, allow the application's role to call sts:AssumeRole on that role ARN. For a third-party SaaS vendor, require an external ID in the trust policy to prevent the confused-deputy problem.

What I would check:

1. Both sides allow: A's identity policy and B's trust policy (or B's bucket policy if using resource-based access directly).
2. KMS: if the bucket uses SSE-KMS, the key policy in B must allow A's principal to decrypt, and A's role needs kms:Decrypt.
3. SCPs or RCPs in either account that might deny the call.
4. Object ownership: with ACLs disabled, the bucket owner owns objects written by A, which avoids old ownership problems.

Production consideration: At scale, use aws:PrincipalOrgID conditions instead of listing accounts, and AWS RAM to share subnets or Transit Gateways.

64. Scenario: your primary AWS Region has a major outage. What happens and what do you do?

Answer: What happens depends entirely on the DR strategy chosen before the outage. Your job in the interview is to describe the decision, the failover mechanics and the data question.

What I would check:

1. Confirm scope with the AWS Health Dashboard and your own metrics; decide to fail over against pre-agreed criteria, not panic.
2. Data first: promote the Aurora Global Database secondary, rely on DynamoDB global tables, or restore from cross-Region backups. Note the actual RPO.
3. Bring up or scale the DR stack from IaC and pre-copied AMIs; make sure service quotas in the DR Region were raised in advance.
4. Shift traffic with data-plane mechanisms: Route 53 failover health checks or Amazon Application Recovery Controller routing controls, or Global Accelerator traffic dials, rather than relying on control-plane edits during the event.
5. Check dependencies that are secretly Regional: secrets, KMS keys (use multi-Region keys), parameters, container images (ECR replication), certificates.

Production consideration: Run game days. A failover runbook that has never been executed will fail on something small like a missing secret or quota.

65. Scenario: users intermittently get 502 and 504 errors from an Application Load Balancer. How do you debug?

Answer: 5xx codes generated by the ALB itself tell you the problem is between the ALB and the targets, so correlate ALB metrics with target behaviour.

What I would check:

1. CloudWatch: HTTPCode_ELB_5XX_Count versus HTTPCode_Target_5XX_Count, TargetResponseTime, healthy host count per AZ.
2. 504: the target took longer than the idle timeout; check slow queries or downstream calls, and align the ALB idle timeout with the app.
3. 502: the target closed the connection or sent a malformed response; a common cause is the app's keep-alive timeout being shorter than the ALB idle timeout, or crashes during deployments.
4. 503: no healthy targets; check health check path, ports and security groups from the ALB SG.

Production consideration: Add alarms on target 5xx and latency percentiles, not just averages, and use slow start for new targets.

66. Scenario: a Lambda function in a VPC times out when calling DynamoDB and a third-party API. What is wrong?

Answer: A VPC-attached function has no internet access by default, even in a public subnet, because its network interfaces never get public IPs. Calls hang until the function timeout.

What I would check:

1. Function subnets are private subnets with a route to a NAT gateway for the third-party API.
2. A DynamoDB gateway endpoint (or interface endpoint) on the route tables of those subnets.
3. SDK timeouts and retries set lower than the function timeout, so failures surface quickly instead of burning the full duration.
4. Whether the function needs the VPC at all; if it only calls public AWS APIs and the internet, removing VPC attachment is simpler.

Production consideration: Watch the Duration, Throttles and Errors metrics together; a timeout loop with retries from an event source can multiply cost quickly.

67. Scenario: someone ran a bad DELETE on a production RDS database an hour ago. How do you recover?

Answer: Do not touch the live instance in a panic. Restore to a point in time just before the delete as a new instance, extract the lost data and decide whether to copy it back or cut over.

What I would check:

1. Exact time of the statement from application logs, database logs or audit logs, so the restore point is precise.
2. Run point-in-time restore to a new instance with the same parameter and option groups, subnet group and security groups.
3. Compare and copy the deleted rows back into production, or switch the application endpoint if a full rollback is acceptable.
4. Afterwards: remove direct write access for humans in production, require reviewed migrations, and test restores regularly.

Production consideration: Multi-AZ and read replicas do not help here: they replicate the delete faithfully. Only backups do.

68. Scenario: you need to move an EC2 instance to another AZ, Region or VPC. How?

Answer: You cannot move a running instance between AZs, Regions or VPCs; you recreate it from an image. For a single instance: create an AMI (or use AWS Backup), copy the AMI to the target Region if needed (with its KMS key re-encrypted for that Region), then launch in the target subnet, AZ or VPC with the right security groups, role and Elastic IP. Update DNS and retire the old one.

What I would check:

1. Data on instance store volumes is not in the AMI; copy it separately.
2. Hard-coded IPs, licences tied to MAC addresses, and Region-specific endpoints in configuration.
3. For many servers, use AWS Application Migration Service or redeploy from IaC rather than hand-copying AMIs.

Production consideration: If moving instances is common, the real fix is an Auto Scaling group spanning AZs and a pipeline that builds images, so placement becomes configuration.

69. Scenario: a CloudFormation stack is stuck in UPDATE_ROLLBACK_FAILED. What do you do?

Answer: The rollback could not restore a resource, often because someone changed or deleted it outside CloudFormation, a dependency is missing, or a permission or quota blocks the rollback.

What I would check:

1. Stack events for the first failure and the exact resource and error message.
2. Fix the underlying cause if possible (recreate a deleted dependency, restore a permission, raise a quota).
3. Run "Continue update rollback"; if a resource still cannot roll back, skip it with the resources-to-skip option, knowing the stack and reality will then differ.
4. Next time, use change sets and avoid manual edits to stack-managed resources.

Production consideration: Keep stateful resources (databases, buckets) in separate, rarely changed stacks with retention policies, so application deployments cannot put them at risk.

70. Scenario: for security reasons the company wants some workloads moved back to private servers while the rest stays on AWS. What architecture would you suggest?

Answer: A hybrid architecture with clear placement rules, private connectivity and one operating model across both sides.

What I would check:

1. Why: the specific regulation, data classification or latency need, so you move only what must move.
2. Connectivity: Direct Connect with Site-to-Site VPN backup into a Transit Gateway, with non-overlapping IP plans and Route 53 Resolver endpoints for hybrid DNS.
3. Placement options: on-premises servers, AWS Outposts if they want AWS APIs on site, or dedicated tenancy and stricter controls in AWS if "private" really means isolation.
4. Operations: Systems Manager hybrid activations so on-premises servers are patched and inventoried like EC2, central logging and consistent backup.

Production consideration: Often the concern can be met inside AWS with dedicated accounts, private endpoints, customer managed keys and SCPs; test that before building a second data centre.

Key takeaways

• AWS interview questions in 2026 test reasoning across layers: identity, network, compute, data and operations, not isolated definitions.
• Know policy evaluation cold: explicit deny wins, guardrails (SCPs, RCPs, boundaries) only limit, and cross-account access needs both sides to allow.
• Be able to draw a multi-AZ VPC with public, private and database subnets, NAT and gateway endpoints, and explain each route.
• Quote current facts with care: 50 TB S3 objects, 10,000 default buckets, 1 MiB SQS messages, four Savings Plans types, six Well-Architected pillars.
• Resilience answers need numbers from the business (RTO and RPO) and a tested backup, because replication copies mistakes too.
• Cost questions reward a method: find the change by service, account, Region and usage type before proposing fixes.
• Practise the scenarios aloud with a checklist; a structured troubleshooting path matters more than knowing every command.

Interview preparation checklist

• Build a two-AZ VPC from scratch in CloudFormation, CDK or Terraform, with NAT, a gateway endpoint and flow logs.
• Deploy a three-tier app: ALB, Auto Scaling group or ECS on Fargate, RDS Multi-AZ, secrets in Secrets Manager.
• Write an identity policy, a bucket policy, a permissions boundary and an SCP, and test them with the IAM policy simulator.
• Set up cross-account role assumption between two accounts, including a KMS-encrypted bucket.
• Break things on purpose: remove a route, close a security group, fail a health check, and fix them using Reachability Analyzer and logs.
• Restore an RDS database to a point in time and an S3 object from a previous version.
• Create a budget and cost allocation tags, and read a Cost Explorer breakdown.
• Re-check service quotas and recent naming changes on docs.aws.amazon.com the week of the interview.

FAQ

How should I prepare for an AWS interview in 2026?

Combine concepts with hands-on labs. Build a VPC, a three-tier application and a cross-account setup in your own account, then practise explaining each design choice and troubleshooting path aloud. Interviewers value a clear method and real experience over memorised service lists.

Which AWS services matter most for a cloud engineer interview?

IAM, VPC, EC2, Auto Scaling, Elastic Load Balancing, S3, RDS, CloudWatch, CloudTrail and CloudFormation or Terraform form the core. After that, Lambda, ECS or EKS, Route 53, CloudFront, KMS and Secrets Manager appear frequently in mid-level and senior rounds.

What is the difference between an AWS cloud engineer and an AWS solutions architect interview?

Cloud engineer interviews lean towards building, operating and troubleshooting: networking issues, deployments, monitoring and scripts. Solutions architect interviews lean towards design and trade-offs: multi-account structure, DR strategy, cost, security controls and explaining decisions to stakeholders.

Do I need an AWS certification to get a cloud job?

A certification can help you get shortlisted and gives structure to your learning, but interviews test practical understanding. Hands-on projects you can explain in detail usually carry more weight than a certificate alone.

Are AWS interview questions different for freshers?

Yes. Freshers are usually asked fundamentals: Regions and AZs, IAM basics, VPC and subnets, EC2, S3 storage classes and security groups. Expect to explain a simple architecture and possibly perform basic console or CLI tasks.

How many scenario-based questions should I expect in an AWS interview?

It varies by company and level, but most mid-level and senior rounds include at least one or two troubleshooting or design scenarios, such as an unreachable instance, a cost spike or a Region failure. Practise answering them with a structured checklist.

Do I need to know Linux and networking for AWS roles?

Yes. Many AWS problems are really Linux or networking problems: SSH access, routing, DNS, ports, disk space and processes. Solid Linux and TCP/IP basics make AWS troubleshooting much easier.

Is AWS still a good career choice with AI growing so fast?

Yes. AI applications still run on cloud infrastructure that needs identity, networking, security, cost control and operations. Engineers who combine AWS fundamentals with an understanding of services such as Bedrock and SageMaker AI are well placed for cloud and AI platform roles.

Ready to turn these answers into hands-on experience? Cloudsoft's AWS course in Ameerpet, Hyderabad covers IAM, VPC, compute, storage, databases, IaC and troubleshooting labs, in the classroom or live online. If you want AWS as part of a broader AI, ML, cloud and security track, look at the APEX AI, ML, Cloud and Cyber Security program. For a free demo, call +91 96660 19191.

Related Cloudsoft resources

• AWS serverless services interview questions
• AWS for AI and Forward Deployed Engineers
• Terraform interview questions 2026
• Kubernetes interview questions
• Linux commands interview questions
• Amazon Bedrock interview questions and answers