AWS Interview Questions

AWS (Amazon Web Services) is a cloud platform offering on-demand compute, storage, networking, databases, and other services on a pay-as-you-go basis. Cloud services fall into three models: IaaS (Infrastructure as a Service) gives you raw building blocks like virtual machines and networking — EC2 is an example; PaaS (Platform as a Service) manages the underlying infrastructure so you just deploy code — Elastic Beanstalk is an example; SaaS (Software as a Service) delivers a finished application over the internet, like Gmail.

A region is a separate geographic area, such as us-east-1 or ap-south-1, that contains multiple isolated data centres. An availability zone (AZ) is one or more discrete data centres within a region, each with independent power, cooling and networking. Deploying across multiple AZs gives you high availability within a region; using multiple regions adds disaster recovery and lower latency for global users.

An edge location is a small site used for caching and terminating connections close to users — it runs CloudFront, Route 53 and AWS Global Accelerator, not your EC2 instances. Availability zones run your workloads; edge locations only shorten the path to them. There are far more edge locations than AZs, which is the point.

It splits security duties between AWS and you. AWS is responsible for security "of" the cloud — physical hardware, the hypervisor, networking and managed-service infrastructure. You are responsible for security "in" the cloud — your data, IAM configuration, OS patching on EC2, encryption choices and firewall rules. The line moves by service: with S3 you patch nothing, with EC2 you patch the guest OS.

Compute time, storage volume, data transfer and request counts, with the exact mix depending on the service. The one that surprises people is data transfer: inbound is generally free, transfer out to the internet is billed, and cross-AZ traffic inside your own VPC is billed too. A large share of unexpected AWS bills is inter-AZ chatter between services that could have been co-located.

Vertical scaling means moving to a larger instance type — more CPU and memory on one machine, which usually requires a restart and has a hard ceiling. Horizontal scaling means adding more instances behind a load balancer, which has no practical ceiling and tolerates the loss of any one node. AWS is built around horizontal scaling; Auto Scaling groups and load balancers exist to make it the default.

High availability means the system keeps serving through common failures, usually via redundancy across AZs — you may see a brief blip. Fault tolerance means no interruption at all, which costs more because it needs full duplicate capacity. Disaster recovery is the plan for recovering after a large failure, measured by RTO (how long until you are back) and RPO (how much data you can afford to lose). Interviewers ask this to see whether you cost-justify redundancy or just add it.

Four, in ascending cost and descending recovery time: backup and restore (cheapest, hours), pilot light (core data replicated, minimal compute idle), warm standby (a scaled-down but running copy), and multi-site active-active (full capacity in two regions, near-zero RTO). Pick by RTO and RPO, not by preference — most workloads do not justify active-active.

An AWS account is the billing and isolation boundary — resources in one account cannot see another by default. AWS Organizations groups multiple accounts under one payer, with consolidated billing and Service Control Policies that cap what member accounts may do. The modern pattern is many small accounts (prod, staging, sandbox per team) under one organisation, rather than one account with everything in it.

An SCP is an Organizations-level guardrail that sets the maximum permissions available in a member account. It never grants anything — it only bounds what IAM policies inside that account can grant. So an action is allowed only if both the SCP permits it and an IAM policy grants it, which is why a user with AdministratorAccess can still be denied by an SCP.

The CLI issues imperative API calls from a shell, an SDK does the same from application code, and CloudFormation declares desired state that AWS reconciles for you. The first two describe steps; the third describes an outcome and can detect drift and roll back. Production infrastructure belongs in the declarative form, with the CLI kept for inspection and one-off operations.

When the managed service cannot meet a hard requirement — a database version AWS does not offer, a compliance rule that forbids a shared control plane, or a cost curve that breaks at your scale. Otherwise self-managing is usually a false economy, because the licence you save is dwarfed by the patching, backups and on-call you take on. Saying this plainly reads better than claiming managed services are always right.

EC2 (Elastic Compute Cloud) provides resizable virtual servers, called instances, in the cloud. You choose an AMI (machine image), an instance type that sets CPU and memory, a VPC subnet and a security group, and you pay only for what you use. It is the service most other AWS compute options are defined against.

On-Demand charges by the second with no commitment — right for unpredictable or short-lived work. Reserved Instances and Savings Plans trade a one- or three-year commitment for a substantial discount on steady baseline load. Spot Instances use spare capacity at a deep discount but can be reclaimed with two minutes of warning, so they suit batch jobs, CI runners and anything checkpointed. Dedicated Hosts exist for licensing and compliance cases that need physical isolation.

