Question 1

Explain the difference between an AWS Region, an Availability Zone and an edge location.

Accepted Answer

A Region is a separate geographic area, like us-east-1 or eu-west-1. Regions are isolated from each other, most services are Regional, and your data stays in a Region unless you move or replicate it, which matters for latency, compliance and data residency. An Availability Zone is one or more discrete data centers inside a Region, with independent power, cooling and networking, linked to the other AZs by low-latency connections. Every Region has several AZs, and spreading resources across at least two of them is the basic high-availability pattern: if one AZ fails, the others keep serving. Edge locations are points of presence in many more cities than there are Regions. CloudFront, Route 53 and AWS Global Accelerator use them to cache content, answer DNS queries and terminate connections close to users. I'd also mention Local Zones and Wavelength Zones, which push compute closer to specific metro areas or 5G networks.

Question 2

What is the AWS shared responsibility model? Give examples of what AWS is responsible for and what you are responsible for.

Accepted Answer

AWS is responsible for security of the cloud; the customer is responsible for security in the cloud. - AWS: the physical data centers, hardware, global network and virtualization layer, plus the software that runs its managed services. - Customer: your data, IAM users, roles and permissions, encryption choices, network rules such as security groups and NACLs, and how you configure every service you use. The line moves with the type of service. On EC2 (infrastructure as a service) you patch the guest OS, the runtime and your application. On RDS, AWS patches the database engine and OS, but you still own database users, network access, encryption and backup settings. On Lambda or S3 AWS manages even more, yet the code, the data and the access policies are still yours. A classic example: a publicly readable S3 bucket, or a security group that opens SSH to 0.0.0.0/0, is the customer's problem, not AWS's.

Question 3

Compare the EC2 pricing models: On-Demand, Reserved Instances, Savings Plans and Spot. When would you use each?

Accepted Answer

- On-Demand: pay for compute by the second or hour with no commitment. Best for spiky, short-lived or unpredictable workloads, and for anything you haven't sized yet. - Savings Plans: commit to a consistent spend per hour for 1 or 3 years in exchange for a discount. Compute Savings Plans apply across instance families and Regions, and also to Fargate and Lambda; EC2 Instance Savings Plans give a deeper discount but are tied to one instance family in one Region. - Reserved Instances: the older commitment model, 1 or 3 years for specific instance attributes. Standard RIs have the biggest discount; Convertible RIs can be exchanged. Zonal RIs also reserve capacity. - Spot: spare capacity at a steep discount, but AWS can reclaim it with a two-minute warning. Use it for fault-tolerant, stateless or flexible work such as batch, CI, big data and containers. A common strategy: a Savings Plan for the steady baseline, On-Demand for the variable part, and Spot for interruptible capacity.

Question 4

What are IAM users, groups, roles and policies, and how do they relate to each other?

Accepted Answer

- Users are identities for a person or workload with long-term credentials: a console password and/or access keys. - Groups are collections of users. Attaching policies to a group is how you manage permissions for many users at once. Groups can't be nested and can't be used as a principal in a policy. - Roles are identities without long-term credentials. A trusted principal (an EC2 instance, a Lambda function, a user in another account, a federated user) *assumes* the role and gets temporary credentials from STS. - Policies are JSON documents made of statements with Effect, Action, Resource and an optional Condition. Identity-based policies attach to users, groups or roles; resource-based policies, like bucket policies, attach to a resource and name a Principal. Current best practice: people sign in through IAM Identity Center or federation, workloads use roles, IAM users with access keys are the exception, and the root user is locked away with MFA.

Question 5

What is the difference between a security group and a network ACL?

Accepted Answer

- Scope: a security group is attached to network interfaces, so effectively to instances, load balancers or Lambda functions in a VPC. A network ACL applies to a whole subnet. - State: security groups are stateful: if a request is allowed in, the response is allowed out automatically. NACLs are stateless: you must allow the return traffic explicitly, usually the ephemeral port range. - Rules: security groups have only allow rules, all evaluated together. NACLs have numbered allow and deny rules, evaluated from the lowest number, and the first match wins. - Defaults: a new security group allows all outbound and no inbound traffic. The default NACL allows everything; a new custom NACL denies everything until you add rules. Security groups can use another security group as the source, which is how you say "only the load balancer may reach the app tier". I use security groups as the main control and NACLs as a coarse subnet guardrail, for example to block a known bad CIDR range.

Question 6

Walk me through the main S3 storage classes and when you would use each.

Accepted Answer

- S3 Standard: frequently accessed data with millisecond access. The default. - S3 Intelligent-Tiering: unknown or changing access patterns. S3 moves objects between access tiers automatically for a small per-object monitoring fee, with no retrieval charges. - S3 Standard-IA and S3 One Zone-IA: infrequently accessed data that still needs millisecond access. Cheaper storage, but per-GB retrieval fees and a minimum storage duration. One Zone-IA keeps data in a single AZ, so use it only for data you can re-create. - S3 Glacier Instant Retrieval: archives read rarely, say once a quarter, but needed in milliseconds. - S3 Glacier Flexible Retrieval: archives restored in minutes to hours. - S3 Glacier Deep Archive: the cheapest class, for long-term retention such as compliance data, restored within hours. - S3 Express One Zone: single-AZ, single-digit-millisecond latency for performance-critical workloads, using directory buckets. Apart from the One Zone classes, data is stored across multiple AZs. Lifecycle rules move objects down the tiers as they age.

Question 7

What makes a subnet public or private in a VPC, and how do instances in a private subnet reach the internet?

Accepted Answer

A subnet is public when its route table sends 0.0.0.0/0 (and ::/0 for IPv6) to an internet gateway. Instances there also need a public IPv4 or Elastic IP address to be reachable. A private subnet has no route to the internet gateway. Private instances that need outbound access, for patches or third-party APIs, get a route to a NAT gateway. The NAT gateway translates their private addresses to its own public IP and only allows connections initiated from inside, so nothing on the internet can open a connection to them. For IPv6 the equivalent is an egress-only internet gateway. A classic (zonal) NAT gateway sits in a public subnet of one AZ, so for high availability you deploy one per AZ and point each private route table at the NAT gateway in its own AZ. AWS has also added a regional NAT gateway mode that spans AZs automatically. If the traffic is only to services like S3 or DynamoDB, VPC endpoints avoid NAT charges entirely.

Question 8

When would you choose an Application Load Balancer, a Network Load Balancer or a Gateway Load Balancer?

Accepted Answer

- ALB works at layer 7 (HTTP, HTTPS, gRPC, WebSockets). It routes by host, path, headers, query string or source IP to target groups of instances, IP addresses, containers or Lambda functions. It terminates TLS, integrates with AWS WAF and can authenticate users through Cognito or any OIDC provider. It's the default for web apps and microservices. - NLB works at layer 4 (TCP, UDP, TLS). It handles very high throughput at low latency, gives you a static IP per AZ (you can bring Elastic IPs) and can preserve the client's source IP. Use it for non-HTTP protocols, extreme performance, fixed IPs that partners allowlist, or in front of a PrivateLink endpoint service. - GWLB works at layer 3 and inserts fleets of third-party virtual appliances, like firewalls or intrusion detection, transparently into the traffic path. It talks to the appliances with GENEVE encapsulation and is reached through Gateway Load Balancer endpoints. The Classic Load Balancer is legacy; I wouldn't use it for new designs.

Question 9

What is the difference between RDS Multi-AZ and read replicas?

Accepted Answer

They solve different problems: Multi-AZ is for availability, read replicas are for read scaling. - Multi-AZ DB instance deployment: RDS keeps a synchronous standby in another AZ that serves no traffic. If the primary or its AZ fails, RDS fails over automatically by pointing the same DNS endpoint at the standby, typically within a minute or two, without losing committed transactions. - Multi-AZ DB cluster deployment (RDS for MySQL and PostgreSQL): a writer plus two readable standbys in three AZs, so you get failover and some read capacity. - Read replicas use asynchronous replication, so they can lag behind. Each has its own endpoint, the application must send reads to it, and it can live in another Region. Promoting a replica to a standalone database is a manual step, which makes a cross-Region replica a handy DR building block. Many production setups use both: Multi-AZ for the primary, plus read replicas for reporting or read-heavy traffic.

Question 10

Design a highly available three-tier web application on AWS.

Accepted Answer

I'd spread every tier across at least two, ideally three, Availability Zones in one Region.

Edge: Route 53 for DNS, CloudFront for static assets and caching, AWS WAF on CloudFront or the load balancer.
Web and app tier: an internet-facing ALB in public subnets forwarding to an Auto Scaling group (or ECS services) in private subnets. ELB health checks replace bad instances, target tracking scales on CPU or request count, and instances are stateless: sessions in ElastiCache or DynamoDB, uploads in S3.
Data tier: RDS Multi-AZ or Aurora in private database subnets, with read replicas or ElastiCache for read-heavy traffic, and automated backups with point-in-time recovery.
Network: security groups chained ALB to app to database, a NAT gateway per AZ, VPC endpoints for S3.
Operations: everything in infrastructure as code, CloudWatch alarms, CloudTrail, secrets in Secrets Manager.

Then I'd say what it survives (an instance or AZ failure) and what it doesn't (a Regional outage), and propose a DR strategy if the RTO requires one.

Question 11

How does an EC2 Auto Scaling group work, and what is a launch template?

Accepted Answer

A launch template is a versioned definition of how to launch an instance: AMI, instance type, key pair, security groups, IAM instance profile, user data, volumes and tags. It replaces the older launch configurations, which AWS has deprecated. An Auto Scaling group uses a launch template to keep a fleet between a minimum and maximum size, aiming at a desired capacity. It spreads instances across the subnets (AZs) you give it, replaces unhealthy instances and registers new ones with load balancer target groups. Scaling options: - Target tracking: keep a metric such as average CPU at 50%. Usually the best default. - Step and simple scaling driven by CloudWatch alarms. - Scheduled scaling for known peaks and predictive scaling from historical patterns. Use the ELB health check type so instances that are running but failing the app's health check get replaced. Also worth knowing: lifecycle hooks, instance refresh for rolling AMI updates, warm pools, and mixed instances policies that combine On-Demand and Spot.

Question 12

What is the difference between EBS volumes and instance store volumes?

Accepted Answer

EBS is network-attached block storage. A volume lives in one AZ, persists independently of the instance, can be detached and reattached, and can be backed up with snapshots, which are incremental, stored by AWS in S3 and copyable across Regions. Volume types include general purpose SSD (gp3, gp2), provisioned IOPS SSD (io2, io1) and HDD types for throughput or cold data (st1, sc1). With gp3 you set IOPS and throughput independently of the volume size. Instance store is disk physically attached to the host. It's very fast and included in the instance price, but it's ephemeral: data survives a reboot but is lost when the instance stops, hibernates or terminates, or if the underlying hardware fails. Only some instance types have it. So EBS for root volumes, self-managed databases and anything that must persist; instance store for caches, scratch space, buffers, or data that is already replicated elsewhere, such as nodes of a distributed database.

Question 13

Compare S3, EBS and EFS. Which would you use for what?

Accepted Answer

- S3 is object storage: objects in buckets, accessed over an HTTPS API. It scales virtually without limit, stores data across multiple AZs by default, and suits static assets, backups, data lakes, logs and media. It isn't a file system you mount for low-latency random writes. - EBS is block storage attached to a single EC2 instance (except Multi-Attach on some provisioned IOPS volumes). It's scoped to one AZ, low latency, and what you use for boot volumes and databases you run yourself. - EFS is a managed NFS file system: many instances, containers and Lambda functions across AZs can mount it at the same time, it grows and shrinks automatically, and you pay for the storage you use. Good for shared content, home directories and lift-and-shift apps that expect a POSIX file system. For Windows file shares, high-performance computing or NetApp compatibility there's the FSx family, such as FSx for Windows File Server, FSx for Lustre and FSx for NetApp ONTAP.