AWS sends an interruption notice through instance metadata and EventBridge roughly two minutes before taking the capacity back. You design for it by keeping no state on the instance, draining it from the load balancer on the notice, checkpointing long jobs, and spreading the request across several instance types and AZs so one capacity pool going tight does not take out the whole fleet.

An Amazon Machine Image is the template an instance boots from — the OS, pre-installed software and configuration, plus the block device mapping. Baking your dependencies into a custom AMI shortens boot time and makes scaling events predictable, which matters when Auto Scaling needs capacity in a hurry. The alternative, installing everything at boot through user data, is simpler but slower and more fragile.

Broadly: general purpose (T and M) for balanced workloads, compute optimised (C) for CPU-bound work, memory optimised (R and X) for caches and in-memory databases, storage optimised (I and D) for high local IOPS, and accelerated (P, G, Inf) for GPU and ML. Choose by the resource that actually saturates first — the common mistake is buying more of everything when only memory was tight.

T instances provide a modest baseline CPU allocation and accrue credits while running below it, spending those credits to burst above it. When credits run out the instance is throttled to baseline, which produces the classic "it was fine for a week then went slow" incident. Unlimited mode lets it keep bursting for an extra charge, which is often cheaper than moving up a family for a spiky workload.

An Auto Scaling group keeps the number of instances between a minimum and maximum, replacing any that fail health checks. Scaling is driven by target tracking (hold average CPU at 50%), step scaling (add two instances when a threshold is breached), scheduled actions for known peaks, or predictive scaling from historical patterns. Target tracking is the sane default; step scaling is for when you need explicit control of the increments.

Both describe how to launch instances for an Auto Scaling group, but launch configurations are immutable, untyped and effectively legacy. Launch templates support versioning, mixed instance types and purchase options in one group, and newer EC2 features. New work should use launch templates; the question is really asking whether you have touched an Auto Scaling group recently.

The Application Load Balancer operates at Layer 7 and routes HTTP and HTTPS by host, path, header or query string. The Network Load Balancer operates at Layer 4 for very high-throughput TCP and UDP, preserves the source IP and supports static IPs. The Gateway Load Balancer fronts third-party virtual appliances such as firewalls. The Classic Load Balancer is legacy and should not be chosen for new work.

ECS is AWS's own container orchestrator — simpler, tightly integrated, no control plane to learn. EKS is managed Kubernetes, which you pick when you want the Kubernetes ecosystem or portability across clouds. Fargate is not an orchestrator at all: it is a launch type that runs ECS or EKS tasks without you managing EC2 capacity. So the real choice is ECS versus EKS, then EC2 versus Fargate for who owns the nodes.

When the workload runs continuously enough that per-request pricing loses, when it needs more than Lambda's execution ceiling or a specialised kernel, when it depends on GPU or licensed software tied to a host, or when a lift-and-shift has to happen before a rewrite. Saying "EC2 because we always have" fails this question; naming the constraint passes it.

S3 (Simple Storage Service) is object storage organised into buckets, designed for 99.999999999% (eleven nines) durability. Storage classes trade cost against retrieval: Standard for frequent access, Standard-IA and One Zone-IA for infrequent access, Intelligent-Tiering to move objects automatically, and Glacier Instant, Flexible and Deep Archive for archival with increasing retrieval delay and decreasing cost.

EBS is block storage attached to one EC2 instance at a time, like a virtual disk — right for boot volumes and databases. S3 is object storage reached over an HTTP API, right for files, backups, logs and static assets, but it is not a filesystem. EFS is a managed NFS filesystem many instances can mount simultaneously, right when several servers genuinely need shared POSIX access.

S3 provides strong read-after-write consistency for PUTs of new objects, overwrites and deletes, across all regions. Historically overwrites and deletes were eventually consistent, and a lot of older material and interview answers still describe that behaviour. Knowing it changed is a small signal that you have read recent documentation rather than a 2018 tutorial.

Block Public Access at the account and bucket level unless you have a specific reason not to, grant access through IAM roles and bucket policies rather than ACLs, enable default encryption, turn on versioning so a bad delete is recoverable, and log access with CloudTrail data events or server access logging. Most public S3 incidents trace to a bucket policy written broadly during debugging and never narrowed.