Question 14

Compare SQS, SNS, EventBridge and Kinesis. How do you decide which one to use?

Accepted Answer

- SQS is a queue: producers send messages, consumers poll and delete them. It decouples services and buffers load, and each message is handled by one consumer. It comes as standard or FIFO. - SNS is push-based pub/sub: a message published to a topic fans out to many subscribers, such as SQS queues, Lambda functions, HTTP endpoints, email or SMS. SNS to several SQS queues is the classic fan-out, giving each consumer its own durable copy. - EventBridge is an event bus with content-based routing: rules match fields in the event JSON and send matches to many kinds of targets. It receives events from AWS services and SaaS partners and supports archive and replay. Best for event-driven integration. - Kinesis Data Streams is a stream: records are ordered per shard by partition key and retained for a set period, so several consumers read independently and can replay. Use it for high-throughput real-time data like clickstreams, logs and IoT. Rule of thumb: work queue, SQS; fan-out, SNS; routing events between services, EventBridge; ordered, replayable streams, Kinesis.

Question 15

How do you choose between RDS, Aurora and DynamoDB?

Accepted Answer

- RDS runs managed relational engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server and Db2. Pick it for a standard or commercial engine, SQL joins and transactions, when the load fits one primary plus replicas. - Aurora is AWS's MySQL- and PostgreSQL-compatible engine with a distributed storage layer: data is copied across three AZs, storage grows automatically, replicas share the same volume so lag is low, and failover is fast. It adds Global Database for cross-Region reads and DR, and Aurora Serverless v2 for variable load. Choose it for demanding relational workloads, usually at a higher price than RDS. - DynamoDB is a serverless key-value and document database with consistent single-digit-millisecond latency at virtually any scale. You design tables around known access patterns (partition and sort keys, GSIs); there are no joins and ad hoc queries are limited. Great for sessions, carts, user profiles, IoT and other high-scale, key-based access. So: relational data with flexible queries, RDS or Aurora; massive scale with well-known key-based access, DynamoDB.

Question 16

What is a Lambda cold start, and how do you reduce its impact?

Accepted Answer

When no idle execution environment is available, Lambda must create one: load your code, start the runtime and run the initialization code outside your handler. That Init phase adds latency to that request, which is the cold start. The environment is then reused for later invocations until Lambda recycles it.

Ways to reduce it:

Keep the package small and load only what you need; heavy frameworks and big dependency trees hurt most.
Do expensive setup once, outside the handler: SDK clients, connections, configuration.
Provisioned concurrency keeps a set number of environments initialized. It costs extra and suits latency-sensitive APIs.
SnapStart (recent Java, Python and .NET runtimes) resumes new environments from a snapshot of an initialized one. It can't be combined with provisioned concurrency.
More memory also means proportionally more CPU, which speeds up init.

Cold starts usually hit a small share of requests, so I'd measure first, using the Init Duration in the logs or traces.

Question 17

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

Accepted Answer

- Operational Excellence: run and monitor systems and keep improving: infrastructure as code, small reversible changes, observability, learning from failures. - Security: protect data and systems: a strong identity foundation with least privilege, traceability, security at every layer, encryption in transit and at rest. - Reliability: recover from failures and meet demand: automatic recovery, horizontal scaling, tested recovery procedures, managed change. - Performance Efficiency: use resources efficiently as demand and technology change: pick the right services, use serverless, go global quickly, experiment. - Cost Optimization: avoid unnecessary spend: pay for consumption, right-size, measure efficiency, attribute costs to owners. - Sustainability: reduce environmental impact: maximize utilization, prefer managed services, shrink the resources your workload needs. The pillars trade off against each other; multi-Region reliability, for instance, costs more. The AWS Well-Architected Tool lets you review a workload against each pillar's questions, and lenses extend it for areas like serverless.

Question 18

How do IAM roles and STS AssumeRole work?

Accepted Answer

A role has two kinds of policy: - A trust policy, a resource-based policy on the role that says *who* may assume it: an AWS service such as lambda.amazonaws.com, an account, a specific role, or a federated identity provider. - Permissions policies that say *what* the role can do once assumed. A trusted principal calls sts:AssumeRole (for cross-account access its own identity policy must also allow that action) and gets temporary credentials: an access key ID, a secret access key and a session token. They last for the session duration, one hour by default and configurable up to the role's maximum, then expire on their own, so there's nothing long-lived to leak or rotate. Services use this behind the scenes: EC2 instance profiles, Lambda execution roles and ECS task roles all give the workload temporary credentials that the SDK refreshes automatically. Roles are also the standard mechanism for cross-account access, and AssumeRoleWithWebIdentity and AssumeRoleWithSAML cover federation.

Question 19

Explain the disaster recovery strategies on AWS and how they relate to RPO and RTO.

Accepted Answer

RPO (recovery point objective) is how much data you can afford to lose, measured in time; RTO (recovery time objective) is how long you can be down. AWS's DR whitepaper describes four strategies, from cheapest to most expensive: - Backup and restore: back up data, AMIs and IaC to another Region; after a disaster, redeploy and restore. RPO and RTO in hours. - Pilot light: data is replicated continuously to live data stores in the DR Region and core infrastructure exists, but app servers are switched off until needed. Tens of minutes. - Warm standby: a scaled-down but fully working copy runs all the time and can take traffic immediately; you scale it up. Minutes. - Multi-site active/active: full capacity in several Regions, all serving traffic. Near-zero RTO, and near-zero RPO with asynchronous replication. Tools include AWS Backup, S3 replication, Aurora Global Database, DynamoDB global tables and Route 53 health checks. Two strong points: fail over with data plane operations, and remember replication also copies corruption, so keep point-in-time backups and test the plan.

Question 20

How do you control access to an S3 bucket? Compare IAM policies, bucket policies, ACLs and Block Public Access.

Accepted Answer

- IAM identity policies grant your own users and roles access to buckets and objects. Best for managing what a principal can do across many resources. - Bucket policies are resource-based policies on the bucket. Use them for cross-account access, service principals like CloudFront, and bucket-wide guardrails such as denying non-TLS requests or requiring a specific VPC endpoint. - ACLs are the legacy, pre-IAM mechanism. New buckets default to the Object Ownership setting "bucket owner enforced", which disables ACLs, and AWS recommends keeping them off. - Block Public Access overrides policies and ACLs to stop public access. It's on by default for new buckets and can also be enforced for the whole account. Buckets are private by default. Within one account an allow in either the IAM policy or the bucket policy is enough, and an explicit deny anywhere wins. Access points help with shared datasets, and IAM Access Analyzer flags buckets shared publicly or with other accounts.

Question 21

How do S3 versioning and lifecycle rules work, and how would you use them together?

Accepted Answer

Versioning keeps every version of an object. An overwrite creates a new version, and a delete without a version ID only adds a delete marker, so the previous version can be restored. It protects against accidental deletes and overwrites, and replication requires it. Once enabled it can be suspended but never fully turned off. MFA Delete and Object Lock add stronger protection. Lifecycle rules act on objects by age, scoped by prefix or tags: - Transition objects to cheaper classes, for example Standard to Standard-IA after 30 days, then to Glacier. - Expire current versions after a retention period. - Expire noncurrent versions so versioning doesn't grow your bill forever. - Abort incomplete multipart uploads and clean up expired delete markers. Together: version the bucket for protection, and let lifecycle rules age data into cheaper tiers and trim old versions.

Question 22

What is the difference between CloudWatch, CloudTrail and X-Ray?

Accepted Answer

- CloudWatch is monitoring: metrics from AWS services plus your own custom metrics, logs with retention settings, Logs Insights queries and metric filters, alarms that notify through SNS or trigger actions like Auto Scaling, and dashboards. It answers "how is my system behaving?". - CloudTrail is the audit log of API calls: who did what, when, from where, on which resource. Management events are recorded by default and visible in the event history for 90 days; a trail delivers events to S3 for long-term retention, and data events such as S3 object reads are opt-in. It answers "who changed this?". - X-Ray is distributed tracing: follow one request through API Gateway, Lambda, containers and downstream calls, with a service map showing where latency and errors come from. AWS now recommends OpenTelemetry-based instrumentation over the older X-Ray SDKs. A classic gotcha: EC2 doesn't report memory or disk usage out of the box; you need the CloudWatch agent.

Question 23

Explain DynamoDB partition keys and sort keys. How do you choose them?

Accepted Answer

Every item is identified by its primary key:

Simple: a partition key only. DynamoDB hashes it to decide which physical partition stores the item, and GetItem needs the exact value.
Composite: partition key plus sort key. Items sharing a partition key form an item collection stored together and ordered by the sort key, so Query can fetch a range with begins_with, between or comparisons, in order.

Choosing keys starts from access patterns, not entities. The partition key should have high cardinality and spread traffic evenly, like userId or orderId, not status or today's date. The sort key models the one-to-many relationship or ordering you need, for example ORDER#2024-05-01#123 so a customer's orders come back sorted by date.

In single-table design, generic key names like PK and SK with prefixed values let one table hold several entity types. Patterns the table's key can't serve go to a GSI; a Scan should be the exception.

Question 24

What is the difference between SQS standard and FIFO queues?

Accepted Answer

- Standard queues offer nearly unlimited throughput, at-least-once delivery (a message is occasionally delivered more than once) and best-effort ordering. Consumers must be idempotent. - FIFO queues give ordering within a message group and exactly-once processing. The queue name ends in .fifo, every message carries a MessageGroupId, and a message sent again within the 5-minute deduplication interval is dropped, based on an explicit MessageDeduplicationId or content-based deduplication (a SHA-256 hash of the body). Throughput is lower than standard, though batching and high-throughput mode raise it a lot. Ordering is per message group, not global, so the group ID is your parallelism knob: different groups, say different customers, are processed in parallel, while messages within one group are strictly sequential. While a message in a group is in flight, the next message in that group isn't delivered. Use FIFO when order or duplicates really matter, such as commands against one account; otherwise use standard with idempotent consumers.

Question 25

What is the SQS visibility timeout, and how do dead-letter queues work?

Accepted Answer

When a consumer receives a message, SQS doesn't remove it; it hides it for the visibility timeout (30 seconds by default, up to 12 hours). The consumer must call DeleteMessage before it expires. If the consumer crashes or is too slow, the message reappears and another consumer gets it, which is how SQS avoids losing messages and also why duplicates happen.

So set the timeout above your processing time, extend it with ChangeMessageVisibility as a heartbeat for long jobs, and when Lambda consumes the queue set the visibility timeout to at least six times the function timeout, as AWS recommends.

A dead-letter queue catches poison messages. The source queue's redrive policy sets maxReceiveCount: once a message has been received that many times without being deleted, SQS moves it to the DLQ. Alarm on the DLQ's depth, inspect the messages, fix the bug, then redrive them back to the source queue. A FIFO queue needs a FIFO DLQ.

Question 26

How should an application running on EC2 get AWS credentials to call S3?

Accepted Answer

Never put access keys in the AMI, the code or config files. Create an IAM role that trusts ec2.amazonaws.com, give it least-privilege permissions (say s3:GetObject on one bucket prefix), and attach it to the instance through an instance profile, the container that passes a role to EC2.

The instance metadata service (IMDS) then serves temporary credentials for that role. The AWS SDKs and CLI find them automatically through the default credential provider chain and refresh them before they expire, so your code just creates an S3 client without any keys.