All three encrypt objects at rest; they differ in who holds the key. SSE-S3 uses keys AWS manages entirely. SSE-KMS uses a KMS key you control, which gives you an audit trail and the ability to revoke access, at the cost of KMS request charges and throttling at very high request rates. SSE-C means you supply the key on every request and AWS stores none of it — powerful and easy to lose data with.

Versioning keeps every version of an object under the same key. With it enabled, a delete does not remove data — it writes a delete marker that hides the object, and the prior versions remain billable until a lifecycle rule or an explicit versioned delete removes them. This is why "we deleted it but the bill did not move" is a common finding.

Rules that transition objects between storage classes or expire them after a set age, scoped by prefix or tag. A typical policy moves logs to Standard-IA after 30 days, to Glacier after 90, and deletes them after a year. Lifecycle rules should also expire incomplete multipart uploads, which otherwise accumulate invisibly and are billed.

A presigned URL grants time-limited access to a specific S3 object using the signing credentials of whoever generated it, without making the object public. The standard use is letting a browser upload directly to S3 or download a private file, so large payloads never pass through your application servers. The expiry should be short, because anyone holding the URL has the access.

gp2 ties IOPS to volume size; gp3 decouples them, so you buy throughput and IOPS independently and it is usually cheaper for the same performance. io1 and io2 are provisioned IOPS for latency-sensitive databases, with io2 offering higher durability. st1 and sc1 are throughput-optimised HDDs for large sequential reads such as log processing, and are poor at random access.

It routes uploads to the nearest CloudFront edge location and carries them to the bucket over the AWS backbone rather than the public internet. It helps when clients are geographically far from the bucket region and the objects are large; it does nothing for clients already close to the region. AWS publishes a speed comparison tool, and the honest answer in an interview is that you measure before enabling it.

Multipart upload: split the object into parts, upload them in parallel, and retry only the parts that fail. It is required past a certain object size and is a good idea well before that, because a single failed byte on a long transfer otherwise restarts everything. Pair it with a lifecycle rule that aborts incomplete multipart uploads, or you will pay for parts nobody ever assembled.

Lambda runs your code in response to events — an API call, an S3 upload, a queue message, a schedule — without you provisioning servers. You are billed for the duration and memory your function actually consumes, and scaling is handled for you. "Serverless" does not mean no servers; it means the capacity, patching and scaling are somebody else's problem.

A function can run for up to 900 seconds — 15 minutes — in a single invocation. Functions using Lambda Managed Instances, when invoked asynchronously or through an event source mapping other than Amazon MQ and DocumentDB, can go to 5,400 seconds (90 minutes). Anything longer belongs in Step Functions, Fargate or Batch rather than in a function you keep trying to make faster.

Between 128 MB and 10,240 MB, in 1 MB increments. CPU is allocated in proportion to memory, and at 1,769 MB a function has the equivalent of one full vCPU. This is the most useful tuning fact about Lambda: a CPU-bound function given more memory often finishes fast enough that the invocation gets cheaper, not dearer, despite the higher per-millisecond rate.

A cold start is the extra latency when Lambda has to create a new execution environment — download the code, start the runtime, run the initialisation outside your handler — before running your function. You reduce it by keeping the deployment package small, moving SDK clients and connection setup into the init phase so they are reused, choosing a lighter runtime, and using Provisioned Concurrency for latency-sensitive paths. Attaching a function to a VPC used to dominate cold starts; that has been largely addressed.

Reserved concurrency caps how many simultaneous executions a function may have, which both guarantees it that capacity and protects the rest of the account from it. Provisioned concurrency pre-initialises a number of execution environments so they are warm and respond without a cold start. Reserved controls the ceiling; provisioned controls the latency. They solve different problems and are often confused.

One thousand concurrent executions per Region by default, and it can be raised to tens of thousands on request. Each function also scales at up to 1,000 new execution environments every 10 seconds. New accounts start with reduced quotas that AWS raises automatically as usage grows, which catches people out when they load-test on a fresh account.

Six MB each for request and response on synchronous invocations, 1 MB for asynchronous ones, and 200 MB for a streamed response. The standard workaround for larger data is to put the payload in S3 and pass the object key — the claim-check pattern. Trying to raise the limit is not an option; it is a hard quota.

A .zip archive is limited to 50 MB when uploaded directly and 250 MB unzipped including layers and custom runtimes; larger zips must come via S3. A container image can be up to 10 GB uncompressed, which is the usual answer when a function needs heavy native dependencies or an ML model. A function may also attach at most five layers.

A layer is a package of libraries or a custom runtime that several functions share, mounted into /opt at runtime. It keeps common dependencies out of every function's own archive and lets you version them centrally. Layers are less compelling now that container images exist, and they count against the 250 MB unzipped limit, so they are not a way around it.

It depends on the invocation type. Synchronous invocations return the error to the caller and retry nothing — the caller decides. Asynchronous invocations are retried twice by Lambda with delays, then sent to a dead-letter queue or an on-failure destination if configured. Event source mappings for streams retry until the record expires or the batch succeeds, which can block the shard, so you set a maximum retry age and a failure destination.

It matters because every invocation model above will, under failure, deliver the same event more than once — at-least-once is the guarantee, not exactly-once. You make it idempotent by deriving a deterministic key from the event (message ID, order ID, S3 object version), recording that key in DynamoDB with a conditional write before doing the work, and short-circuiting if it is already present. Writing "we assume each message arrives once" is the answer that loses the offer.

Use RDS Proxy, which pools and multiplexes connections so a burst of concurrent functions does not open a connection each and exhaust the database. Failing that, cap the function with reserved concurrency so the database can survive the worst case. The underlying mismatch is that Lambda scales horizontally far faster than a relational database accepts connections, which is why serverless plus RDS needs deliberate design.

All environment variables for a function together are limited to 4 KB, and they are visible to anyone who can read the function configuration. Secrets belong in Secrets Manager or SSM Parameter Store, fetched at init and cached in the execution environment, so rotation does not require a redeploy and the value never sits in plaintext configuration. Storing a database password in an environment variable is common and is still the wrong answer.

A VPC (Virtual Private Cloud) is a logically isolated network inside AWS where you control the IP range, subnets, route tables and gateways. The usual layout splits it into public subnets that route to an internet gateway and private subnets that reach the internet through a NAT gateway but cannot be reached from it. It is the foundation nearly every other AWS architecture sits on.

Its route table. A subnet is public if its route table sends 0.0.0.0/0 to an internet gateway; it is private if it does not. Nothing about the subnet itself is marked public — which is why "I put it in the public subnet and it still cannot reach the internet" usually turns out to be a missing route or a missing public IP.

A security group is stateful and attaches to an instance or ENI: return traffic is allowed automatically and only allow rules exist. A network ACL is stateless and applies to a whole subnet: inbound and outbound are evaluated separately, and it supports deny rules. Security groups are the primary control; NACLs are a coarse subnet-wide backstop, most often used to block a specific address range.

An internet gateway is a two-way door for resources that have public IPs, attached to the VPC. A NAT gateway sits in a public subnet and lets private-subnet resources make outbound connections while refusing inbound ones. NAT gateways are charged per hour and per GB processed, and they are a frequent surprise on the bill for chatty private workloads.

A VPC endpoint lets resources in a private subnet reach AWS services without traversing the internet or a NAT gateway. Gateway endpoints cover S3 and DynamoDB and are free; interface endpoints (PrivateLink) create an ENI in your subnet for most other services and are charged hourly plus per GB. For a workload pulling heavily from S3, a gateway endpoint often pays for itself immediately in avoided NAT charges.

VPC peering creates a direct one-to-one link, is cheap, and does not route transitively — so a mesh of N VPCs needs N(N-1)/2 peerings. Transit Gateway acts as a hub that every VPC attaches to once, which scales and supports transitive routing at a higher cost. PrivateLink is the third option when you only want to expose one service rather than join two networks.

CIDR notation writes an IP range as an address plus a prefix length — 10.0.0.0/16 gives roughly 65,536 addresses. Size generously, because a VPC CIDR cannot be shrunk and overlapping ranges block future peering. Note that AWS reserves five addresses in every subnet, so a /28 gives you eleven usable hosts, not sixteen.

Route 53 is AWS's DNS and domain registration service. Beyond name resolution it supports routing policies — simple, weighted, latency-based, failover, geolocation and multivalue — and pairs them with health checks so DNS can steer traffic away from an unhealthy region. It is the usual mechanism for active-passive failover between regions.

CloudFront is AWS's CDN: it caches content at edge locations near users, terminates TLS there, and fetches from an origin such as an S3 bucket or a load balancer on a miss. Beyond latency it reduces origin load and cost, and it integrates with AWS WAF and Shield so filtering happens before traffic reaches your infrastructure.

A Site-to-Site VPN runs an encrypted tunnel over the public internet — quick to set up, cheap, and subject to internet variability. Direct Connect is a dedicated physical circuit into an AWS location, giving consistent latency and higher throughput at the cost of lead time and a contract. The common production answer is Direct Connect with a VPN configured as the backup path.