Worth adding: require IMDSv2, which needs a session token obtained with a PUT request and helps protect against SSRF attacks that try to steal credentials from the metadata endpoint. The same idea applies elsewhere: Lambda execution roles, ECS task roles, and EKS Pod Identity or IAM roles for service accounts on Kubernetes.

Question 27

How does AWS evaluate policies to decide whether a request is allowed?

Accepted Answer

Everything starts as an implicit deny: nothing is allowed unless a policy allows it. Then: - Explicit deny wins. AWS collects every applicable policy: Organizations SCPs and RCPs, resource-based policies, identity-based policies, permissions boundaries and session policies. If any statement denies the request, the answer is deny. - Guardrails must allow. SCPs (on principals) and RCPs (on resources) never grant anything; they set the maximum. If they don't allow the action, it's denied. - Something must grant. Within one account, an allow in either the identity-based or the resource-based policy is generally enough. Role trust policies and KMS key policies are exceptions that must allow the principal explicitly. - Boundaries and session policies intersect. If present, they must allow the action too. For cross-account requests both sides must allow: the caller's identity policy and the resource's policy (or the trust policy of a role to assume). In the snippet, every object action on reports/* is allowed except DeleteObject, because the explicit deny wins.

Question 28

What options do you have for encrypting data in S3?

Accepted Answer

At rest, S3 encrypts every new object by default with SSE-S3, using keys S3 manages. The other options: - SSE-KMS: keys in AWS KMS, either the AWS managed key or your own customer managed key. You get key policies controlling who can decrypt, CloudTrail records of key use, and rotation. Enable S3 Bucket Keys to cut KMS request volume and cost. - DSSE-KMS: dual-layer encryption with KMS keys, for specific compliance requirements. - SSE-C: you send your own key with every request and S3 doesn't store it. It's now disabled by default on new buckets and rarely the right choice. - Client-side encryption: encrypt before uploading, so S3 never sees plaintext. In transit, use HTTPS and enforce it with a bucket policy that denies requests where aws:SecureTransport is false. SSE-KMS with a customer managed key is the usual pick for separation of duties: someone with s3:GetObject but no kms:Decrypt on the key still can't read the data.

Question 29

What is an S3 presigned URL, and when would you use one?

Accepted Answer

A presigned URL grants time-limited access to one object operation, such as a GET to download or a PUT to upload, to someone who has no AWS credentials. Your backend signs the URL with its own credentials, and S3 checks the signature, the expiry and the signer's permissions when the request arrives. Typical uses: - Direct uploads from browsers or mobile apps: your API authorizes the user and returns a presigned PUT URL, so the file goes straight to S3 instead of streaming through your servers or API Gateway. - Private downloads: invoices, reports or media only an authenticated user should get. Things to know: the URL can only do what the signer is allowed to do. With Signature Version 4 the maximum lifetime is 7 days, and a URL signed with temporary credentials, such as a role's, stops working when those credentials expire. Anyone holding the URL can use it until then, so keep expiries short. For content behind CloudFront, use CloudFront signed URLs or signed cookies instead.

Question 30

What is CloudFront, and how does it improve performance and security?

Accepted Answer

CloudFront is AWS's content delivery network. Users are routed to a nearby edge location; if the object is cached there it's served immediately, otherwise CloudFront fetches it from the origin (an S3 bucket, an ALB, API Gateway or any HTTP server) over the AWS network, often through regional edge caches, and caches it. Performance: lower latency, less load on the origin, TLS terminated close to the user, compression, HTTP/2 and HTTP/3. Cache behaviors map path patterns to origins, each with a cache policy that sets TTLs and which headers, cookies and query strings form the cache key. Stale content is cleared with invalidations or, better, versioned file names. Security: AWS Shield Standard against common DDoS attacks, AWS WAF, HTTPS with ACM certificates, geographic restrictions, signed URLs or cookies for private content, and origin access control so an S3 origin only accepts requests from your distribution. For logic at the edge, CloudFront Functions handle lightweight header and URL rewrites, and Lambda@Edge handles heavier work.

Question 31

What routing policies does Route 53 support, and when would you use each?

Accepted Answer

- Simple: a single resource, such as one web server or load balancer. - Weighted: split traffic in proportions you choose, for example 90/10 for a canary or a gradual migration. - Latency-based: answer with the Region that gives the user the lowest latency; the usual choice for multi-Region active/active. - Failover: active-passive. Route 53 returns the primary while its health check passes, otherwise the secondary. The basis of DNS-level disaster recovery. - Geolocation: route by the user's continent, country or US state, for compliance, localized content or licensing. Always add a default record. - Geoproximity: route by the distance between users and your resources, with a bias to shift traffic toward or away from a location. - IP-based: route by the client's source IP ranges, for example a known ISP's CIDR blocks. - Multivalue answer: return up to eight healthy records at random. Most policies combine with health checks, and alias records point to AWS resources such as ALBs or CloudFront, even at the zone apex. Remember TTLs: failover only takes effect as clients' DNS caches expire.

Question 32

How do you connect multiple VPCs? Compare VPC peering and Transit Gateway.

Accepted Answer

VPC peering is a direct private connection between two VPCs, in the same or different accounts and Regions. There's no extra hop or bandwidth bottleneck, and you pay only for data transfer. But it's not transitive: if A peers with B and B peers with C, A can't reach C through B. CIDR ranges can't overlap, and with many VPCs you end up managing a full mesh of connections and route entries. Transit Gateway is a Regional hub-and-spoke router. Each VPC, VPN connection or Direct Connect gateway attaches once, and transit gateway route tables decide who can reach whom, so you can segment networks: prod can't reach dev, but everyone reaches shared services. Transit gateways in different Regions can peer with each other. The trade-off is cost: hourly charges per attachment plus per-GB data processing. So peering for a handful of VPCs or heavy point-to-point traffic, Transit Gateway once you have many VPCs or hybrid connectivity. To expose just one service rather than a whole network, use PrivateLink.

Question 33

What are ECS, EKS and Fargate, and how would you choose between them?

Accepted Answer

- ECS is AWS's own container orchestrator. You write task definitions (image, CPU, memory, ports, IAM task role) and run them as services that keep a desired count behind a load balancer. It's simpler than Kubernetes, tightly integrated with IAM, ALB and CloudWatch, and has no control plane fee. - EKS is managed Kubernetes: AWS runs the control plane and you get the standard Kubernetes API and ecosystem, like Helm and operators, plus portability to other clouds and on-premises. The cost is more complexity and a per-cluster fee. - Fargate isn't an orchestrator but a serverless compute engine for containers that works with both ECS and EKS. No EC2 instances to patch or scale; you pay for the vCPU and memory each task or pod requests. My default is ECS on Fargate for a team that wants containers on AWS with minimal operations; EKS when the team already runs Kubernetes or needs its ecosystem; EC2 capacity for either when you need GPUs, specific instance types, or the lowest cost at steady scale, often with Spot.

Question 34

What is the difference between a global secondary index and a local secondary index in DynamoDB?

Accepted Answer

- Key: a GSI can use a completely different partition key and optional sort key. An LSI keeps the table's partition key and only changes the sort key. - Lifecycle: GSIs can be added or deleted at any time. LSIs must be defined when the table is created and can't be added or removed later. - Consistency: GSIs support only eventually consistent reads; LSIs also support strongly consistent reads. - Capacity: a GSI has its own throughput and is updated asynchronously; an LSI uses the table's capacity. - Size: with an LSI, all items for one partition key value (table plus indexes) must stay within 10 GB; GSIs have no such limit. - Attributes: a GSI query returns only projected attributes, while an LSI can fetch the rest from the table. The default quotas are 20 GSIs and 5 LSIs per table. In practice I almost always use GSIs, and pick an LSI only for a strongly consistent alternate sort order known up front. Watch out: in provisioned mode, an under-provisioned GSI can throttle writes to the base table.

Question 35

What does least privilege mean in AWS, and how do you apply it in practice?

Accepted Answer

Least privilege means each identity gets only the permissions it needs for its task, on only the resources it needs, for only as long as it needs them. It limits the blast radius of a bug, a leaked credential or a compromised workload.

In practice:

Scope actions and resources: dynamodb:GetItem on one table ARN instead of dynamodb:* on *. Add conditions such as source VPC endpoint, tags or MFA.
Prefer roles with temporary credentials over IAM users with long-term access keys, one role per workload.
Tighten over time: AWS managed policies help you start, then IAM Access Analyzer can generate a policy from CloudTrail activity and flag unused or externally shared access, and last-accessed data shows permissions nobody uses.
Guardrails: SCPs in AWS Organizations and permissions boundaries cap what can ever be granted, for example when developers create their own roles.
People: federate through IAM Identity Center, require MFA, and don't use the root user day to day.

Review regularly, because permissions tend to accumulate.

Question 36

When would you use Secrets Manager instead of Systems Manager Parameter Store?

Accepted Answer

Both store values encrypted with KMS, are controlled with IAM, and can be read at runtime by Lambda, ECS, CloudFormation and your own code.

Secrets Manager is built for secrets:

Automatic rotation on a schedule, with managed rotation for database credentials such as RDS and Lambda-based rotation for anything else.
Replication of secrets to other Regions, and resource-based policies for cross-account access.
Priced per secret per month plus API calls.

Parameter Store is a general configuration store:

Hierarchical names like /app/prod/db-url, String, StringList and encrypted SecureString types, with version history.
The standard tier has no additional charge; the advanced tier allows larger values, more parameters and parameter policies such as expiration, for a fee.
No built-in rotation.

My rule: database passwords, API keys and anything that should rotate go in Secrets Manager; endpoints, feature flags and other configuration go in Parameter Store. Either way, cache values in the application instead of calling the API on every request.

Question 37

Compare CloudFormation, the AWS CDK and Terraform for infrastructure as code.

Accepted Answer

- CloudFormation is AWS's native IaC service. You write declarative JSON or YAML templates and deploy them as stacks; AWS keeps the state. You get change sets to preview updates, automatic rollback on failure, drift detection, and StackSets for many accounts and Regions. Downsides: verbose templates, and AWS only. - AWS CDK defines infrastructure in TypeScript, Python, Java, C# or Go. Constructs bundle sensible defaults or whole patterns, and you get loops, types and reuse. cdk synth produces a CloudFormation template, so deployment, state and rollback are still CloudFormation's. - Terraform uses HCL and providers for AWS and many other platforms, so one tool covers several clouds and SaaS products. terraform plan shows the diff before apply. You manage the state file yourself, typically in S3 with locking, and protect it because it can contain secrets. OpenTofu is an open-source fork. I'd pick CDK or CloudFormation for AWS-only teams that want managed state, and Terraform for multi-cloud setups or where it's already the organization's standard.

Question 38

What does API Gateway do, and how do REST APIs, HTTP APIs and WebSocket APIs differ?

Accepted Answer

API Gateway is a managed front door for APIs: routing, authorization, throttling, CORS, custom domains, stages and logging, with integrations to Lambda, HTTP backends, other AWS services, and private resources in a VPC through VPC links. - REST APIs have the most features: API keys and usage plans for per-client throttling, request validation and transformation, caching, AWS WAF, resource policies, private endpoints and canary deployments. - HTTP APIs have fewer features but are cheaper and simpler, with native JWT authorizers for Cognito or any OIDC provider. A good default for plain Lambda or HTTP proxies. - WebSocket APIs keep persistent two-way connections for chat, notifications or live dashboards. Routes such as $connect and $disconnect invoke your backend, which pushes messages back through a connection callback URL. Authorization options include IAM, Lambda authorizers and Cognito. Two limits to know: REST API integrations time out after 29 seconds by default (it can be raised for Regional and private APIs), and payloads are capped at 10 MB, so large files go straight to S3 with presigned URLs.

Question 39

Explain Lambda concurrency: the account quota, reserved concurrency and provisioned concurrency.

Accepted Answer

Concurrency is the number of requests a function handles at the same moment, roughly requests per second times average duration. Each concurrent request needs its own execution environment. - Account quota: by default 1,000 concurrent executions per Region, shared by all functions and raisable. Beyond it, synchronous calls are throttled with a 429 error, while asynchronous and event source invocations are retried. Lambda also limits how fast each function can scale out. - Reserved concurrency sets aside a fixed amount for one function. It's both a guarantee (others can't starve it) and a cap (it can't go higher), which is handy to protect a downstream database. Setting it to 0 stops all invocations. No extra charge. - Provisioned concurrency keeps environments pre-initialized on a version or alias, removing cold starts for that capacity; beyond it the function scales on demand. It costs extra and can be scheduled or auto scaled. For SQS event sources, the event source mapping's maximum concurrency setting is a gentler way to cap consumers than reserved concurrency.

Question 40

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

Accepted Answer

VPC endpoints let resources in private subnets reach AWS services without an internet gateway or NAT gateway, keeping traffic on the AWS network.

Gateway endpoints exist only for S3 and DynamoDB. They're a target in your route tables, cost nothing, and are controlled with endpoint policies. They only serve traffic from inside the VPC, not from on-premises networks.
Interface endpoints are powered by AWS PrivateLink: a network interface with a private IP in each subnet you choose, protected by security groups. They exist for most AWS services, work from peered and on-premises networks, and with private DNS the normal service hostname resolves to those private IPs. They're billed per hour per AZ plus per GB.

PrivateLink also exposes your own service: put it behind an NLB, create an endpoint service, and consumers in other VPCs or accounts create interface endpoints to it. Only that service is shared, overlapping CIDRs don't matter, and no peering is needed.

Endpoints also cut NAT data processing costs, and bucket policies can require a specific endpoint with aws:SourceVpce.

Question 41

How does AWS KMS work, and what is envelope encryption?

Accepted Answer

KMS manages encryption keys in hardware security modules, and a KMS key's material never leaves KMS unencrypted. Every key has a key policy; IAM policies and grants add to it, and every use is logged in CloudTrail. Keys are AWS owned (used inside services), AWS managed (created per service in your account, like aws/s3), or customer managed, where you control the policy, rotation and deletion. Encrypt only accepts small payloads (up to 4 KB), and sending all your data to KMS would be slow anyway. So services use envelope encryption: - GenerateDataKey returns a plaintext data key plus the same key encrypted under your KMS key. - Encrypt the data locally with the plaintext key, then discard it from memory. - Store the encrypted data key next to the ciphertext. - To decrypt, send the encrypted data key to KMS Decrypt and decrypt the data locally. S3, EBS and RDS encryption work this way. You get speed, no size limit, and access to the data hinges on permission to decrypt one small key.

Question 42

The AWS bill has grown much faster than traffic. How would you approach cost optimization?

Accepted Answer

Visibility first, then the biggest levers.

Visibility: Cost Explorer grouped by service, account and cost allocation tags; AWS Budgets with alerts; Cost Anomaly Detection. Each team should own its spend.
Right-size: use Compute Optimizer and CloudWatch utilization to shrink over-provisioned instances, databases and containers, and consider Graviton instances for better price-performance.
Stop paying for idle: schedule non-production environments off at night; delete unattached EBS volumes, old snapshots, idle load balancers and unused public IPs.
Pricing models: Savings Plans or Reserved Instances for the steady baseline, Spot for fault-tolerant work.
Storage: S3 lifecycle rules and Intelligent-Tiering, gp2 to gp3 migrations, sensible CloudWatch Logs retention.
Data transfer: NAT gateway processing and cross-AZ traffic often hide surprises. Use VPC endpoints for S3 and DynamoDB and CloudFront to reduce egress.
Architecture: serverless or managed services for spiky workloads, caching to shrink databases.

Trusted Advisor gives quick wins. Then make it continuous with tagging policies, per-team budgets and regular reviews.

Question 43

Design a serverless backend where users upload images that are resized and then served through an API.

Accepted Answer

- Upload: the client calls an API (API Gateway HTTP API with a Cognito JWT authorizer) to get a presigned S3 PUT URL, then uploads straight to an uploads bucket. No file bytes pass through API Gateway or Lambda. - Trigger: an S3 event notification goes to an SQS queue, and a Lambda function consumes it in batches. The queue absorbs bursts and retries failures, and a DLQ catches poison messages. - Processing: Lambda, with enough memory for the image library, writes the resized variants to a separate processed bucket (never the source bucket, which would trigger itself in a loop) and records metadata and status in DynamoDB. - Serving: CloudFront with origin access control in front of the processed bucket; the API reads metadata from DynamoDB. - Operations: idempotent processing keyed by object key and version, alarms on DLQ depth and errors, a least-privilege role per function, and everything defined in SAM or CDK. If the pipeline grows into several steps, like moderation and notifications, I'd orchestrate them with Step Functions. The design scales to zero when idle.

Question 44

Compare DynamoDB on-demand and provisioned capacity modes.

Accepted Answer

- On-demand: no capacity planning. DynamoDB scales automatically and you pay per read and write request. AWS now describes it as the default and recommended mode for most workloads. Ideal for new tables, unpredictable or spiky traffic, and tables that are often idle. You can set a maximum throughput per table to cap spend. - Provisioned: you set read and write capacity units per second and pay for them hourly whether or not you use them. Add auto scaling (target tracking on utilization) and, for steady long-term workloads, reserved capacity for a lower price. Best when traffic is predictable and you want tight cost control. Capacity units: one RCU is one strongly consistent read per second of an item up to 4 KB, or two eventually consistent reads; one WCU is one write per second of up to 1 KB. Transactional requests consume twice as much. Either mode can still throttle if traffic concentrates on one partition key, because each partition has its own throughput ceiling. Switching modes is allowed only a limited number of times.

Question 45

What is a hot partition in DynamoDB, and how do you fix one?

Accepted Answer

DynamoDB spreads items across partitions by hashing the partition key, and each partition has a ceiling of 3,000 read units and 1,000 write units per second. A hot partition appears when a disproportionate share of traffic hits one key or a few: a celebrity's profile, today's date as the key, a global counter, a status attribute. You get throttled while the table has spare capacity.

DynamoDB helps: burst capacity absorbs short spikes, and adaptive capacity shifts throughput to busy partitions and can split partitions that stay hot. But a single hot item can never exceed the per-partition limit.

Fixes:

Choose a higher-cardinality key, like userId instead of country.
Write sharding: add a suffix, such as 2024-05-01#7 out of 10 shards, to spread writes, and query all shards in parallel when reading.
Cache hot reads with DAX or ElastiCache.
Aggregate counters instead of updating one item per event.
Check GSIs: a low-cardinality GSI key can be hot even when the table isn't.

CloudWatch Contributor Insights shows the most accessed keys.

Question 46

When would you use ElastiCache, and which caching strategies would you apply?

Accepted Answer

ElastiCache is a managed in-memory data store for sub-millisecond reads. Use it to offload repeated database queries, store sessions, build leaderboards with sorted sets, rate limit, or do pub/sub. It supports Valkey, Redis OSS and Memcached, either as a serverless cache or as node-based clusters.

Valkey or Redis OSS: rich data structures, replicas with automatic failover across AZs, cluster mode for sharding, persistence options. The usual choice.
Memcached: a simple multi-threaded key-value cache without replication or persistence, fine for purely disposable data.

Strategies:

Cache-aside (lazy loading): read the cache; on a miss, read the database and populate the cache. Only requested data is cached, but misses are slow and data can go stale.
Write-through: update the cache on every database write. Fresher data, but you also cache things nobody reads.
TTLs on keys to bound staleness, with some jitter so many keys don't expire together.

Also plan invalidation on writes, protection against a stampede when a hot key expires, and the eviction policy for when memory fills up.

Question 47

What is AWS Step Functions, and when would you choose Standard or Express workflows?

Accepted Answer

Step Functions orchestrates workflows as state machines written in Amazon States Language. States include Task (call Lambda or an AWS service API directly), Choice, Parallel, Map, Wait, Succeed and Fail, and each state can declare Retry and Catch, so error handling lives in the workflow instead of your code. The .sync pattern waits for a job such as an ECS task to finish, and .waitForTaskToken pauses until a person or external system calls back. - Standard workflows run up to one year with exactly-once execution and a full, inspectable execution history, priced per state transition. Use them for long-running, auditable or non-idempotent processes like order fulfilment or payments. - Express workflows run up to five minutes and are priced by executions, duration and memory, for high-volume event processing. Asynchronous Express is at-least-once and synchronous Express at-most-once, so steps should be idempotent, and they don't support .sync or callbacks. I reach for Step Functions when a Lambda starts calling other Lambdas and managing its own retries.

Question 48

What are the 7 Rs of migrating workloads to AWS?

Accepted Answer

AWS describes seven migration strategies, chosen per application after a portfolio assessment:

Retire: decommission applications nobody needs.
Retain: keep them where they are for now, because of compliance, dependencies, a recent upgrade or low value.
Rehost ("lift and shift"): move servers as they are, often automated with AWS Application Migration Service.
Relocate: move at the platform level without changing the application, for example a VMware estate to a VMware-based platform on AWS, or resources to another VPC, Region or account.
Repurchase ("drop and shop"): replace the application with a SaaS product or a newer version.
Replatform ("lift, tinker and shift"): targeted optimizations such as a self-managed database moving to RDS or an app moving into containers, without changing the core architecture.
Refactor or re-architect: redesign with cloud-native services such as serverless or microservices; the most effort and the most benefit.

For large migrations AWS generally recommends rehost, replatform and relocate to move quickly, then modernizing once in the cloud. AWS DMS handles database migrations and DataSync moves file data.

Question 49

How do different event sources invoke Lambda, and how does error handling differ between them?

Accepted Answer

There are three invocation models: - Synchronous: the caller waits for the result, as with API Gateway, an ALB or an SDK Invoke. Lambda doesn't retry; the caller sees the error and decides. - Asynchronous: Lambda queues the event and acknowledges immediately, as with S3 notifications, SNS and EventBridge. On failure Lambda retries twice by default, and you can send failed events to an on-failure destination or a DLQ. - Event source mappings: Lambda polls SQS, Kinesis, DynamoDB Streams, Kafka or Amazon MQ and invokes your function with batches. With polling sources, errors affect the whole batch. For SQS, failed messages reappear after the visibility timeout and eventually land in the queue's DLQ. For Kinesis and DynamoDB Streams, a failing batch blocks its shard until it succeeds or the records expire, so configure maximum retries, maximum record age, bisect batch on error and an on-failure destination. For SQS and streams, enable partial batch responses so only failed items are retried, and make handlers idempotent.

Question 50

What is an AMI, and what is EC2 user data used for?

Accepted Answer

An AMI (Amazon Machine Image) is the template an instance boots from: snapshots of the root volume and any other volumes, plus metadata like the architecture and block device mapping. AMIs are Regional; you can copy them to other Regions and share them with other accounts. You can start from AWS images like Amazon Linux, Marketplace images, or your own golden AMIs built with EC2 Image Builder or Packer. User data is a script or cloud-init configuration passed at launch. By default it runs once, as root, on the instance's first boot, and is typically used to install packages, fetch configuration or register the instance somewhere. It's limited to 16 KB and readable through the instance metadata service, so never put secrets in it. The trade-off: baking software into the AMI gives fast, consistent boots, which matters for Auto Scaling; heavy user data keeps images generic but slows every launch and can fail at boot. A common middle ground is a golden AMI with the OS and dependencies plus a short user data script for environment-specific settings.

AWS interview questions & answers

Top 59 AWS interview questions most asked first