IAM controls who can do what in your AWS account. Users are long-lived identities with their own credentials; groups collect users to attach policies once; roles are temporary identities that a user, service or EC2 instance assumes and that issue short-lived credentials; policies are JSON documents granting or denying specific actions on specific resources. The working rule is least privilege, delivered through roles rather than embedded access keys.

A role delivers temporary credentials through the instance metadata service and rotates them automatically, so nothing long-lived is stored on disk or in an environment variable. Access keys, by contrast, get committed to repositories, copied into laptops and shared. Almost every published AWS credential leak involves a static key that a role would have made unnecessary.

An explicit deny anywhere wins outright. Otherwise the request must be allowed by an applicable policy and not blocked by any boundary — an SCP, a permissions boundary, or a resource policy that fails to grant access to a principal in another account. Default is deny, so anything not explicitly allowed is refused. Candidates who lead with "explicit deny always wins" are signalling they have actually debugged an IAM failure.

An identity-based policy attaches to a user, group or role and says what that principal may do. A resource-based policy attaches to the resource — an S3 bucket, an SQS queue, a KMS key — and names which principals may act on it. Cross-account access usually needs both sides to agree, which is why granting a role permission is not enough if the bucket policy does not mention it.

A permissions boundary is a policy that sets the maximum permissions an IAM entity can have, without granting anything itself. Its main use is safe delegation: you let a team create their own roles while guaranteeing those roles can never exceed the boundary you set. It is the account-level analogue of what an SCP does at the organisation level.

KMS manages encryption keys and performs cryptographic operations without exposing key material. Envelope encryption is the pattern it uses: a data key encrypts your data, KMS encrypts that data key with a master key, and the encrypted data key is stored beside the ciphertext. This means large objects never travel to KMS — only the small data key does.

Both store configuration securely and integrate with IAM and KMS. Parameter Store is free for standard parameters and fine for configuration values and secrets you rotate manually. Secrets Manager costs per secret per month and adds built-in rotation, including managed rotation for RDS credentials. If you need automatic rotation, pay for Secrets Manager; if you do not, Parameter Store is usually enough.

CloudTrail records API calls made in your account — who called what, from where, and when. Management events are on by default; data events such as individual S3 object reads must be enabled and are billed separately. It is the first place to look after a security incident, and the reason to send trails to a separate, locked-down account.

Security groups filter by IP, port and protocol at the instance level — Layer 3 and 4. WAF inspects HTTP requests at Layer 7 and blocks patterns like SQL injection or a single IP flooding a login endpoint. Shield is DDoS protection, with Standard on by default and Advanced adding response-team support and cost protection. They stack rather than substitute.

Create a role they assume cross-account rather than issuing IAM users or keys, scope it to the minimum actions and resources, and require an external ID so the role cannot be used by a confused deputy — a third party tricked into using their own credentials on someone else's behalf. Add a condition on their account ID, log the assumptions in CloudTrail, and set an expiry review. The external ID is the part most candidates miss.

RDS is managed relational database hosting for engines like MySQL, PostgreSQL, MariaDB, Oracle and SQL Server — right when you need joins, transactions across tables and ad-hoc queries. DynamoDB is a managed NoSQL key-value and document store giving single-digit millisecond reads at effectively any scale, right when the access patterns are known in advance and throughput matters more than query flexibility.

Multi-AZ maintains a synchronous standby in another AZ purely for availability — you cannot read from it, and failover is automatic. A read replica is asynchronous, can be read from, and exists to spread read load or to serve another region. They solve availability and scale respectively, and production systems that need both run both.

Aurora is AWS's own MySQL- and PostgreSQL-compatible engine with a distributed storage layer that replicates six ways across three AZs and grows automatically. Compared with standard RDS it offers faster failover, up to fifteen low-latency read replicas that share the same storage, and backups that do not affect performance. You give up some version flexibility and pay more per hour.

Pick an attribute with high cardinality and even access, because DynamoDB spreads data and throughput by partition key hash. A key like status or country creates hot partitions that throttle while the table is nominally under-provisioned. If a natural key is skewed, add a random or calculated suffix to spread writes, and remember you then have to query every shard on read.

A local secondary index shares the partition key and gives an alternative sort key; it must be created with the table and shares its throughput. A global secondary index can use an entirely different partition and sort key, can be added later, and has its own throughput. GSIs are eventually consistent; LSIs can be read strongly consistent.

Provisioned capacity means you specify read and write units and pay for them whether used or not, optionally with auto scaling — cheaper for steady, predictable load. On-demand charges per request with no capacity planning and absorbs spikes instantly, which suits unpredictable or new workloads. The usual pattern is to start on-demand, measure, then switch to provisioned once the shape is known.

ElastiCache is managed in-memory caching in front of a slower data store. Redis supports data structures, persistence, replication, pub/sub and transactions; Memcached is a simpler multi-threaded key-value cache that scales out horizontally. Choose Redis for almost everything unless you specifically want the simplicity and raw multi-threaded throughput of Memcached.

Redshift is a columnar data warehouse built for analytical queries scanning large volumes — aggregations over billions of rows. RDS is row-oriented and built for transactional work: many small reads and writes with low latency. Running analytics on your production RDS instance is the mistake this question is checking for.

A stream is an ordered, time-limited log of item-level changes to a table, which Lambda or Kinesis can consume. It backs change-data-capture patterns: maintaining an aggregate table, pushing updates to OpenSearch, triggering notifications, or implementing the outbox pattern so a write and its side effect cannot diverge. It is the standard answer to "how do you react to a DynamoDB write".

Infrastructure as code means defining your resources in version-controlled files that a tool applies, rather than clicking through a console. It gives you review, history, repeatable environments and a way to rebuild after a disaster. The practical test is whether you could recreate production in a new account from the repository alone — if not, the infrastructure is not really in code.

CloudFormation is AWS's native IaC service: you declare resources in a YAML or JSON template and it creates, updates or deletes them as a stack, rolling back on failure. Change sets let you preview what an update will do before applying it, and drift detection reports resources that were modified outside the template. Its weakness is verbosity, which is what CDK exists to solve.

The Cloud Development Kit lets you define infrastructure in TypeScript, Python, Java or Go and synthesises it to a CloudFormation template, so CloudFormation still does the deploying. The gain is real language features — loops, conditionals, classes, unit tests — and higher-level constructs that expand into many resources with sensible defaults. The cost is that a small amount of code can generate a large amount of infrastructure, so reviewing the synthesised template matters.

When you manage more than one cloud or a significant amount of non-AWS infrastructure, when you want a single state and plan workflow across providers, or when your team already knows HCL. CloudFormation and CDK win on same-day support for new AWS features and on not having to manage remote state. This question is usually testing whether you can justify a tool choice rather than defend a favourite.

Drift detection compares the live configuration of stack resources with what the template declares and reports differences. Drift happens when somebody fixes an incident through the console and never puts the change back into the template — after which the next stack update may silently revert the fix. Detecting drift routinely is what keeps IaC honest.

CodeCommit is managed Git hosting, CodeBuild compiles and tests, CodeDeploy pushes artefacts to EC2, Lambda or ECS, and CodePipeline orchestrates the stages into a pipeline. They are a complete native CI/CD chain, though many teams keep GitHub Actions or GitLab for build and use only CodeDeploy and CodePipeline for the AWS-side deployment.

Blue/green stands up a complete second environment, shifts all traffic at once, and keeps the old one ready for an instant rollback. Canary routes a small percentage to the new version, watches metrics, and increases the share only if the alarms stay quiet. Blue/green optimises for fast rollback; canary optimises for limiting blast radius. CodeDeploy supports both, and for Lambda aliases the canary shift is a configuration setting.

Systems Manager covers fleet operations: Session Manager gives shell access to instances without SSH keys or open port 22, Patch Manager schedules OS patching, Run Command executes scripts across a fleet, and Parameter Store holds configuration. Session Manager is the most interview-relevant piece, because it lets you close inbound SSH entirely and still get a shell, with the session logged in CloudTrail.

ECR is a managed container registry with IAM-based access, image scanning for known vulnerabilities and lifecycle policies to expire old tags. A typical pipeline builds in CodeBuild or GitHub Actions, pushes an immutable tag to ECR, and updates an ECS service or EKS deployment to that tag. Using immutable tags rather than reusing "latest" is what makes rollbacks meaningful.

Give the pipeline an IAM role and have it fetch secrets from Secrets Manager or Parameter Store at run time, rather than storing them as pipeline variables. Use OIDC federation so an external CI system such as GitHub Actions assumes a role with short-lived credentials instead of holding a static access key. Scope the role per pipeline and per environment, and never let a pull-request build from a fork assume the production role.

Separate accounts per environment and often per team, under one organisation, with SCPs setting guardrails and a shared services account for CI, logging and container registries. The reason is blast radius and quota isolation: a runaway job in staging cannot exhaust production concurrency or delete production data, and billing is attributable without tag discipline nobody maintains. Control Tower automates most of the setup.

CloudWatch collects metrics, logs and events across AWS services and your own applications. Alarms fire on thresholds or anomaly detection and can notify through SNS or trigger an action such as an Auto Scaling adjustment. Note that some metrics — memory and disk usage on EC2 — are not collected by default and need the CloudWatch agent, which catches people out.

CloudWatch tells you how things are performing, CloudTrail tells you who called which API, and Config tells you what the configuration was at a point in time and whether it complies with rules. Debugging a latency spike is CloudWatch; investigating who deleted the bucket is CloudTrail; proving every volume was encrypted last quarter is Config. Interviewers ask this because the three are routinely conflated.

X-Ray traces a request across services, producing a service map and per-segment timings so you can see which hop consumed the latency. It is the answer to "the API is slow but every individual service looks healthy", which metrics alone cannot resolve in a distributed system. It needs instrumentation in the application, not just a setting.

Operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. The framework matters less as a list to recite than as a way to structure a design answer — naming the trade-off you are making between two pillars, usually cost against reliability, is what the question is really probing.

Start with Cost Explorer grouped by service and then by usage type, because the headline service is rarely the whole story. The recurring culprits are idle or oversized EC2 and RDS instances, unattached EBS volumes and old snapshots, NAT gateway data processing, cross-AZ traffic, and S3 storage in the wrong class with no lifecycle rule. Then commit to Savings Plans for the baseline you have proven is steady.

Reserved Instances commit to a specific instance family in a region and discount that. Savings Plans commit to an hourly spend in dollars and apply across instance families, regions and, for Compute Savings Plans, across EC2, Fargate and Lambda. Savings Plans are more flexible and are usually the better default now; Reserved Instances still win where you also want a capacity reservation.

They let you break the bill down by team, environment or project once activated in the billing console. They fail because tagging is voluntary — anything created by hand, by an old pipeline or by a nested stack tends to arrive untagged, and untagged spend grows quietly. The fix is enforcement through SCPs or Config rules rather than a policy document asking people to remember.

Alarm on symptoms a user feels — error rate, p99 latency, queue age, failed payments — and on things that are actionable at 3am. Leave out CPU on an autoscaling fleet, individual instance health, and anything whose runbook is "wait and see", because those train people to ignore pages. An alarm nobody acts on is worse than no alarm, since it erodes trust in the ones that matter.

Work outward in order: does the instance have a public IP or Elastic IP; does the subnet's route table send 0.0.0.0/0 to an internet gateway; is that gateway attached to the VPC; does the security group allow the outbound traffic; does the NACL allow both the outbound request and the inbound reply, since it is stateless. Only then look at the OS firewall. Naming that sequence matters more than guessing the answer.

CPU being low is information: the bottleneck is elsewhere. Check memory and disk, which need the CloudWatch agent and are often not collected; check database connections and slow queries; check p99 rather than average latency, because an average hides the tail; check whether a T-family instance has exhausted CPU credits; and use X-Ray to find which hop is consuming the time. A distributed system can be slow with every component individually idle.

Throttling means concurrent executions hit either the account limit — 1,000 by default per Region — or the function's own reserved concurrency. Check the Throttles metric, then decide whether to raise the account quota, raise or remove the reservation, or slow the source. If the trigger is SQS, throttled invocations retry and messages eventually land in the dead-letter queue, so the fix may be to increase the limit rather than to make the function faster.

Stop the exposure first: enable Block Public Access at the bucket and account level and remove the offending policy or ACL. Then establish scope with CloudTrail data events and server access logs — what was read, by whom, over what period. Then rotate anything the objects contained, notify whoever owns the data, and only after that write the preventive control. Investigating before closing the hole is the wrong order and interviewers notice.

Almost certainly a hot partition: throughput is divided across partitions by partition key hash, so a skewed key concentrates traffic on one partition while the table average looks comfortable. Confirm with CloudWatch Contributor Insights, then fix the key design — add a suffix to spread writes, or move the access pattern to a GSI with a better key. Raising provisioned capacity treats the symptom expensively.

Put RDS Proxy in front to pool and reuse connections, which is the direct fix when the client is Lambda or a container fleet that scales faster than the database accepts connections. Alongside that, size the connection pool in the application rather than opening per request, move read traffic to read replicas, and cap the caller with reserved concurrency. Increasing max_connections alone usually just moves the failure into memory pressure.

Roll back before diagnosing. With blue/green, shift traffic to the old environment; with a canary, halt and reverse the shift; with Lambda, point the alias at the previous version. Restore service first, then read the logs and traces at leisure. Candidates who start describing log analysis while the site is down are answering the wrong question.

Open Cost Explorer, group by service, then by usage type, and compare with the previous month rather than looking at absolutes. Look for a new service someone enabled, a forgotten load test, storage growing because a lifecycle rule was never added, snapshots accumulating, NAT gateway processing from a chatty private workload, and cross-AZ data transfer introduced by a topology change. Set a budget alert afterwards, because the second occurrence is the unforgivable one.

Spread every tier across at least three AZs, keep Auto Scaling groups configured to replace lost capacity, put the database in Multi-AZ so failover is automatic, and make sure the remaining AZs have headroom to absorb the load rather than falling over in turn. Then test it — a design that has never had an AZ removed deliberately is a hypothesis, not a guarantee. Mentioning that you would run the test is the senior signal here.

Scale consumers out, increase the batch size so each invocation does more work, and check whether a poison message is being retried endlessly and blocking progress — the classic cause, fixed by a dead-letter queue and a maximum receive count. If the producer is genuinely faster than the consumer can ever be, the answer is backpressure or a slower producer, not an ever-larger consumer fleet.

Start with Cost Explorer, because anything that matters costs money and the bill is an honest inventory. Then AWS Config for a resource inventory and relationships, Trusted Advisor for obvious waste and risks, CloudTrail for who is actively changing things, and Resource Groups and tags for whatever structure exists. Reading Terraform or CloudFormation last, not first, because it tells you what someone intended rather than what is there.

Route 53 in front of CloudFront, an Application Load Balancer across at least two AZs, an Auto Scaling group of stateless application servers, RDS Multi-AZ or Aurora for the database, ElastiCache for hot reads, and S3 for static assets and uploads. Keep session state in the cache or the database so any instance can serve any request. The part candidates forget is that "stateless" is what makes the rest of the design work.

Have the browser upload straight to S3 with a presigned URL so large files never touch your servers, fire an S3 event notification to SQS, and let Lambda or Fargate consume the queue. The queue matters: a direct S3-to-Lambda trigger gives you no buffer, no retry control and no dead-letter queue, so a burst of uploads or a poison file becomes an outage rather than a backlog.

CloudFront for static and cacheable content, Route 53 latency-based routing to the nearest healthy region, and read replicas or DynamoDB global tables to keep reads local. Accept that writes usually stay in one region unless the data model tolerates conflict resolution — claiming full active-active writes without discussing conflicts is the answer that invites a hard follow-up.

SQS is a queue: one consumer group pulls each message and processes it, which decouples producer speed from consumer speed. SNS is publish-subscribe: one message is pushed to many subscribers at once. The common production pattern is SNS fanning out to several SQS queues, so each downstream service gets its own durable, independently retried copy rather than sharing one.

Inventory and categorise first, using the migration strategies — rehost, replatform, refactor, repurchase, retire, retain — because the biggest win is usually discovering how much can simply be retired. Move the lowest-risk workload first to prove the pipeline, use DMS for databases with continuous replication so cutover is short, and keep a rollback path until the new stack has survived a full business cycle. A big-bang cutover is the answer that signals no migration experience.

By traffic shape, team size and operational appetite. Spiky or event-driven work with modest per-request duration suits Lambda; steady throughput with custom runtimes suits containers; a large existing codebase with long-lived connections often stays on EC2 until there is a reason to move. The good answer names the constraint that decides it rather than ranking the three in the abstract.

Choose the isolation model first, because everything follows from it: a silo model gives each tenant separate resources — strongest isolation, highest cost; a pool model shares infrastructure and separates by tenant ID — cheapest, hardest to guarantee; a bridge model mixes the two, pooling compute and siloing data. Enforce the boundary with IAM conditions and per-tenant encryption keys rather than application-level checks alone, because an application bug should not be the only thing between two customers' data.

Spend the first minutes on requirements and scale — reads versus writes, latency target, consistency needs, growth — then sketch the happy path end to end before optimising anything. Name your assumptions out loud so the interviewer can correct them early, and reach for a managed service before building the thing yourself. What is being assessed is whether you can bound an open problem, not whether you memorised one architecture.