Back to interview questions
By
Team Sherlock.sh
AWS interviews should reveal how a candidate turns cloud services into a secure, reliable workload. Recruiters need to distinguish familiarity with service names from the ability to explain permissions, network paths, data guarantees, and recovery decisions. Ask candidates to identify the services and deployment assumptions behind an answer rather than rewarding an architecture diagram alone.
This guide to 100+ AWS Interview Questions and Answers contains 120 questions across beginner, intermediate, and experienced levels. It covers global infrastructure, identity, networking, compute, storage, databases, serverless applications, messaging, containers, infrastructure as code, observability, security, cost, and disaster recovery. Use the levels to match the role: a cloud engineer, application developer, and solutions architect may need different depths in the same service.
How can recruiters identify potential AI cheating, deepfakes, impersonation, and unauthorized assistance during AWS interviews?
Ask a candidate to trace an IAM denial, explain a duplicate queue message, or calculate how a recovery plan meets its target. A fluent list of AWS services does not establish independent ability to reason about the workload.
Sherlock AI helps recruiters detect potential AI-assisted cheating, deepfakes, candidate impersonation, and unauthorized real-time assistance during AWS interviews.
Combine interview-integrity checks with a small policy review or failure scenario and follow-up questions about trade-offs. Evaluate suspicious signals in context rather than treating a single signal as proof of misconduct.
AWS Interview Questions
Choose questions that match the responsibilities and workload. State the AWS partition, Region, service configuration, database engine, and recovery requirements where they affect the answer. Ask candidates to separate documented service behavior from assumptions about their own application.
AWS Interview Questions for Beginners
Establish the service vocabulary, ownership boundaries, identity model, basic network paths, and core data and compute choices.
What is AWS, and how is cloud computing different from owning servers?
How do AWS Regions, Availability Zones, and edge locations differ?
How would you choose an AWS Region for an application?
What does the AWS shared responsibility model mean?
What are AWS accounts, and why separate workloads into accounts?
What is IAM, and how do users, groups, and roles differ?
How do IAM permission policies control access?
What are temporary credentials and AWS STS?
Why are MFA and root-user protection important?
What is an Amazon VPC?
What is the difference between a public subnet and a private subnet?
How do VPC route tables and internet gateways work?
How do security groups differ from network ACLs?
What does a NAT gateway do?
What are VPC endpoints?
What is Amazon EC2, and what does an AMI provide?
How do EC2 instance families and purchasing options differ?
How do EBS, instance store, and EFS differ?
What does an EC2 Auto Scaling group do?
What is Elastic Load Balancing?
What is Amazon S3, and how are objects organized?
What consistency does Amazon S3 provide?
How do S3 Versioning and Lifecycle rules work together?
How do you keep an S3 bucket private?
What is Amazon RDS, and what does managed database operation include?
What is the difference between RDS Multi-AZ and a read replica?
What is DynamoDB, and when would you choose it over a relational database?
What are DynamoDB partition keys, sort keys, and indexes?
What is AWS Lambda, and what does serverless mean?
How does Lambda invocation affect retries and error handling?
What does Amazon API Gateway provide?
How do SQS, SNS, and EventBridge differ?
What are SQS visibility timeouts and dead-letter queues?
How do ECS, EKS, and Fargate relate?
How do CloudWatch and CloudTrail differ?
What are infrastructure as code and AWS CloudFormation?
How do encryption, KMS, and secrets management fit together?
What are the pillars of the AWS Well-Architected Framework?
How do you estimate and control AWS costs?
What do availability, backup, RTO, and RPO mean?
AWS Interview Questions for Intermediate
Explore permissions, network configuration, storage guarantees, database access patterns, event processing, containers, deployment, and monitoring.
How do you evaluate an IAM request across identity policies and guardrails?
How do you configure a cross-account role without confusing trust and permissions?
How do you write a least-privilege S3 read policy?
How do KMS key policies interact with IAM permissions?
How should an application retrieve and rotate database secrets?
How do you diagnose a private subnet that cannot reach an external API?
When should you use a gateway endpoint versus an interface endpoint?
How do you connect VPCs without assuming peering is transitive?
How do you select a useful EC2 Auto Scaling target-tracking metric?
How do ALB health checks and connection draining affect deployments?
How do you combine On-Demand, Spot, and commitment discounts?
How do you secure S3 access without relying on object ACLs?
How do SSE-S3, SSE-KMS, and client-side encryption differ?
How do you make presigned S3 uploads safer?
How should a multipart upload handle failures and incomplete parts?
What does S3 replication copy, and what must you configure explicitly?
How do you handle replication lag and read-after-write requirements with RDS read replicas?
How do you manage database connections from Lambda with RDS Proxy?
How do DynamoDB partition and sort keys support an access pattern?
When should you choose a DynamoDB GSI or LSI?
When do you request a strongly consistent DynamoDB read?
How do conditional writes prevent lost updates in DynamoDB?
When should you use DynamoDB transactions rather than batch operations?
How do reserved and provisioned Lambda concurrency differ?
How do you configure Lambda asynchronous failure handling with event age, retries, and destinations?
How do partial batch responses improve Lambda processing of SQS messages?
How do you choose an SQS visibility timeout and deletion strategy?
How do you configure and operate an SQS dead-letter queue?
What guarantees does an SQS FIFO queue actually provide?
How do EventBridge event patterns, retries, and dead-letter queues work together?
How do EKS workloads obtain AWS permissions without sharing node credentials?
How do ECS task roles differ from task execution roles?
How do you design health checks and rollout controls for a container service?
How do CloudFormation change sets reduce deployment risk?
What can CloudFormation drift detection prove and not prove?
How do you deploy Lambda versions safely with aliases?
How do you combine metrics, logs, traces, and audit events during debugging?
How do you make CloudWatch alarms actionable rather than noisy?
How do you build useful AWS cost allocation and budget controls?
How do you test a backup restore instead of merely checking that backups exist?
AWS Interview Questions for Experienced
Use production scenarios to assess architectural judgment, recovery planning, security, scaling, incident diagnosis, and financial trade-offs.
How would you choose a disaster-recovery strategy from RTO and RPO requirements?
How would you prove that a multi-AZ application can survive an Availability Zone failure?
How would you fail over a workload to another Region without creating split-brain writes?
What must a safe regional failback plan include?
How would you make a payment API idempotent when clients retry after a timeout?
How does the transactional outbox pattern prevent a database-and-message dual-write failure?
When would you use a saga instead of a distributed database transaction?
How would you contain a retry storm during a dependency outage?
How would you diagnose and drain an SQS backlog safely?
How would you process ordered business events without claiming exactly-once side effects?
How would you fix a hot partition in DynamoDB?
How would you choose between MREC and MRSC DynamoDB global tables?
How would you prevent overselling inventory across Regions?
How would you diagnose an RDS failover that leaves the application unavailable?
How would you handle an ambiguous database commit after a network timeout?
How would you design S3-based recovery against accidental deletion and ransomware?
How would you select and validate S3 Object Lock retention controls?
How would you structure organization-wide guardrails without confusing them with permissions?
How would you respond to suspected compromise of an AWS workload role?
How would you design cross-account access for a third-party service?
How would you design KMS controls and recovery for encrypted data?
How would you enforce tenant isolation in a shared AWS application?
How would you design connectivity among many VPCs without assuming peering is transitive?
How would you make outbound connectivity resilient while controlling data-transfer costs?
How would you design hybrid connectivity that survives a circuit failure?
What would you review before running a sensitive workload on Amazon EKS?
How would you deploy a container service without dropping in-flight requests?
How would you prevent Lambda scaling from exhausting a relational database?
How would you investigate high Lambda latency and unexpected serverless costs?
How would you define useful SLOs and alarms for an AWS application?
How would you investigate a slow request that crosses several AWS services?
How would you perform a controlled resilience experiment?
How would you recover a failed CloudFormation deployment safely?
How would you deploy a backward-compatible database schema change?
How would you compare AWS architectures using unit economics rather than monthly totals alone?
How would you evaluate Savings Plans, reservations, and Spot capacity for a workload?
How would you reduce cross-AZ and cross-Region transfer costs without weakening reliability?
How would you migrate a database with a short cutover window and a credible rollback plan?
How would you evaluate data residency requirements for a multi-Region AWS design?
How would you prepare an AWS workload for a major traffic event?
AWS Interview Questions and Answers
These answers follow the question bank in the same order and begin with direct responses candidates can adapt. Examples assume the commercial AWS partition unless stated otherwise; illustrative account IDs, names, and Regions are placeholders. CLI examples use AWS CLI v2 syntax. Policy and infrastructure snippets are scoped examples, not complete deployment packages, and must not be run against a live account as part of reading this guide.
AWS Interview Questions and Answers for Beginners
These answers connect AWS fundamentals to concrete behavior without treating managed services as responsibility-free infrastructure.
1. What is AWS, and how is cloud computing different from owning servers?
AWS is a collection of on-demand infrastructure and managed services that I can configure through APIs, tools, and the console. Instead of purchasing physical servers before demand is known, I provision capacity and pay according to each service's charging model. That changes procurement and operations; it does not remove architecture or cost management.
For example, a small application could use EC2 for virtual machines, S3 for objects, and a managed database instead of building those capabilities from physical equipment. Elasticity means adjusting capacity to demand. Scalability means being able to handle growth; a scalable system is not necessarily configured to scale automatically.
I would explain the trade-off rather than promise that cloud is always cheaper. Idle resources, data transfer, requests, support, and licenses can materially affect the bill. AWS operates the underlying infrastructure, while the customer still owns choices such as access control, application correctness, and the workload's data. The exact division depends on the service.
2. How do AWS Regions, Availability Zones, and edge locations differ?
A Region is a geographic deployment area containing multiple Availability Zones. An Availability Zone is an isolated infrastructure location made up of one or more data centers; it is not simply another server rack. Edge locations support services such as content delivery near users and are not interchangeable with Regions for deploying arbitrary workloads.
I normally spread a production application's redundant components across multiple Availability Zones to reduce exposure to a single-zone failure. That is different from a multi-Region design, which introduces additional replication, routing, operational, and cost decisions. Two instances in the same subnet do not provide zone diversity because a subnet belongs to one Availability Zone.
CloudFront can serve cached content near users while the origin remains in a selected Region. It does not automatically make the origin database multi-Region. I avoid memorizing a total Region count because infrastructure changes; the useful interview skill is identifying failure boundaries and the actual scope of each resource.
3. How would you choose an AWS Region for an application?
I select a Region using user latency, data-residency requirements, required service features, operational dependencies, and total cost. A nearby Region is often helpful, but geographic distance alone does not establish application latency or regulatory suitability.
I first verify that the needed database engine, instance type, managed service feature, and deployment model are available there. I then measure representative user-to-application and application-to-dependency latency. If the application depends on a database in another Region, moving only its web tier closer to users may make requests slower rather than faster.
I also consider the recovery Region and how data, keys, secrets, container images, and infrastructure definitions would become available there. Commercial AWS Regions, AWS GovCloud (US), and AWS China have different account and partition boundaries; I do not assume an ordinary account or ARN works across all three. In these examples, the default assumption is a commercial AWS Region with the named service available.
4. What does the AWS shared responsibility model mean?
The shared responsibility model divides security work between AWS and the customer. AWS protects the infrastructure that operates its cloud services. The customer protects the workload, including data classification, identities, permissions, application behavior, and the service configuration under their control.
The boundary changes with the service. On EC2, I manage the guest operating system, patching, application software, and security-group configuration. With a managed database, AWS handles more of the infrastructure and database-service operation, but I still control database users, network access, application queries, retention choices, and appropriate use of the data.
For example, encrypting an S3 object does not compensate for granting an unintended principal permission to read it: the service can legitimately decrypt an authorized read. Similarly, using a managed service does not make an insecure application secure. I turn the responsibility model into an explicit operational checklist with named owners rather than treating it as a slogan or a blanket compliance guarantee.
5. What are AWS accounts, and why separate workloads into accounts?
An AWS account is a boundary for resource ownership, access administration, quotas, and billing attribution. I use separate accounts to isolate environments or organizational responsibilities, especially production, nonproduction, security tooling, and centralized logs.
AWS Organizations provides centralized account management and governance. Organizational units group accounts for policies, and consolidated billing simplifies payment without merging every account's resources or permissions. Service control policies constrain available permissions in their applicable scope; they do not themselves grant an engineer permission to perform an action.
For example, a developer can administer a test application in a development account without automatically receiving production access. A deliberate cross-account role can provide a controlled production workflow. This is stronger isolation than relying only on naming conventions or tags in one account, though cross-account access and shared networking still need careful design. I keep the management account's workload footprint small and avoid describing account separation as a complete substitute for least privilege, monitoring, or recovery planning.
6. What is IAM, and how do users, groups, and roles differ?
IAM controls who can perform which actions on AWS resources. An IAM user represents an identity in an account and can have long-term credentials. A group is a collection of IAM users used to assign permissions; it is not an identity that an application assumes. A role is an assumable identity that provides temporary credentials for a session.
For workforce access, I normally prefer federation and centrally managed access rather than creating a long-lived access key for every person. For workloads, I attach an appropriate role through the service's supported mechanism, such as an EC2 instance profile or a Lambda execution role.
A role has two distinct questions: who may assume it, governed by its trust policy and applicable authorization, and what the resulting session may do, governed by permission policies and other controls. Granting a role permission to read S3 does not automatically let any user assume it. Likewise, assuming a role does not bypass explicit denies or organization-level restrictions.
7. How do IAM permission policies control access?
IAM policies describe allowed or denied actions, resources, and optional conditions. Identity-based policies attach to users, groups, or roles; supported resource-based policies attach to resources. Access evaluation starts from no permission, and an applicable explicit deny overrides an allow. Boundaries, session policies, and organization policies can further constrain permissions.
This illustrative identity-policy statement allows reading objects under one prefix, not listing the bucket or writing objects:
JSON example
The bucket name is a placeholder, and the policy is not a complete access configuration. A bucket policy, encryption-key policy, or applicable deny can still block the request. I use the resource ARN shape required by each action: an object action usually needs an object ARN, while a bucket-list action uses the bucket ARN. Least privilege means selecting actions and scope deliberately, then testing the intended allowed and denied cases.
8. What are temporary credentials and AWS STS?
Temporary AWS credentials consist of an access key ID, secret access key, and session token with an expiration. AWS Security Token Service, or STS, issues temporary credentials for supported federation and role-assumption flows. They reduce reliance on distributing permanent keys, but they are still secrets while valid.
An application running with a properly configured workload role can obtain and refresh credentials through the AWS SDK's credential provider chain. I do not copy those credentials into source code, a container image, or a public log. A session token is required when signing requests with temporary credentials; omitting it is a common configuration error.
The session's effective access depends on the role and applicable controls, not merely its expiration time. For troubleshooting, this illustrative CLI command identifies the active caller without changing resources:
Bash command
It still contacts AWS and requires an appropriate environment; it has not been executed for this article. I select supported regional endpoints explicitly when designing regional dependencies.
9. Why are MFA and root-user protection important?
MFA adds an authentication factor beyond a password, reducing the risk that a stolen password alone grants access. I enable appropriate MFA for privileged human access and protect the root identity especially carefully because some account-level tasks require root privileges.
The root user is not the normal application identity or daily administrator. I use delegated access for routine work, avoid creating root access keys, secure account-recovery channels, and monitor exceptional root activity. Where an organization uses centralized root-access management, I follow that supported model rather than assuming every member account should retain standalone root credentials.
MFA does not replace authorization or protect every form of credential automatically. A stolen live session can still be dangerous, and adding MFA to console sign-in does not magically invalidate a leaked workload access key. I combine authentication controls with short-lived credentials, least privilege, logging, and a recovery procedure that authorized responders can actually use during an incident.
10. What is an Amazon VPC?
A VPC is a logically isolated network in an AWS Region. I choose its address ranges and configure subnets, routes, gateways, and network-access controls. A VPC can contain subnets in multiple Availability Zones, but each subnet belongs to one zone.
For example, an application could use public subnets for an internet-facing load balancer and private subnets for application instances and a database. The placement expresses intended network paths; it does not automatically grant or deny application permissions. IAM authorization and database authentication remain separate from packet reachability.
I plan nonoverlapping address ranges when VPCs may connect to each other or to an on-premises network. I also account for subnet address capacity, DNS behavior, IPv4 versus IPv6, and the needs of managed services that create network interfaces. A VPC is not a physical dedicated data center, and attaching resources to one does not by itself guarantee isolation from every other workload or the internet.
11. What is the difference between a public subnet and a private subnet?
A public subnet has a route to an internet gateway. A private subnet does not have a direct route to an internet gateway, although it may have outbound connectivity through a NAT device or private connectivity to other networks and services. An isolated subnet has no route outside its intended local network paths.
For IPv4, placing an EC2 instance in a public subnet is not enough to make it internet-reachable. The instance also needs suitable public addressing, security-group and network-ACL rules, and a listening application. Conversely, calling a subnet private does not mean its instances cannot initiate internet connections through NAT.
A useful design is an internet-facing load balancer in public subnets, application instances in private subnets, and a database reachable only from the application tier. I verify the actual associated route table rather than relying on subnet names. IPv6 routing and egress controls require their own review; assumptions based on IPv4 address translation do not automatically carry over.
12. How do VPC route tables and internet gateways work?
A route table determines where traffic goes based on its destination. Each route has a destination range or supported prefix list and a target, such as an internet gateway, NAT gateway, or peering connection. A subnet uses its explicitly associated route table or the VPC's main route table.
For an illustrative IPv4 public subnet, the VPC-local route handles local destinations and a default route sends other destinations toward an attached internet gateway:
Plain-text example
This is a conceptual table, not executable configuration. The default route is the broad fallback; more-specific matching routes take precedence under routing rules. The gateway provides a path, not permission to access every workload.
When a connection fails, I check both the forward and return paths, addressing, security groups, network ACLs, and the application listener. Adding a route cannot fix an IAM denial or a database rejecting credentials. I also avoid creating an internet route merely to reach a service that supports an appropriate private endpoint.
13. How do security groups differ from network ACLs?
Security groups are stateful allow-rule controls associated with supported resources' network interfaces. If permitted traffic establishes a tracked flow, its response is allowed without a separate response rule. Network ACLs operate at the subnet boundary, support allow and deny rules, and are stateless, so return traffic must also be allowed.
Security-group rules are combined as permissions; they do not provide numbered explicit-deny rules. Network-ACL rules are evaluated in rule-number order until a match. I normally use security groups for application-tier access and add network ACLs only where subnet-level controls have a clear purpose.
For example, the database's security group can allow the database port from the application tier's security group instead of from the whole internet. That reference is a network rule, not IAM role trust and not an application login. With a restrictive network ACL, I also need the relevant return-path ephemeral ports. I avoid assuming that a stateful security group makes every firewall or route on the path stateful.
14. What does a NAT gateway do?
A NAT gateway translates addresses so private workloads can initiate supported outbound connections without accepting unsolicited inbound connections through that gateway. In a conventional zonal IPv4 design, a public NAT gateway is placed in a public subnet, uses an Elastic IP address, and reaches the internet through the VPC's internet gateway.
The private subnet's route table sends internet-bound traffic to the NAT gateway. This does not make the private instance publicly addressable. A private NAT gateway serves private connectivity use cases and does not provide internet access through an internet gateway simply because it is called NAT.
NAT is not an application firewall, a proxy authorization system, or a free network hop. I review processing charges, routing, throughput needs, and the failure domain of the selected NAT deployment model. For a zonal design, routing each zone through a gateway in that zone avoids making all egress depend on one other zone. I also check whether VPC endpoints can meet specific AWS-service connectivity requirements.
15. What are VPC endpoints?
VPC endpoints provide supported private paths from a VPC to services or resources without requiring the application's traffic to traverse an internet gateway or NAT gateway. The endpoint type matters. Interface endpoints use private network interfaces and AWS PrivateLink; gateway endpoints use route-table entries for supported services such as S3 and DynamoDB.
For example, an application in a private subnet may reach S3 through a gateway endpoint rather than send that traffic through NAT. An interface endpoint for another AWS service may require suitable security-group rules and DNS configuration so the service name resolves to the intended private endpoint.
An endpoint is connectivity, not blanket authorization. IAM policies, resource policies, and supported endpoint policies still determine what requests are permitted. I check service and Region support, DNS behavior, cross-network access requirements, and costs before selecting a type. I also avoid assuming that all endpoint types share the same routing, transitivity, or availability behavior.
16. What is Amazon EC2, and what does an AMI provide?
EC2 provides configurable virtual servers called instances. An Amazon Machine Image, or AMI, supplies the image and launch information used to create an instance, including an operating-system baseline and any packaged software. The instance type determines the available combination of CPU, memory, networking, and related hardware capabilities.
I combine an AMI with networking, storage, security groups, a workload role, and launch configuration. An AMI is not a running server, and selecting a trusted AMI does not remove the need to patch and operate the guest system. Architecture compatibility also matters: an Arm image and an x86 instance type are not interchangeable.
For repeatable deployment, I build or select a controlled image and keep configuration reproducible rather than hand-editing a long-lived server. Application state should survive instance replacement through an appropriate data service or durable storage design. Before treating an image as reusable, I check that it does not contain credentials, host-specific state, or unapproved software.
17. How do EC2 instance families and purchasing options differ?
An EC2 instance family describes a hardware profile, such as general-purpose, compute-optimized, memory-optimized, or accelerated computing. A purchasing option describes how capacity is obtained or charged. These are separate choices: I first match the workload's performance needs, then choose a suitable commercial and availability model.
On-Demand is useful when I need flexibility without a long usage commitment. Savings Plans and Reserved Instances can reduce eligible charges in exchange for commitments, but their matching and flexibility rules differ. Spot uses spare capacity and can be interrupted, so it suits fault-tolerant work such as resumable batch processing rather than an unprotected single critical instance.
I do not say that every discount buys a capacity reservation. Capacity reservation is a distinct requirement, and some zonal reservation arrangements differ from regional discounts. I evaluate actual Region, operating system, tenancy, licensing, instance availability, utilization, and interruption handling. A lower hourly rate is not a saving if an oversized or idle instance remains provisioned.
18. How do EBS, instance store, and EFS differ?
EBS provides persistent block volumes for EC2. Instance store provides temporary storage physically associated with the instance's host. EFS provides a managed shared file system that supported clients can mount, commonly for Linux workloads needing shared file access.
I use EBS when the application needs a block device, such as a filesystem or a database volume, and choose the volume performance settings deliberately. EBS volumes are scoped to an Availability Zone and are not automatically a multi-zone shared filesystem. Deletion-on-termination settings can still remove a volume when its instance terminates.
I use instance store for replaceable data such as caches or intermediate processing results, not the only copy of important records. Stopping, hibernating, terminating, or losing the underlying host can lose that data. EFS suits shared file semantics; its Regional and One Zone storage choices have different failure-domain implications. None of these options eliminates the need to understand backups, throughput, application consistency, access controls, and recovery testing.
19. What does an EC2 Auto Scaling group do?
An EC2 Auto Scaling group manages a collection of instances and maintains a desired capacity within configured limits. It can replace unhealthy instances and change capacity according to scaling policies or schedules. I normally define instances through a launch template and distribute the group across suitable subnets.
For example, minimum capacity might be two instances, desired capacity two, and maximum capacity six. A target-tracking policy can increase capacity as a chosen metric rises, but new instances still need time to boot, initialize, and become healthy. Scaling is not instantaneous, and a metric should reflect the actual bottleneck.
The application must tolerate instances being added and removed. I keep durable state outside replaceable instances, drain active work, and use appropriate health checks and lifecycle behavior. Auto Scaling does not automatically make a single database scale, guarantee capacity in every failure, or ensure an application is healthy merely because the VM is running. Load balancing and health-check configuration complete the design.
20. What is Elastic Load Balancing?
Elastic Load Balancing distributes incoming traffic across registered targets. An Application Load Balancer suits HTTP and HTTPS routing, including host- and path-based rules. A Network Load Balancer suits transport-level traffic and requirements where its connection and addressing characteristics are useful. Gateway Load Balancer serves network-appliance insertion rather than ordinary web routing.
A load balancer uses listeners, target configuration, and health checks. For a web application, I might terminate HTTPS at an Application Load Balancer and forward traffic to private application targets. I still decide whether the downstream connection also needs TLS and restrict direct target access appropriately.
Load balancing is not the same as Auto Scaling: one distributes requests, while the other changes or maintains compute capacity. Health checks need to reflect readiness without unnecessarily coupling every target to a shared dependency. I also understand product-specific behavior when all targets are unhealthy rather than promising that unhealthy traffic is impossible. A load balancer cannot repair application errors or create missing database capacity.
21. What is Amazon S3, and how are objects organized?
Amazon S3 is object storage. An object contains data and metadata and is identified by a key within a bucket. A key such as invoices/2026/001.pdf can look like a filesystem path, but in a general purpose bucket the apparent folders are prefixes, not ordinary disk directories.
I choose S3 for workloads such as documents, backups, static assets, and data-lake objects. It is not an EC2 block device or a drop-in shared filesystem with arbitrary in-place byte updates. Applications normally use object operations and should be designed around those semantics.
This guide's basic bucket examples assume S3 general purpose buckets; directory and other specialized bucket types have different capabilities. I choose storage classes based on access frequency, retrieval requirements, minimum-duration charges, resilience needs, and lifecycle behavior. I also define access policies and retention explicitly. An object's apparent path is not a security boundary until policies enforce it, and a bucket's durability does not protect against every authorized deletion or application-level mistake.
22. What consistency does Amazon S3 provide?
For general purpose S3 buckets, successful object writes and deletes are strongly consistent: a subsequent read or list observes the completed change. Overwriting an object does not require an application to wait for eventual consistency before reading the new value. Updates to a single key are atomic, so readers do not receive a partially written object.
For example, after a successful upload of reports/result.json, a later GET or LIST can observe that object. This does not create a transaction across several keys. If I upload a data object and then update a separate manifest, clients can observe an intermediate state unless the application protocol accounts for it.
I also distinguish origin consistency from other layers. A CDN or application cache may still serve an older response, and cross-Region replication is not an immediate global commit. Some bucket-configuration changes have different propagation behavior. Concurrent writers need a deliberate coordination or conditional-write strategy; strong consistency is not automatic prevention of conflicting business updates.
23. How do S3 Versioning and Lifecycle rules work together?
S3 Versioning retains multiple versions of an object, helping recover from overwrites and some deletions. In a versioning-enabled general purpose bucket, an ordinary delete usually creates a delete marker rather than removing every stored version. Permanently deleting a specified version is a different action and requires appropriate permission.
Lifecycle rules automate transitions and expiration for selected objects. I define current-version and noncurrent-version behavior separately because retaining old versions indefinitely can keep storage costs growing even when the current view looks small. Lifecycle expiration is asynchronous, not a scheduler that promises deletion at an exact second.
For example, a policy might keep current invoices readily accessible, transition older versions according to retention needs, and remove obsolete noncurrent copies only when permitted. I check storage-class minimum-duration and retrieval charges rather than assuming every transition saves money. Versioning is not the same as immutability or an independent backup: authorized deletion, account compromise, and compliance-retention requirements may need additional controls such as Object Lock or separately protected copies.
24. How do you keep an S3 bucket private?
I keep an S3 bucket private by preventing unintended public grants and granting only the identities and operations the application needs. I review Block Public Access at its applicable levels, bucket and access-point policies, object-ownership settings, and any legacy ACL use. I do not rely solely on an obscure bucket name.
For a private document service, the application role might read a specific prefix while users authenticate to the application. A presigned URL can provide time-limited delegated access to a particular operation, but anyone who obtains a valid URL may be able to use it within its constraints. I avoid logging it as harmless text.
Encryption is a separate protection. An encrypted object can still be readable by an unintended principal if authorization allows the request and required key access is available. Conversely, a private bucket does not mean network access must use a VPC endpoint. I test both intended access and denied anonymous or cross-account access, and review public-access findings when configurations change.
25. What is Amazon RDS, and what does managed database operation include?
Amazon RDS is a managed relational database service. It handles significant infrastructure and operational work around supported engines, such as provisioning, backups, maintenance workflows, and supported availability features. I still choose the engine, capacity, access configuration, retention, and deployment topology.
Managed does not mean the application stops needing database engineering. I remain responsible for schema design, indexes, query efficiency, connection management, database permissions, and transaction correctness. I also plan maintenance and verify what automated backups and point-in-time recovery cover for the chosen engine and configuration.
For example, an order system with relational constraints and transactional updates may fit PostgreSQL on RDS. I would not expose it publicly merely because the service is managed; the application should reach it through intended private paths and credentials. This answer describes standard RDS engine deployments, not a claim that every feature is identical in Aurora, RDS Custom, or every engine edition. Engine support, licensing, version behavior, and regional availability must be checked for the actual workload.
26. What is the difference between RDS Multi-AZ and a read replica?
RDS Multi-AZ primarily addresses availability, while a read replica commonly provides read scaling or a replication-based recovery option. The exact Multi-AZ deployment type matters. A traditional Multi-AZ DB instance deployment has a standby for failover that does not serve application reads. A Multi-AZ DB cluster has readable instances as well as its writer, subject to supported engines and configuration.
Read replicas commonly use asynchronous replication, so applications can observe replication lag. I avoid routing a read-after-write request to a replica when the operation requires immediately observing the committed write unless the application has an appropriate consistency strategy.
For an interview, I name the engine and deployment type before discussing failover, replication, or endpoints. I also distinguish automatic failover from promoting a replica through a recovery procedure. Multi-AZ within one Region is not automatically cross-Region disaster recovery, and neither a standby nor a replica replaces backups against erroneous writes that replicate successfully. Connection retries and endpoint handling remain application responsibilities.
27. What is DynamoDB, and when would you choose it over a relational database?
DynamoDB is a managed NoSQL database built around key-based access to items. I choose it when access patterns can be modeled explicitly and the workload benefits from managed scaling without operating database servers. I choose a relational database when joins, relational constraints, and flexible SQL querying are central requirements.
For example, retrieving a customer's shopping cart by customer ID is a natural key lookup. A reporting workload requiring arbitrary joins across many entities may fit a relational or analytical system better. DynamoDB supports transactions and conditional operations, so NoSQL does not mean that every update must be uncoordinated.
The design starts with access patterns, key distribution, item size, and index requirements, not with copying relational tables mechanically. Capacity mode, consistency options, backups, and indexes affect cost and behavior. I do not promise a latency number for every request or assume on-demand capacity removes all throttling risks. Global tables also have configuration-specific consistency and replication behavior that must be evaluated separately from a single-Region table.
28. What are DynamoDB partition keys, sort keys, and indexes?
A DynamoDB table's primary key is either a partition key alone or a partition key plus sort key. The complete primary key uniquely identifies an item. With a composite key, multiple items can share a partition-key value as long as their sort-key values differ.
For example, I could model a customer's orders with partition key customerId and sort key orderTimestamp. A Query supplies the partition-key value and can apply a supported sort-key condition, allowing a time range for one customer without scanning every order.
Secondary indexes support additional access patterns. A global secondary index can use a different partition and sort key; a local secondary index keeps the table's partition key and uses another sort key. Their creation constraints, quotas, and consistency capabilities differ. A filter expression is applied after reading candidate items and is not a replacement for a suitable key. I also avoid concentrating all traffic on one hot logical key merely because the table's total configured capacity looks sufficient.
29. What is AWS Lambda, and what does serverless mean?
AWS Lambda runs application code while AWS manages the underlying compute infrastructure. Serverless means I do not provision and administer the underlying servers for that execution model; it does not mean servers do not exist or that application operations disappear.
For the traditional handler-based examples here, I mean Lambda Event Functions: an event or API invocation reaches a handler, which performs bounded work and returns or completes. The execution role grants access to downstream services. I configure resources, timeout, concurrency controls, observability, and dependencies to match the workload.
For example, an object-upload event can trigger validation and metadata extraction. The function must still handle malformed input, downstream failures, duplicate events, and durable state. I do not rely on local files or in-memory variables as the only durable record between invocations. Current Lambda offerings include other execution models, so handler invocation and retry statements should not be generalized to every Lambda primitive. Runtime support, packaging, regional availability, and the chosen model should be verified for deployment.
30. How does Lambda invocation affect retries and error handling?
Lambda Event Function retry behavior depends on the invocation path. With a synchronous direct invocation, the caller receives the result or error and decides whether to retry. With asynchronous invocation, Lambda queues the event and applies its asynchronous retry and event-age configuration. Event source mappings, such as SQS integration, have their own source-specific processing rules.
I therefore ask who owns the retry before changing a function. A client timeout does not prove that the function performed no work. If an order was saved before the response was lost, blindly retrying can create a duplicate unless the operation uses a stable idempotency key and durable duplicate detection.
For SQS, processing is at least once and batch failures can cause messages to be retried; partial-batch responses can reduce unnecessary retries when configured correctly. I monitor failed and aged-out work and configure a suitable failure destination or queue for the relevant path. I never promise exactly-once business effects merely because the handler returned successfully once.
31. What does Amazon API Gateway provide?
Amazon API Gateway provides managed API endpoints, routing, integrations, and supporting controls for REST, HTTP, and WebSocket APIs. I use it to expose an intentional API contract rather than making clients call internal services directly.
For a simple request path, a client calls an authenticated HTTP API route, API Gateway invokes a Lambda integration, and the response returns to the client. The gateway does not automatically validate every business rule or decide whether a user may access a particular order. Authentication, endpoint authorization, input validation, and record-level authorization are related but distinct responsibilities.
I choose the API type based on required features rather than treating REST APIs and HTTP APIs as different names for the same product. Authorizer options, usage plans, transformations, caching, and other capabilities differ. I configure timeouts, throttling, logging, and error responses deliberately and avoid logging secrets. CORS is a browser access mechanism, not authentication; allowing an origin does not prove a caller is authorized or prevent direct nonbrowser requests.
32. How do SQS, SNS, and EventBridge differ?
SQS is a queue for buffering work and decoupling producers from consumers. SNS is a publish-subscribe service that fans messages out to subscriptions. EventBridge routes events to targets using event patterns and integrations. I choose based on whether I need work distribution, fan-out notification, or event-based integration.
For example, an order-created event could be routed by EventBridge to several business workflows. A queue in front of a slow worker absorbs bursts, while an SNS topic can publish the same notification to multiple subscribed queues. Multiple workers reading one SQS queue normally compete for work; that is not the same as every worker receiving every message.
Delivery and ordering guarantees depend on the service, queue or topic type, and integration. Standard SQS queues provide at-least-once delivery and best-effort ordering. FIFO deduplication and message-group ordering do not make arbitrary downstream side effects exactly once. I design idempotent consumers, failure handling, retention, and observability instead of assuming that a message broker removes all duplication or loss scenarios.
33. What are SQS visibility timeouts and dead-letter queues?
An SQS visibility timeout temporarily hides a received message from subsequent receives while a consumer works on it. Receiving is not deletion. After successful processing, the consumer or its integration deletes the message using the appropriate receipt handle; otherwise, it can become visible again when the timeout expires.
If processing may take forty seconds, a ten-second visibility timeout risks concurrent repeated work. I choose a suitable timeout and, where necessary, extend visibility while processing. I still make consumers idempotent because standard queues can deliver duplicates and a crash can occur after a business update but before deletion.
A dead-letter queue collects messages that meet a configured redrive policy after repeated unsuccessful receives. It is a place to investigate and recover work, not a garbage bin or proof of permanent failure. I alarm on it, preserve diagnostic context without leaking sensitive data, fix the cause, and redrive carefully. For FIFO workflows, moving a failed message away can also affect the business ordering assumptions.
34. How do ECS, EKS, and Fargate relate?
ECS and EKS orchestrate containers. ECS provides AWS-native orchestration using tasks and services. EKS provides managed Kubernetes, which is useful when the team needs Kubernetes APIs and ecosystem compatibility. Fargate is a managed compute option for supported container workloads; it is not a third orchestration system competing with both.
With ECS on Fargate, I define the container task and its resource, networking, and IAM settings without managing the underlying EC2 hosts. With an EC2-backed container cluster, I retain more host-level control and operational responsibility. EKS has its own supported compute options and Kubernetes-specific configuration requirements.
For a small service, I might choose ECS for straightforward AWS integration. I would choose EKS when concrete Kubernetes requirements justify its additional concepts, not because containers automatically require Kubernetes. In either case, I maintain container images, application dependencies, secrets, health checks, resource limits, and deployment safety. Moving a vulnerable image into a managed orchestrator does not patch it or guarantee that its application can scale safely.
35. How do CloudWatch and CloudTrail differ?
CloudWatch helps me observe workload behavior through metrics, logs, alarms, dashboards, and related monitoring features. CloudTrail records supported AWS account activity for auditing, such as API actions performed by users, roles, and services. I often use both because performance symptoms and configuration changes answer different questions.
If an application suddenly returns errors, CloudWatch can show error rates, latency, and application logs. CloudTrail may help identify a recent security-group change or deployment-related API action. Correlating timestamps and request identifiers is more useful than assuming one service contains every possible event.
I configure the necessary telemetry explicitly. Guest operating-system metrics and application logs may require an agent or instrumentation, and CloudTrail management-event history is not a blanket record of every object-level data access. Relevant data events, retention, regional coverage, and destinations need deliberate configuration. I protect logs from tampering and sensitive-data exposure, and create actionable alarms with an owner rather than collecting data that nobody reviews.
36. What are infrastructure as code and AWS CloudFormation?
Infrastructure as code expresses infrastructure in version-controlled definitions instead of relying only on manual console changes. CloudFormation uses templates to manage related resources as a stack. I can review proposed changes, reproduce environments, and track infrastructure definitions alongside application work.
This small illustrative template declares a queue; deploying it would create a billable resource and is not part of this article's validation:
YAML example
A template is not automatically a safe deployment. I review IAM implications, replacement behavior, retention policies, dependencies, and a change set before approving execution. Some updates replace resources or can lose data without suitable protection. I keep secrets out of plain template values and use supported references or secret-management integrations. I also detect configuration drift, because a manual resource change can make the deployed environment differ from its source definition.
37. How do encryption, KMS, and secrets management fit together?
Encryption protects data using cryptographic keys, while secrets management protects sensitive values such as database passwords and API tokens. AWS KMS manages cryptographic keys and key-use authorization; Secrets Manager stores and retrieves secrets and supports rotation workflows. TLS protects supported network connections in transit, which is separate from encrypting stored data.
For example, a database password can be stored in Secrets Manager, encrypted using a KMS key, and retrieved by an application role with narrowly scoped permission. The application still needs to avoid logging the password and handle rotation without retaining an obsolete credential indefinitely.
I separate permission to use a key from permission to administer it, and plan recovery before disabling or deleting keys. Encrypting data is not enough if an unintended identity can request decryption through an authorized service. I also distinguish key rotation from secret rotation: changing cryptographic key material does not automatically change a database password or rewrite every existing ciphertext. Service-specific integration and regional key behavior matter.
38. What are the pillars of the AWS Well-Architected Framework?
The six AWS Well-Architected pillars are operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. I use them as a structured way to review trade-offs rather than as a claim that one architecture is best for every workload.
For an order-processing system, operational excellence includes deployment and incident procedures; security covers identities and data protection; reliability includes retries and recovery; performance efficiency examines suitable resources and measured bottlenecks; cost optimization examines utilization and business value; sustainability considers resource efficiency and environmental impact.
The pillars can pull in different directions. Extra redundant capacity may improve availability while increasing cost and resource consumption. I start with business objectives, quantify requirements where possible, and document the decision rather than maximizing one metric in isolation. A Well-Architected review should produce prioritized risks and improvement actions with owners. Completing a questionnaire does not prove that the application meets its recovery objectives, security requirements, or user-facing performance targets; those need evidence and testing.
39. How do you estimate and control AWS costs?
I estimate AWS costs from the workload's usage model, not merely the headline compute price. I account for compute duration, storage and backups, requests, provisioned capacity, data transfer, network services, observability, licenses, and applicable support charges. Rates and charging units depend on service, Region, and configuration.
For an illustrative calculation, ten workers running three hours daily for thirty days consume 900 worker-hours before considering the instance rate or other charges:
Plain-text example
That is usage arithmetic, not a price quote. I compare estimates with actual bills and use tags or cost categories to attribute spending. Cost Explorer helps analyze usage, while budgets and anomaly detection can signal unexpected growth. An ordinary budget alert is not a hard spending cap.
I reduce waste through rightsizing, idle-resource cleanup, retention policies, and scaling before buying commitments. Discounts are useful only when the eligible usage is sufficiently understood; they do not compensate for an inefficient design or guarantee future savings.
40. What do availability, backup, RTO, and RPO mean?
Availability describes whether a service can perform its intended function when needed. Backups preserve recoverable copies of data. Recovery time objective, or RTO, is the target time to restore the required service after disruption. Recovery point objective, or RPO, is the maximum tolerable age of the data recovered, often expressed as acceptable data loss in time.
For example, an RTO of one hour and an RPO of fifteen minutes mean the business targets restoring service within an hour using data no more than fifteen minutes behind the disruption. They are objectives, not guarantees created by writing them in a document.
Multi-AZ deployment can help with infrastructure availability, but it does not necessarily recover from accidental deletion, corrupt data, or a Region-level incident. I combine suitable backups or replication with a tested restoration procedure covering credentials, keys, configuration, dependencies, and routing. A successful backup job is incomplete evidence: I need to demonstrate that the data can be restored and the application can actually serve its required functions.
AWS Interview Questions and Answers for Intermediate
These answers explain implementation choices, configuration boundaries, and failure handling. Examples state their scope rather than implying that a small excerpt is a production-ready system.
41. How do you evaluate an IAM request across identity policies and guardrails?
I evaluate the actual principal, action, resource, and request conditions before combining policy results. An applicable explicit deny overrides an allow. For a typical same-account identity-policy grant, permissions boundaries, session policies, and applicable Organizations controls can narrow what the identity may do; none of those limiting policies independently grants access.
Resource-based grants require additional care. A grant to an IAM role ARN is not evaluated identically to a grant directly to an assumed-role session principal. I therefore avoid the oversimplification that every policy is always intersected. Cross-account requests also require authorization on both sides, and KMS key policies have service-specific rules.
For an access-denied investigation, I record the caller ARN, exact API, resource ARN, Region, and relevant condition values, then inspect the matching policy statements and organization controls. A policy simulator or Access Analyzer can help, but its result is evidence about the modeled request, not proof that every production dependency permits the operation. Network reachability and resource existence are separate checks.
42. How do you configure a cross-account role without confusing trust and permissions?
I configure two different authorizations: the destination role trusts an approved source principal to assume it, and the source principal is allowed to call sts:AssumeRole on that destination role. The destination role's permission policies then define what the resulting session can do. A trust policy alone does not grant S3 or database access.
This trust-policy excerpt names an illustrative source role rather than trusting every identity indiscriminately:
JSON example
The source role separately needs an allow on the destination role ARN; organizational controls and explicit denies still apply. For third-party access, I evaluate an external ID to mitigate the confused-deputy problem, but do not treat that ID as a password. I also constrain session duration and require appropriate session identity or tags for auditing. Example account IDs and role names must be replaced during an authorized implementation.
43. How do you write a least-privilege S3 read policy?
I separate bucket-level operations from object-level operations and scope each to the narrowest useful resource. s3:ListBucket uses a bucket ARN, while s3:GetObject uses object ARNs. A prefix condition can restrict listings, but it is not a substitute for restricting object resources.
For a role that reads only an illustrative reports prefix, the identity-policy excerpt is:
JSON example
This intentionally does not permit bucket-wide browsing or object writes. Requests listing a different prefix will not match this allow. Version-specific reads and SSE-KMS objects may require additional narrowly scoped permissions. I review bucket policies, endpoint policies, and organization controls as well; attaching this policy does not override an existing deny or establish cross-account access by itself.
44. How do KMS key policies interact with IAM permissions?
A KMS key policy controls access to a particular key and determines whether IAM policies can authorize its use. Merely adding kms:Decrypt to a role does not necessarily make that role able to decrypt with any key. The key policy must allow the relevant access directly or enable the appropriate IAM delegation; grants provide another controlled authorization mechanism.
I distinguish key administrators from key users. A deployment operator may manage selected configuration without receiving routine access to application plaintext. For an application using an encrypted S3 object, both S3 access and the applicable KMS permissions must succeed. Cross-account use generally needs permission in the key-owning account and an identity policy in the caller's account.
I also check encryption context and service constraints where supported, and investigate the actual key ARN rather than assuming an alias uniquely identifies equivalent permissions across Regions. Key policies are Regional. Rotation does not mean rewriting every existing ciphertext, and scheduling key deletion can make protected data unrecoverable after the waiting period. Key lifecycle decisions therefore belong in recovery planning.
45. How should an application retrieve and rotate database secrets?
I give the workload a role that can retrieve only the required secret, fetch it over an authenticated service connection, and cache it for a bounded interval rather than embedding credentials in source code or requesting them for every query. If a customer-managed KMS key protects the secret, the access path also needs the appropriate key authorization.
Rotation is a coordinated credential change, not just a timer. The rotation mechanism must update the target database and secret stages consistently, and the application must refresh cached credentials and recreate failed connections when necessary. I test the database engine's supported rotation strategy and the network path used by the rotation function or managed integration.
I keep secret values out of logs, exception messages, command history, and build artifacts. Monitoring should expose retrieval failures and rotation age without exposing the value. For a replicated secret, I verify Regional availability and recovery behavior explicitly instead of assuming immediate synchronization. A secret manager reduces credential-management risk; it does not remove the need for least privilege, secure transport, and application access control.
46. How do you diagnose a private subnet that cannot reach an external API?
I trace the connection from DNS resolution through the private subnet's route table, egress device, security controls, and return path. For a conventional IPv4 design using a public zonal NAT gateway, the private subnet needs a route for external destinations to that gateway. Its public subnet needs a route to an attached internet gateway, and the NAT gateway needs the appropriate public address configuration.
I then inspect security-group egress, stateless network ACL rules including return traffic, destination allowlists, and TLS or proxy errors. A successful DNS lookup does not prove that TCP or application authorization will succeed. Conversely, adding a public IP to an instance is not the normal fix for a private-subnet architecture.
For IPv6, an egress-only internet gateway or a DNS64/NAT64 design may be relevant; I do not copy an IPv4 route plan blindly. NAT deployment modes and supported Regions must be checked for the chosen architecture. Flow logs and targeted connectivity analysis help isolate the failing boundary, but I distinguish a reachability finding from an actual successful API request.
47. When should you use a gateway endpoint versus an interface endpoint?
I choose the endpoint type based on the service, traffic origin, and DNS and routing requirements. Gateway endpoints provide route-table-based private access to S3 or DynamoDB from supported VPC paths. Interface endpoints use private network interfaces and AWS PrivateLink for supported services; their security groups and DNS configuration become part of the connection path.
For example, a workload that only needs same-Region S3 access from a VPC may use a gateway endpoint rather than route that traffic through NAT. A workload that must reach a supported API through private interface addresses may need an interface endpoint instead. I verify the service's actual endpoint options, because S3 has more than one option and not every AWS service supports every endpoint type.
An endpoint policy limits access through that endpoint; it does not independently grant application permissions. I also check the workload's IAM policy, resource policy, endpoint security groups where applicable, and private DNS resolution. Endpoint placement, cross-AZ traffic, and endpoint charges belong in the design review rather than assuming private access is automatically free or universally reachable from connected networks.
48. How do you connect VPCs without assuming peering is transitive?
I treat VPC peering as a direct connection between two VPCs, not as a transit router. If VPC A peers with B and B peers with C, A does not automatically reach C through B. Each peering relationship needs compatible address ranges, routes on both sides, and security rules that allow the intended traffic.
For a small number of direct connections, peering can be simple. As the number of networks grows, I consider Transit Gateway or another explicitly designed routing architecture instead of building an unmanageable mesh. That choice introduces its own attachments, route tables, segmentation, capacity, and cost considerations; a transit hub is not an implicit allow-all security boundary.
I plan nonoverlapping CIDR ranges early and evaluate DNS resolution separately from packet routing. Overlapping networks may require a service-oriented PrivateLink pattern, address translation, or renumbering rather than ordinary peering. In troubleshooting, I inspect the most-specific routes and return path in each network. A connection marked active only establishes the peering relationship; it does not establish application reachability.
49. How do you select a useful EC2 Auto Scaling target-tracking metric?
I choose a metric that reflects demand per instance and changes predictably as capacity changes. Average CPU utilization works for a CPU-bound service, while ALB request count per target can fit evenly distributed requests of similar cost. A raw total queue length is usually less useful for target tracking than backlog per worker, because doubling healthy workers should reduce the per-worker load.
For example, if acceptable queue delay is 60 seconds and each worker processes one job in 3 seconds, an initial backlog target is about 20 jobs per worker. That is a starting estimate, not a guarantee: I validate processing-time variation, startup delay, and downstream limits under representative load.
I configure minimum and maximum capacity, instance warmup, and health-check behavior. A scaling policy cannot exceed a restrictive maximum, create unavailable capacity, or repair a saturated database automatically. I also watch whether the metric has missing data or changes meaning during failures. Scale-out should follow genuine demand; scale-in must preserve enough capacity to drain work safely.
50. How do ALB health checks and connection draining affect deployments?
An ALB health check determines whether a target should receive normal routed traffic; deregistration draining gives in-flight requests time to finish as a target leaves the group. I make the readiness endpoint test the application's ability to serve requests without performing a destructive or expensive operation on every probe.
The configuration must match the health-check protocol, port, path, expected status codes, and realistic startup time. Security groups must allow the load balancer to reach both the serving and health-check paths. A healthy process that cannot reach a critical dependency may still be unready, but making every dependency outage mark every target unhealthy can also amplify an incident. The health signal needs deliberate semantics.
During a rollout, I bring replacement capacity to readiness before retiring old targets and align deregistration delay with application shutdown and request deadlines. ALB health is distinct from EC2 Auto Scaling health configuration; I verify which checks can cause replacement. I also remember ALB's fail-open behavior when all registered targets are unhealthy, so a health check is not an authorization control.
51. How do you combine On-Demand, Spot, and commitment discounts?
I use On-Demand capacity for flexibility, Spot for workloads that tolerate interruption, and commitment discounts for a measured baseline of eligible usage. Savings Plans and Reserved Instances are billing commitments with different applicability; they are not interchangeable with purchasing a particular running server. A discount commitment does not universally guarantee capacity.
For a batch service, I might keep a small On-Demand base and use diversified Spot capacity for additional workers. Jobs need checkpointing or retry-safe execution, and the queue must tolerate workers disappearing. Diversifying instance types and Availability Zones improves options but does not guarantee uninterrupted Spot availability. For a critical scheduled event, I evaluate the appropriate capacity reservation separately.
Before committing, I analyze utilization, coverage, Region, operating system, tenancy, and expected architecture changes. Overcommitting to a disappearing workload can erase apparent savings. I compare the complete bill, including storage, licensing, networking, and idle resources, not only compute unit price. The final choice depends on current product terms and regional availability; I avoid quoting a universal discount percentage or assuming every Reserved Instance has identical capacity behavior.
52. How do you secure S3 access without relying on object ACLs?
For a modern general purpose bucket, I prefer Bucket owner enforced Object Ownership with ACLs disabled, then control access through IAM and bucket or access-point policies. This avoids a separate object-ACL ownership model and makes cross-account uploads easier to reason about. I verify existing settings rather than assume an older bucket has current defaults.
I enable the appropriate S3 Block Public Access controls and inspect both account-level and bucket-level protections. Those controls prevent specified public-access configurations; they do not replace least-privilege policies for authenticated identities. A policy allowing an entire organization, for example, may still expose more data than a particular application needs.
I require encrypted transport with a carefully scoped policy and verify service-to-service access requirements before adding broad denies. For delivery through CloudFront, I consider Origin Access Control and a restricted bucket policy rather than making the bucket public. Access Analyzer, inventory, and access logging or data-event auditing can help detect mistakes. Encryption at rest alone is not an access-control boundary, because an authorized read can still return plaintext.
53. How do SSE-S3, SSE-KMS, and client-side encryption differ?
SSE-S3 encrypts objects on the S3 side with S3-managed keys. SSE-KMS uses AWS KMS keys and adds KMS authorization and audit considerations. Client-side encryption encrypts data before it reaches S3, so the application must manage the client-side cryptographic design and access to decryption material.
For a general purpose bucket, I choose SSE-KMS when requirements call for explicit key policies, separation of key access, or KMS-level controls. I then consider key permissions, request volume, quotas, and cost rather than treating encryption as a checkbox. An S3 Bucket Key can reduce some KMS request traffic for supported SSE-KMS configurations, but it is not a replacement for a sound key policy.
Default bucket encryption applies to new writes; changing that setting does not automatically re-encrypt every existing object. I inspect object-level encryption when proving compliance. TLS remains necessary regardless of the at-rest choice. These mechanisms also do not imply that data is protected from every authorized application: server-side encryption normally decrypts during an authorized read, whereas client-side encryption changes where plaintext becomes available.
54. How do you make presigned S3 uploads safer?
I treat a presigned URL as a temporary bearer capability for a specific signed request, not as a user identity. Anyone who obtains it may use it while it remains valid and the signing credentials and policies permit access. It can be reused, so it is not inherently a one-time upload token.
For uploads, I authorize the user in my application first, generate a unique server-controlled object key, use a short expiry, and sign required headers such as supported checksum or content-type headers. Signed headers must match the request. Where strict form constraints such as content-length ranges are needed, I consider a presigned POST policy rather than assuming an ordinary PUT URL enforces them.
The signer must have permission for the operation, and temporary credential expiry can shorten the usable lifetime. I avoid logging the full URL and validate uploaded content before trusting or publishing it. An upload to an existing key can replace the current object, subject to versioning and other controls. A random key and application-level upload record help prevent unintended overwrites and bind the resulting object to the correct user.
55. How should a multipart upload handle failures and incomplete parts?
I initiate the multipart upload, upload numbered parts, retain each successful part's identifier and integrity metadata, and complete the upload with the ordered part list. A failed part can be retried without resending the entire object. Retrying the same part number replaces that part within the upload, so the client must maintain a consistent manifest.
The object is not a completed ordinary object merely because all parts were transmitted; completion is a separate step. I use supported checksums rather than assume a multipart ETag is the MD5 hash of the complete file. For an ambiguous completion response, I reconcile the result with the SDK's behavior and object metadata instead of blindly starting duplicate uploads.
Incomplete multipart uploads retain uploaded parts and can continue consuming storage. I abort abandoned uploads and configure a lifecycle rule to remove incomplete uploads after a suitable interval. Cleanup needs to account for in-flight part requests. Part sizing and concurrency must respect current service limits and client memory, bandwidth, and retry behavior. The example design assumes a general purpose bucket; specialized bucket types can impose different constraints.
56. What does S3 replication copy, and what must you configure explicitly?
S3 replication asynchronously copies eligible objects between configured buckets in the same Region or different Regions. I enable the required versioning, configure the replication role and destination permissions, and define which objects the rule selects. For SSE-KMS objects, I explicitly check replication configuration and source and destination key permissions.
Live replication applies to eligible new writes after the rule is configured; it does not automatically backfill every older object. Existing objects may need S3 Batch Replication. Delete-marker behavior, ownership, storage class, and replica modification handling also need deliberate configuration. I never describe replication as a perfect mirror of every possible deletion or metadata change.
I monitor replication status, failures, and lag, then test a restore or application read from the destination. Cross-Region replication does not automatically redirect clients, recreate IAM and application infrastructure, or guarantee zero data loss during a regional disruption. Retention or backup controls may be needed to protect against accidental or malicious changes. I select replication features against a stated recovery objective rather than assuming that having a second bucket completes the disaster-recovery plan.
57. How do you handle replication lag and read-after-write requirements with RDS read replicas?
I route freshness-sensitive reads to the writer and use read replicas for queries whose staleness tolerance is explicit. Conventional RDS read replicas use asynchronous replication, so a successful write on the primary does not guarantee that a subsequent replica read will immediately see it. Engine-specific metrics and replication status are part of the routing decision, not just whether the replica accepts connections.
For an order confirmation, I can keep that user's follow-up reads on the writer for the necessary workflow or use an engine-supported replication-position check before serving from a replica. An arbitrary sleep is not a correctness guarantee. For analytics, I can expose the data freshness watermark and pause or reroute jobs when lag exceeds the agreed threshold.
I investigate long transactions, write bursts, resource pressure, and replication errors when lag grows. Promotion behavior, supported monitoring metrics, and topology differ by engine; a Multi-AZ DB instance standby is not a general read replica, while a Multi-AZ DB cluster has readable instances. I state the engine and deployment type before promising any read consistency or failover behavior.
58. How do you manage database connections from Lambda with RDS Proxy?
RDS Proxy provides a managed connection pool between supported applications and databases, helping absorb bursts of short-lived client connections. For Lambda, that can prevent a sudden rise in execution environments from opening an uncontrolled number of database connections. It does not increase the database's intrinsic query capacity or make slow transactions disappear.
I verify the supported engine, version, Region, authentication mode, VPC connectivity, and security-group path. The application connects to the proxy endpoint and still needs bounded query deadlines and transaction handling. Connection reuse depends on session behavior: stateful operations can pin a client connection to a database connection and reduce multiplexing benefits.
I measure connection borrowing latency, active connections, transaction duration, and database CPU or I/O under realistic concurrency. A useful initial constraint is to cap Lambda concurrency against downstream capacity rather than relying on the proxy to queue infinite demand. Failover handling still requires safe retries because a connection can fail after a database operation has committed. I make write operations idempotent or reconcile their outcome before repeating them.
59. How do DynamoDB partition and sort keys support an access pattern?
I design DynamoDB keys from the application's access patterns, not by copying a relational schema mechanically. The partition key distributes items and identifies the group addressed by a Query; a sort key orders items within that partition-key value and can support range or prefix conditions.
For orders by customer, an illustrative design is:
Plain-text example
A Query can select PK = CUSTOMER#42 and a sort-key range for a time period. It cannot efficiently discover every customer's orders for that date without another access path. A Scan with a filter still reads data before filtering and is not a substitute for an appropriate key or index.
I estimate item size, access skew, write rate, and growth. A very active customer can create a hot key even when the table has plenty of aggregate capacity. Sharding can distribute that load, but makes reads and ordering more complicated. The right design balances predictable queries with distribution; single-table design is an option, not a universal requirement.
60. When should you choose a DynamoDB GSI or LSI?
A global secondary index supplies an alternative partition key and optional sort key, while a local secondary index shares the table's partition key and provides another sort key. I use a GSI for a different grouping, such as looking up orders by status, and an LSI when a same-partition alternate ordering fits the access pattern and its constraints.
GSIs are maintained asynchronously and support eventually consistent reads. LSIs can support strongly consistent reads, but must be defined when the table is created and impose an item-collection size constraint. I check current limits and the projected attributes rather than assume an index behaves like a relational index with no storage or write cost.
Projection determines which attributes are available directly from the index. A sparse GSI can be useful when only items carrying the index key attributes should appear. I also assess skew: a GSI whose partition key is simply OPEN can concentrate traffic. Adding an index improves a query only if its key distribution, capacity mode, projection, and freshness semantics fit the workload.
61. When do you request a strongly consistent DynamoDB read?
I request a strongly consistent read when the operation must observe previously successful writes to the item and the chosen resource supports that mode. DynamoDB tables and local secondary indexes support strongly consistent reads; global secondary indexes and streams do not. An eventually consistent read can be sufficient for a catalog or dashboard that tolerates brief staleness.
For an illustrative regional table with a string partition key OrderId, this read-only CLI example asks for the latest committed item:
Bash command
This is an example only, not a command executed against an account. A strongly consistent read does not lock the item against a subsequent write, nor does a multi-item Scan become a transactional snapshot. I use conditions or transactions when an invariant spans operations. For global tables, I explicitly distinguish multi-Region eventual consistency from multi-Region strong consistency and check the selected mode's supported Regions and constraints instead of assuming every global table has identical guarantees.
62. How do conditional writes prevent lost updates in DynamoDB?
A conditional write checks a predicate against the item as part of the write, so competing clients cannot both succeed based on the same expected version. I use this optimistic-concurrency pattern when a read-modify-write operation must reject stale updates rather than silently overwrite another client's change.
This Python SDK excerpt assumes an existing DynamoDB Table resource and an item with numeric version and balance attributes:
Python example
If another writer has already changed version 7, the condition fails. The application must reload and reconsider the business operation; blindly retrying the same stale value is not conflict resolution. For an increment, an atomic update expression may be simpler, but an increment is not automatically idempotent after an ambiguous network failure. Every writer must follow the version protocol, and cross-Region behavior must match the table's configured consistency model.
63. When should you use DynamoDB transactions rather than batch operations?
I use a DynamoDB transaction when several item changes must succeed or fail together, such as reserving inventory and creating an order record. TransactWriteItems can combine supported writes and condition checks across eligible tables in one account and Region. TransactGetItems provides a coordinated transactional read of specified items.
Batch operations are different. BatchWriteItem improves throughput for independent puts and deletes, but the batch is not one atomic transaction and can return unprocessed items. I retry those unprocessed items with bounded backoff rather than resubmitting an entire business workflow indiscriminately. Batch write does not provide conditional update semantics.
A transaction still has documented item-count and size limits, contention behavior, and additional capacity consumption. I avoid relying on a transaction as a distributed transaction with an external payment service or a second Region. For retryable writes, I use the transaction's client request token where applicable and understand its bounded idempotency window. Downstream stream or index observations also need their own semantics; consumers should not infer that all changed items will arrive together as a single application event.
64. How do reserved and provisioned Lambda concurrency differ?
For standard on-demand Lambda Event Functions, not Lambda Managed Instances, reserved concurrency allocates a function a portion of the account's concurrency and caps that function's concurrent executions. It is useful both for protecting a critical function from other workloads and for protecting a downstream system from excessive fan-out. It does not preinitialize execution environments.
Provisioned concurrency prepares execution environments for a published version or alias to reduce initialization latency for traffic within that configured capacity. It has separate cost implications and does not make every possible invocation latency-free. Traffic above provisioned capacity may use on-demand capacity if other limits allow it; reserved concurrency can constrain the total.
As a first estimate, concurrency is request rate multiplied by average execution duration. At 200 requests per second and 0.25 seconds average duration, the average is about 50 concurrent executions. I provision headroom based on bursts and tail latency, not just that average. I also inspect regional account quotas, scaling behavior, and event-source limits. These controls should not be generalized unchanged to Lambda Managed Instances, Lambda Web Functions, or other compute primitives.
65. How do you configure Lambda asynchronous failure handling with event age, retries, and destinations?
For an asynchronously invoked Lambda Event Function, I configure how long an event may remain queued, how many retries occur for function errors, and where a final invocation record should go. Maximum event age and maximum retry attempts solve different problems: one bounds stale work, while the other limits repeated handler failures. Throttling and service errors have their own retry behavior within the asynchronous processing system.
An illustrative CloudFormation property fragment is:
YAML example
This fragment assumes an existing function and alias and deliberately omits a destination configuration; it is not a complete recoverable deployment. In production, I add an appropriate failure destination with permissions, alarm on delivery failures, and define a controlled replay procedure. A destination receives an invocation record rather than simply being identical to every event-source DLQ. SQS event-source mappings use their queue-processing model, not these asynchronous retry settings. Duplicate processing remains possible, so the handler still needs idempotency.
66. How do partial batch responses improve Lambda processing of SQS messages?
Partial batch responses let a Lambda Event Function report which SQS records failed instead of making successfully processed records retry with the entire batch. I enable ReportBatchItemFailures on the event-source mapping and return the failed records' message IDs in the required response shape.
For a standard queue, a simplified handler sketch is:
Python example
The omitted processing function must durably record successful work and provide safe duplicate handling. If the handler instead raises an uncaught exception, Lambda treats the whole batch as failed. For a FIFO queue, I stop after the first failure and include failed and unprocessed records as required to preserve ordering, rather than continuing with this standard-queue sketch. Partial responses reduce unnecessary retries; they do not make delivery exactly once. Visibility timeout, queue redrive policy, and concurrency must still fit processing behavior.
67. How do you choose an SQS visibility timeout and deletion strategy?
I set the visibility timeout long enough for normal processing and acknowledgement, while keeping failure recovery acceptably fast. Receiving a message hides it temporarily; it does not remove it. After the business operation completes durably, the consumer deletes the message using the receipt handle for that receive attempt.
For variable-duration work, I extend visibility with bounded heartbeats while the consumer remains healthy. A timeout that is too short can let another consumer receive work that is still running; an excessively long timeout delays recovery after a crash. Standard queues still require duplicate-safe processing, even when visibility is configured correctly.
For Lambda's SQS integration, I follow the integration-specific visibility recommendation based on function timeout and batching window rather than apply a generic worker formula. I monitor age of the oldest message, in-flight count, processing latency, and delete failures. The dangerous boundary is a consumer that commits a payment and crashes before deletion: the next delivery must recognize the completed operation instead of charging again. A message ID alone is not always the right business idempotency key.
68. How do you configure and operate an SQS dead-letter queue?
I configure a redrive policy on the source queue with a dead-letter queue and a receive-count threshold that allows realistic transient recovery without retrying poison messages indefinitely. I also restrict which source queues can use the DLQ and choose compatible queue types, retention, account, and Region settings.
A DLQ is an operational workflow, not a success state. I alarm when messages arrive, preserve enough context to diagnose the failure, fix the consumer or data, and redrive at a controlled rate. Replaying the entire DLQ immediately into an unchanged failure can create another incident. Sensitive payloads need the same access and retention controls as the source queue.
Retention semantics differ between standard and FIFO queues: for standard queues, the original enqueue time remains relevant to expiration after movement to a DLQ. I therefore choose a sufficiently long DLQ retention period. With FIFO, removing a failed message to a DLQ can break the business sequence, so some workflows must halt or quarantine a group instead. I decide that behavior from the ordering requirement rather than enabling a DLQ mechanically.
69. What guarantees does an SQS FIFO queue actually provide?
An SQS FIFO queue preserves order within a message group and provides producer deduplication within its documented deduplication interval. It does not impose one global order across independent groups, and it does not atomically commit a consumer's external side effect together with deleting the message.
I use a stable message-group ID for the business entity whose operations must remain ordered, such as an account. A deduplication ID identifies one logical send, not an entire account forever. With content-based deduplication, the body participates in the hash but message attributes do not, which matters if the application puts its distinguishing fields only in attributes.
If a consumer updates a database and crashes before acknowledging, the same message can become visible again. The consumer still needs an idempotent update or a durable processed-operation record. Retrying a send outside the deduplication interval can also enqueue another copy. Many groups allow concurrency; one very busy group can serialize work. I evaluate the queue's selected throughput mode and current quotas instead of claiming FIFO is either universally slow or an end-to-end exactly-once transaction system.
70. How do EventBridge event patterns, retries, and dead-letter queues work together?
An EventBridge rule matches an event pattern and routes matching events to configured targets. I make patterns specific enough to avoid accidental fan-out, validate them against representative events, and distinguish a matching failure from a target-delivery failure. An event that does not match the rule is not a failed delivery to that rule's target.
For retryable delivery errors, the target's retry policy controls the attempt count and event age. I configure an appropriate SQS dead-letter queue for events that cannot be delivered and grant the required permissions. Some nonretryable failures can go directly to the DLQ, so I inspect its error metadata rather than assuming every failed event exhausted the same retry schedule.
A successful handoff to an asynchronous target does not prove the target completed its business work. For example, Lambda can accept an asynchronous invocation and later fail during handler execution; its own failure handling then matters. I monitor both layers and make consumers duplicate-safe. Event buses, Pipes, and Scheduler have distinct settings, so this answer specifically describes event-bus rules and their targets.
71. How do EKS workloads obtain AWS permissions without sharing node credentials?
I assign an IAM role to the workload's Kubernetes service account through a supported mechanism such as EKS Pod Identity or IAM roles for service accounts, rather than distribute long-lived keys or let every pod inherit a broad node role. The role's permissions should match that workload's required AWS operations.
EKS Pod Identity associates a role with a cluster, namespace, and service account, and requires the supported Pod Identity agent and compatible SDK credential chain. IRSA instead uses the cluster's OIDC identity provider and a role trust policy tied to the service account token. Their setup, supported compute environments, and cross-account patterns differ, so I select one against the actual EKS cluster and node or Fargate configuration.
I restrict access to instance metadata where appropriate and review Kubernetes RBAC: someone able to launch a pod using a privileged service account may gain that role's permissions. Workload identity is not a hard isolation boundary between hostile containers sharing a kernel. I test which principal the SDK actually resolves, inspect audit events, and keep the node role limited to node responsibilities.
72. How do ECS task roles differ from task execution roles?
The ECS task role grants AWS permissions to application code inside the task. The task execution role grants permissions used by ECS or its agent for supported startup and infrastructure operations, such as pulling an image from ECR, publishing logs, or retrieving configured secrets. Giving a permission to the execution role does not automatically make it available to the application's SDK.
For example, a worker that writes to an S3 prefix needs that permission in its task role. If its task definition injects a secret at startup, the execution role needs the relevant retrieval and key permissions for that integration. If the application retrieves the secret itself at runtime, the task role is the relevant identity instead.
I scope both roles independently and avoid a shared administrator role for every service. On EC2-backed ECS, I also constrain the instance role and metadata access so application containers do not bypass the task identity design. Fargate changes infrastructure management, but does not remove the need for a task role, secure images, resource limits, network controls, and application authorization.
73. How do you design health checks and rollout controls for a container service?
I separate startup, readiness, and ongoing health signals so that a slow-starting container is not repeatedly killed and an unready container does not receive traffic. For an ECS service behind an ALB, container health and target-group health can both influence deployment progress, and their grace periods and thresholds must fit the application.
I deploy an immutable image reference, provide enough spare capacity for the configured minimum and maximum healthy percentages, and enable an appropriate deployment failure-detection and rollback mechanism. For ECS rolling deployments, the deployment circuit breaker can detect a failure to reach steady state, but its availability and behavior depend on the deployment controller. I verify the selected strategy rather than mix settings from unrelated deployment types.
The container must handle termination by stopping new work and completing or safely releasing existing work within its shutdown budget. A rollback also cannot undo an incompatible database migration automatically. I use backward-compatible schema changes, monitor error rate and latency during rollout, and keep a known-good revision. A container that merely starts successfully has not demonstrated application correctness.
74. How do CloudFormation change sets reduce deployment risk?
A CloudFormation change set previews the proposed resource changes before I execute a stack update. I review additions, modifications, removals, and replacement indications, especially for stateful resources. Creating a change set does not itself apply the planned stack changes; execution is a separate authorized action.
For a database or bucket, I inspect both deletion and replacement behavior. This resource excerpt illustrates explicit retention, not a complete secure bucket configuration:
YAML example
DeletionPolicy and UpdateReplacePolicy address different lifecycle paths, and retaining a resource can leave an orphan that still incurs cost. I also review IAM changes, parameters, capabilities, and generated changes from transforms or nested stacks.
A preview is not a guarantee that deployment will succeed or that the application will remain compatible. Runtime permissions, quotas, dependencies, and service validation can still fail, while some values are resolved only during execution. I combine change-set review with template validation, policy checks, backups, and a rollback or recovery plan. In an interview, I explain the risky replacement and its data-migration strategy rather than simply say that infrastructure as code makes every change safe.
75. What can CloudFormation drift detection prove and not prove?
CloudFormation drift detection compares supported resource properties with the values expected from the stack template and parameters. It helps reveal out-of-band changes, such as someone manually changing a configured resource property. I inspect resource-level differences rather than treat a single stack status as a complete compliance report.
Coverage is limited to supported resources and properties that CloudFormation can compare. Properties not explicitly set in the template can be outside the useful comparison, and some values cannot be returned for inspection. Nested stacks may require their own drift operation. A result of IN_SYNC therefore does not prove that application data, runtime behavior, every secret, or all security controls are correct.
When I find drift, I decide whether the intended state should win or whether the legitimate operational change should be incorporated into code. I do not immediately overwrite a production fix without understanding why it happened. The longer-term remedy is a controlled change path and clear ownership. Drift detection is evidence about infrastructure configuration, not a backup mechanism or a replacement for security monitoring.
76. How do you deploy Lambda versions safely with aliases?
I publish an immutable Lambda Event Function version and make clients or triggers use an alias, so a deployment can change the alias target without relying on mutable $LATEST. A weighted alias can send a fraction of invocations to a second version for a canary rollout, subject to the feature's compatibility constraints.
I monitor errors, duration, throttling, and business outcomes for each executed version rather than only aggregate function metrics. With low traffic, actual routing proportions can differ noticeably from the configured weight, so a brief canary with no observed failures is weak evidence. If provisioned concurrency is involved, I account for both versions and possible spillover during the rollout.
An automated deployment system can shift traffic and roll back on alarms, but rollback only changes code routing. It cannot automatically reverse an incompatible data write or external side effect. I therefore use backward-compatible event and schema changes, idempotent handlers, and a recovery plan. Alias routing also has specific requirements for execution roles and dead-letter queue configuration; I validate them before planning a weighted deployment.
77. How do you combine metrics, logs, traces, and audit events during debugging?
I use metrics to detect and scope the symptom, logs to inspect individual events, traces to locate latency or failure across service boundaries, and audit events to investigate control-plane or selected data-access changes. These signals answer different questions and are most useful when they share request, trace, deployment, and tenant identifiers without leaking sensitive data.
For a sudden rise in API latency, I first compare traffic, error rate, and latency distributions. I then inspect traces for a slow downstream call and correlate relevant application logs. If the timing coincides with a permission or network change, CloudTrail can provide evidence of the API action when the relevant event category is recorded.
Sampling, retention, log permissions, missing instrumentation, and asynchronous boundaries all affect what I can conclude. The absence of a trace or audit record is not proof that nothing happened. I instrument retry attempts separately from logical requests so retry amplification is visible. Finally, I verify the proposed fix against the same user-facing indicator that triggered the investigation, not merely against a newly quiet log stream.
78. How do you make CloudWatch alarms actionable rather than noisy?
I create alarms around an actionable condition with a known owner and response, preferably tied to user impact. A threshold on error rate or queue age is often more useful than a generic CPU alarm if the service can tolerate high CPU without harming users. I specify the metric dimensions, statistic, period, evaluation window, and missing-data behavior explicitly.
For example, an M-out-of-N evaluation can require several breaching periods while tolerating a short isolated spike. That reduces noise but also changes detection time. Percentile latency alarms need enough samples to be meaningful, and a missing metric may mean either healthy inactivity or failed telemetry depending on the workload.
I use composite alarms when combining meaningful conditions reduces duplicate pages, not to hide an unresolved symptom. Each page should include a dashboard, runbook, recent deployment context, and escalation path. I test the alarm and notification route safely, then review false positives and missed incidents. An alarm action can change resources, so automation requires tighter safeguards than a notification-only alert.
79. How do you build useful AWS cost allocation and budget controls?
I establish a consistent allocation model using accounts, activated cost-allocation tags, and cost categories where useful. Tags such as owner, application, environment, and cost center help attribute spend, but I verify coverage and activation rather than assume every resource or historical charge is automatically labeled.
I then use cost and usage reporting to separate recurring baseline, growth, idle capacity, and anomalies. A unit measure such as cost per thousand successful jobs is more informative than a lower total bill caused by dropped work. Shared costs, credits, commitments, and data transfer need an explicit allocation rule so teams compare like with like.
AWS Budgets provides tracking and notifications, and supported budget actions can automate selected responses. A budget is not a real-time universal spending cap: billing data and evaluations have latency, and stopping one resource may not stop every related charge. I configure alerts early enough to act and require careful authorization for disruptive actions. Before buying commitments, I first right-size and remove waste, then evaluate stable eligible usage against current terms.
80. How do you test a backup restore instead of merely checking that backups exist?
I restore a selected recovery point into an isolated, authorized test environment and validate that the restored application data is usable. A successful backup job proves that a backup operation completed; it does not prove that the application can recover within its recovery time objective or that the chosen point satisfies the recovery point objective.
The test records the recovery point's timestamp, restore start and finish, dependency restoration, application validation, and cleanup. I verify access to encryption keys, network configuration, permissions, schema compatibility, and representative business records. For databases, a simple connection is insufficient if essential tables are missing or application-level invariants fail.
AWS Backup restore testing can automate supported restore workflows, but resource coverage and custom validation requirements must be checked. I prevent the test environment from sending real emails, processing payments, or consuming production queues. Restores may incur resource and storage charges, so they require an approved scope and cleanup plan. No restore is executed for this article; the interview answer describes the evidence a real authorized recovery test should produce.
AWS Interview Questions and Answers for Experienced
These answers focus on explicit requirements, failure modes, measurable outcomes, and the limits of service guarantees. Architecture decisions remain workload-specific.
81. How would you choose a disaster-recovery strategy from RTO and RPO requirements?
I start with the business's maximum tolerable outage and data loss, then choose a recovery design that can meet both under test. RTO is the recovery-time objective; RPO describes how far back the recoverable data may be. Neither is a guarantee obtained merely by selecting an AWS service.
For an illustrative reporting workload that tolerates four hours of outage and one hour of lost changes, tested backups and automated restoration may be reasonable. A checkout service with a five-minute RTO needs much more preprovisioned recovery capacity, current application configuration, and a deliberately designed data-replication strategy. Asynchronous replication cannot establish zero data loss simply because its normal lag is small.
I compare backup-and-restore, pilot light, warm standby, and active-active against operating cost, operational complexity, consistency, and recovery dependencies. The recovery plan includes identity, secrets, keys, DNS, images, quotas, and external providers—not only the database. I measure from the user-visible incident through restored business service, rehearse restoration with representative data, and document where observed results fall short of the objective.
82. How would you prove that a multi-AZ application can survive an Availability Zone failure?
I test the entire request path under the loss of one Availability Zone, not just whether instances exist in two zones. That includes ingress, application capacity, data access, outbound connectivity, DNS dependencies, and deployment tooling. A regional service may handle its own zonal redundancy while my application still has a single-zone dependency.
Suppose traffic needs 600 requests per second and three zones each safely support 300. Losing one zone leaves 600 of capacity, with no spare headroom. If retries or load redistribution increase demand, the nominal design may already be inadequate. I load-test the surviving capacity and account for scaling delays rather than assuming new instances appear immediately.
For EC2-backed applications I check target-group health, distribution across zones, scaling configuration, connection draining, and whether clients reconnect after a database failover. For zonal NAT gateways I inspect the actual routes from surviving subnets. I use a separately authorized, bounded fault exercise with explicit abort criteria and compare latency, errors, and data correctness before and during the fault. Multi-AZ deployment is a starting architecture, not proof of workload availability.
83. How would you fail over a workload to another Region without creating split-brain writes?
I separate traffic routing from write ownership. Redirecting DNS or a front door to another Region does not stop the original Region from accepting writes, and asynchronous database replicas may not contain every acknowledged update. The failover procedure must explicitly address those two risks.
For a single-writer relational design, I establish a trusted decision process, stop or fence the old writer where possible, evaluate replication progress, and promote the recovery database using the chosen engine's supported procedure. If I cannot establish safe ownership, I may temporarily reject writes rather than silently create divergent histories. Reads can sometimes remain available under a clearly defined staleness policy.
The application in the recovery Region also needs working keys, secrets, queues, capacity, and downstream integrations. I validate a real business transaction before shifting the full load and monitor duplicates, missing events, and reconciliation work. DNS caches and long-lived connections make routing changes noninstantaneous. For active-active databases I instead use the service's explicit consistency and conflict model; the phrase multi-Region does not by itself solve split-brain behavior.
84. What must a safe regional failback plan include?
Failback is a second controlled migration, not a reversal of a DNS change. I first decide which data history is authoritative after failover, repair or rebuild the original environment, and synchronize it from the active recovery environment using the database's supported mechanism. Bringing an old primary online with stale writable data is unsafe.
I compare infrastructure, application releases, configuration, certificates, access policies, and quotas in both Regions. Then I verify replication health and data reconciliation, rehearse the transition, and choose a window with a clear decision owner. For a single-writer application, a short write pause or another fencing mechanism may be necessary to establish an unambiguous handoff.
My runbook defines validation transactions, routing steps, connection recycling, rollback boundaries, and monitoring after the switch. If new writes occur in the restored Region, returning to the recovery Region requires another data-consistency decision; it is not automatically safe. I keep the recovery environment available until the observation criteria are satisfied. Successful failover proves only half of the recovery lifecycle; failback must be independently demonstrated.
85. How would you make a payment API idempotent when clients retry after a timeout?
I require a stable operation identifier and make repeated submissions return the same business result rather than create another charge. The identifier is scoped to the authenticated customer and operation, and I bind it to a hash of the important request fields so that reusing the key with a different amount is rejected.
For a payment provider, I propagate an idempotency key supported by that provider and persist our operation state. A local deduplication record alone cannot atomically cover a remote card charge. If the charge succeeds and the response is lost, recovery must query or retry using the same provider key, not generate a new payment.
Pseudocode example
This is a protocol sketch, not an atomic implementation. Concurrent claims need a conditional write or transaction, and in-progress records need bounded recovery rather than permanent lockout. I test crashes before and after the external side effect, duplicate deliveries, and key expiry. Idempotency retention must cover the business's retry and replay window.
86. How does the transactional outbox pattern prevent a database-and-message dual-write failure?
I write the business change and an outbox record in the same database transaction, then publish the outbox record asynchronously. That eliminates the gap where an order commits but its notification is never recorded for delivery. It does not make the database and message broker one atomic system.
For an RDS-backed order service, the transaction might insert an order and an event containing a unique event ID. A relay reads committed outbox rows, sends them to SQS or EventBridge, and records publication progress. If the relay crashes after sending but before marking the row, it may publish the event again. Consumers therefore deduplicate by event ID and apply their own state change atomically with the deduplication decision when possible.
SQL example
The excerpt assumes compatible tables already exist. A real design also addresses relay ownership, ordering requirements, payload evolution, retention, and monitoring of the oldest unpublished event. I never describe the pattern as exactly-once delivery across arbitrary external systems.
87. When would you use a saga instead of a distributed database transaction?
I use a saga when a business workflow spans services that cannot share a practical ACID transaction. Each service commits a local transaction, and a coordinator or event-driven process advances the workflow. Failures trigger compensating business actions rather than a magical rollback of every external effect.
For an order workflow, inventory reservation may precede payment authorization and shipment scheduling. If payment fails, releasing the reservation is a compensation. If a shipment already left the warehouse, cancellation may no longer be possible; the correct action might be a return or a manual exception. Those semantics belong in the design before choosing orchestration tooling such as AWS Step Functions.
I persist workflow state, use stable operation identifiers, and make both forward actions and compensations safe to retry. Timeouts distinguish an operation known to have failed from an operation whose result is unknown. The latter requires reconciliation. I also define human escalation for stuck workflows and monitor age, not just execution counts. A saga trades immediate cross-service isolation for recoverable coordination; concurrent workflows can still observe intermediate states unless the application deliberately prevents that.
88. How would you contain a retry storm during a dependency outage?
I cap work before adding retries. During a dependency outage, unbounded retries multiply demand precisely when the dependency has the least capacity. I set connection and request deadlines, classify retryable errors, use bounded exponential backoff with jitter, and ensure one layer owns the retry policy where possible.
For example, if three nested layers each make four attempts, one user operation can cause 64 downstream attempts. I instead give the operation a shared deadline and retry budget. A circuit breaker or admission control can stop predictable failures, while a queue absorbs only a bounded amount of recoverable work. Nonidempotent operations require an idempotency protocol before retrying.
Python example
This pure delay function does not perform requests; callers must enforce attempt and elapsed-time limits. I monitor retry volume separately from original requests, shed optional work, and gradually restore traffic. Backoff reduces synchronization; it does not repair a permanent authorization error, invalid request, or exhausted business resource.
89. How would you diagnose and drain an SQS backlog safely?
I compare arrival rate, successful completion rate, age of the oldest message, in-flight messages, retries, and downstream health. Queue depth alone cannot tell me whether the system is healthy: a large stable batch backlog differs from a small backlog containing one critical message that is repeatedly failing.
Suppose 600 messages arrive each second and workers successfully complete 900. A backlog of 180,000 messages would take about 600 seconds to drain if those rates remain constant: backlog divided by the net drain rate of 300 per second. Increasing concurrency helps only if the database or external service can tolerate it.
For Lambda Event Function consumers I inspect the SQS event source mapping, concurrency limits, batch handling, visibility timeout, and dead-letter redrive policy. Partial batch responses can avoid replaying successful records when another record fails, but handlers must still be idempotent. I separate poison messages from transient failures and investigate before redriving them. FIFO queues also depend on available message groups; one blocked group cannot be fixed merely by adding workers. I ramp recovery traffic while observing downstream latency instead of emptying the queue at any cost.
90. How would you process ordered business events without claiming exactly-once side effects?
I define the scope of ordering first—usually an account, order, or aggregate rather than the entire business. With SQS FIFO, a message group provides an ordered processing boundary; using one group for everything can unnecessarily serialize the workload. Producer deduplication and queue ordering do not make a downstream payment or email exactly once.
My consumer records event IDs and expected aggregate versions alongside the business update. If event version 12 arrives when the stored version is 10, I handle the gap explicitly rather than silently apply it. Whether to wait, fetch authoritative state, or reject depends on the workflow. Replays should preserve the original business identifiers.
Pseudocode example
An external side effect still needs its own idempotency contract or outbox. A crash after commit but before acknowledgement can cause reprocessing, so that path is expected, not exceptional. I describe guarantees at each boundary and test duplicate, delayed, and out-of-order inputs.
91. How would you fix a hot partition in DynamoDB?
I inspect the access pattern and throttling dimensions before increasing table capacity. A single popular partition key or item can remain a bottleneck even when the table has spare aggregate capacity. Adaptive capacity helps uneven workloads, but it is not a substitute for a key design that distributes the required traffic.
For a write-heavy event stream keyed only by a large customer's ID, I might add a deterministic shard suffix based on event ID. Writes then spread across several logical keys. The trade-off is that reading all recent customer events now requires querying and merging those shards. I choose the shard count from measured traffic and operational requirements, not an arbitrary maximum.
I separately inspect global secondary indexes: a well-distributed base table can still have a hot index key such as a shared status value. Caching can help repeated reads, but it introduces invalidation and staleness decisions. For a single mutable inventory item, random sharding is not automatically correct because updates must preserve the business invariant. I load-test representative skew, measure throttling and latency by operation, and migrate key layouts with explicit compatibility and backfill plans.
92. How would you choose between MREC and MRSC DynamoDB global tables?
I choose the global-table consistency mode from the business invariant, acceptable latency, and supported deployment topology. MREC asynchronously replicates writes across Regions; a strong read in one Region does not promise to include a write that has not yet replicated from another. Applications must account for replication delay and concurrent-update conflict behavior.
MRSC provides strongly consistent reads across participating replicas and synchronously replicates an item write to another participating Region before success. That changes latency and availability trade-offs and does not provide arbitrary cross-item transactions. I verify current Region support and feature limitations rather than reuse an old list of allowed Region sets; supported configurations have evolved.
For a globally replicated product description, MREC may be adequate. For an entitlement that must not be granted twice from concurrent regional requests, global strong conditional updates may be important, provided the invariant fits the supported item model. I test failover, conflicting writes, and loss of quorum, and distinguish eventual reads from explicitly strong reads. The consistency mode is a table-level design choice, not a client-side switch that converts an existing MREC deployment into MRSC.
93. How would you prevent overselling inventory across Regions?
I put the inventory invariant behind a coordination mechanism that is actually strong enough for the business. Two Regions independently reading stock of one and both decrementing it can oversell even if replication eventually converges. A regional conditional write on an MREC replica does not by itself create a global uniqueness guarantee.
One option is a single authoritative writer for each SKU or inventory partition, accepting cross-Region latency and a controlled ownership-transfer procedure. Another is allocating nonoverlapping regional inventory quotas, so each Region can sell only its assigned units. Rebalancing those quotas becomes a coordinated workflow. Where supported and appropriate, MRSC conditional updates can enforce a single-item stock invariant across replicas, but cross-item order-and-stock transactions require separate consideration.
For a reservation system I also model expiration, payment failure, cancellations, and duplicate requests. A retry must reuse the same reservation ID instead of decrementing stock again. I test concurrent regional requests and failover during reservation finalization. Choosing DynamoDB global tables is only a storage decision; preventing overselling depends on the write protocol, consistency mode, and boundaries of the invariant.
94. How would you diagnose an RDS failover that leaves the application unavailable?
I distinguish database recovery from application recovery. RDS can complete a supported Multi-AZ failover while the application continues using stale DNS results, broken pooled connections, or an exhausted retry loop. I first confirm the deployment type and engine because a Multi-AZ DB instance, a Multi-AZ DB cluster, and Aurora have different details.
For a Multi-AZ DB cluster, I compare RDS events with application connection errors and verify that clients use the documented endpoint rather than a pinned IP address. Existing connections may need to be discarded and re-established. I inspect DNS caching, pool validation, connection timeouts, and retry backoff. Aggressively reconnecting every worker at once can create a connection storm.
I then check whether the new writer is overloaded by cold caches, long transactions, lock contention, or replayed application work. A failover does not automatically cure a bad query or excessive connections. Recovery validation includes a new transaction and safe resolution of operations whose commit result is unknown. I report measured user-visible recovery time rather than quote a generic failover duration as an SLA.
95. How would you handle an ambiguous database commit after a network timeout?
I treat a timeout after sending COMMIT as an unknown outcome, not proof that the transaction rolled back. The database may have committed successfully before the network response was lost. Blindly replaying a money transfer or order creation could therefore duplicate the business action.
I give the operation a durable unique business identifier and enforce uniqueness in the same database transaction as its effects. After reconnecting, the application queries the authoritative database for that identifier. If the transaction already committed, it returns the stored result. If it definitely did not, it can retry under the same identifier and let the uniqueness rule resolve concurrent attempts.
For example, payment_request_id might be a unique column on a payment ledger entry, with the resulting account changes in the same transaction. A replica that is allowed to lag is not a reliable place to decide that the operation never happened. If the transaction spans an external payment provider, database uniqueness alone is insufficient; the provider needs an idempotency or reconciliation contract too. I explicitly test dropped responses after commit and verify that recovery preserves the ledger invariant.
96. How would you design S3-based recovery against accidental deletion and ransomware?
I combine recoverable versions, protected backups, constrained administration, and tested restoration. S3 Versioning can preserve earlier object versions, but a principal with sufficient permission can permanently delete versions. Replication is also not automatically an immutable backup, and I inspect which changes and deletions the configured replication rules propagate.
For important data, I separate backup administration from application administration and evaluate S3 Object Lock or another appropriate immutable backup mechanism. I restrict destructive permissions, protect the encryption keys, and monitor unusual deletion, policy, and retention changes. Access to the backup account must not depend solely on credentials likely to be compromised with production.
My recovery drill starts with an application-level corruption scenario: identify the last trustworthy versions, restore a consistent set, validate checksums and business relationships, and reconnect the application. Restoring individual files is insufficient when a dataset requires a coordinated snapshot. I also account for storage-class retrieval requirements, recovery throughput, and the availability of key material. The design must meet a measured recovery objective; having an S3 bucket named backup does not establish either immutability or recoverability.
97. How would you select and validate S3 Object Lock retention controls?
I select retention mode according to the required protection and the consequences of an irreversible mistake. S3 Object Lock applies to object versions and requires versioning. Governance mode allows specifically authorized bypass; compliance mode prevents deletion or shortening of the protected retention period, including by the account root user, until that period expires.
I do not treat a legal hold as a fixed-duration retention rule. A legal hold remains until an authorized action removes it, and it is independent of the retention date. Bucket defaults help apply policy to new objects, but I verify the actual version metadata instead of assuming every historical object has the intended protection.
Before applying controls, I test with nonproduction data, validate who can change defaults or bypass governance, and confirm how replication and lifecycle rules interact with protected versions. I also protect KMS keys: retaining ciphertext does not help if the required decryption key is permanently lost. Retention decisions need the organization's records and compliance owners. This is an architectural explanation, not legal advice or a recommendation to apply irreversible compliance retention without approval.
98. How would you structure organization-wide guardrails without confusing them with permissions?
I use account and organizational-unit boundaries to limit blast radius, then apply tested guardrails for the risks each environment presents. Service control policies limit permissions available to principals in member accounts; they do not grant the permissions an application needs. The organization's management account is not constrained by SCPs in the same way, so I keep ordinary workloads out of it.
For example, an SCP can prevent unapproved destructive operations while workload IAM roles still grant narrowly scoped application access. I separate organization administration, security logging, production, and development ownership, and use delegated administration where supported. Resource access also requires evaluating resource policies and other applicable controls; an SCP is not a universal firewall around every external principal.
I test a proposed restriction in a small representative organizational unit, inspect service dependencies, and preserve a controlled recovery path. Region restrictions need special care for global services and cross-Region dependencies. I version the policies, record why exceptions exist, and monitor changes. A broad deny may reduce one risk while breaking backup, incident response, or deployment, so successful guardrails are both restrictive and operationally validated.
99. How would you respond to suspected compromise of an AWS workload role?
I contain access while preserving evidence and maintaining a trusted incident-response path. I identify the role, session identifiers, source workload, affected accounts, and observed actions through available CloudTrail records and application telemetry. I do not assume that replacing a long-lived access key solves compromise of temporary role credentials.
Containment may include isolating the workload, preventing new role assumptions, and applying supported session-revocation or deny controls for existing sessions. Each action must be selected and authorized for the incident because blocking a production role can itself cause an outage. I preserve relevant logs and snapshots according to the incident process rather than immediately deleting the compromised instance.
I investigate privilege escalation, newly created credentials, changed resource policies, data access, and persistence mechanisms. Then I rebuild from trusted artifacts, rotate exposed secrets, repair the entry point, and validate least privilege before restoring service. CloudTrail event availability depends on the configured event types and retention, so missing events are not proof that no access occurred. The final result is a scoped timeline and evidence-backed recovery decision, not merely a green health check.
100. How would you design cross-account access for a third-party service?
I provide a dedicated assumable role with minimal permissions rather than sharing an IAM user's long-lived keys. The trust policy identifies the approved third-party principal and requires a provider-managed external ID when appropriate to prevent the confused-deputy problem. The external ID is an association mechanism, not a password that replaces principal validation.
JSON example
This illustrative trust policy uses a fictional account and role. The vendor also needs permission to assume the role, and the target role needs a separate permissions policy restricted to the required resources and actions. I review session duration, audit attribution, access removal, and whether session tags or source identity fit the integration. I test both valid and mismatched external IDs and monitor assumptions. A wildcard trust relationship with broad permissions is not made safe merely by adding an external ID.
101. How would you design KMS controls and recovery for encrypted data?
I separate key administration from routine data use and design recovery around both ciphertext and the keys required to decrypt it. For a customer managed KMS key, I review the key policy, applicable IAM permissions, grants, service integration, and any encryption-context constraints. A permissive application role can undermine otherwise strong storage access controls.
I inventory which backups, replicas, logs, and historical objects depend on each key. Rotation is not equivalent to re-encrypting every stored object, and deleting an old key without understanding dependencies can make retained data unreadable. For ordinary customer managed symmetric keys, scheduled deletion has a waiting period and can be canceled before completion; after permanent deletion, the original key is not recoverable.
I protect destructive key-management actions, alert on changes, and test restoration using a separately controlled recovery identity. Multi-Region keys have service-specific behavior and are not an automatic solution for every cross-Region restore. The runbook must identify the actual destination keys and policies used by the backup or replication service. I favor reversible containment where appropriate and require explicit authorization for deletion; losing a decryption path can defeat the entire disaster-recovery design.
102. How would you enforce tenant isolation in a shared AWS application?
I enforce tenant identity at every authorization boundary, not merely in the user interface. The authenticated tenant context must determine which records, objects, and operations the caller may access. A client-supplied tenant ID is input to validate, not proof of ownership.
In a pooled service, I might partition DynamoDB keys by tenant and use scoped credentials or service-side authorization appropriate to the access pattern. In S3, tenant-specific prefixes and carefully designed policies can help, but prefix naming alone does not enforce isolation. For higher-risk tenants, separate accounts, databases, or compute boundaries may be justified despite greater operating cost.
I test cross-tenant access attempts through normal APIs, background jobs, exports, caches, logs, and administrative tools. Shared caches need tenant-aware keys; a secure database query can still leak data if the cache lookup omits tenant identity. I also control noisy-neighbor effects with quotas and admission policies. The design distinguishes authentication, authorization, resource isolation, and performance isolation, because none of those automatically supplies the others. The chosen model should be explained as an explicit risk and cost trade-off rather than a universal SaaS template.
103. How would you design connectivity among many VPCs without assuming peering is transitive?
I choose an explicit routing architecture and document which networks are allowed to communicate. VPC peering connects peer VPCs but does not provide transitive routing: a connection from A to B and B to C does not make A-to-C traffic work through B. Large environments often need a hub such as Transit Gateway or a deliberate service-access model.
With Transit Gateway, I design attachment associations and route propagation separately from VPC subnet routes. Separate route tables can keep production, development, and shared services from becoming one unrestricted flat network. Security groups, network ACLs, inspection appliances, and return-path routing still matter; a transit attachment is not an authorization policy.
I reserve nonoverlapping address space, plan DNS resolution, and account for hybrid routes and regional boundaries. If traffic crosses a stateful inspection device, symmetric paths are important. I validate both directions of a representative flow and examine flow logs or reachability tooling where supported. For exposing one service rather than entire network reachability, PrivateLink may be a better fit. The simplest topology is the one that satisfies the actual communication matrix, not necessarily the one with the fewest diagrams.
104. How would you make outbound connectivity resilient while controlling data-transfer costs?
I begin by separating traffic that truly needs internet egress from traffic that can use private AWS service endpoints. Then I choose a documented egress topology with explicit failure behavior. For a design using zonal NAT gateways, each active zone can route through a local gateway so that loss of another zone's gateway does not strand it. I do not assume every NAT offering has identical scope or failover behavior.
I inspect route tables, endpoint policies, DNS behavior, firewall capacity, and application connection reuse. Centralized inspection can simplify policy but introduces routing complexity and potentially additional data-processing and transfer charges. Distributed egress can improve fault isolation but increases the number of components to manage.
The cost comparison uses measured bytes and the actual service, Region, and traffic path; I do not quote one universal NAT or cross-AZ rate. I also test failover paths for address allowlists used by external partners. Changing the egress architecture can alter the public source addresses they see. My success criteria are verified connectivity, bounded failure impact, auditable policy, and a measured cost model—not merely replacing one gateway with fewer gateways.
105. How would you design hybrid connectivity that survives a circuit failure?
I design redundancy across the failure domains that matter: devices, circuits, locations, providers, and AWS connectivity endpoints. Two logical connections sharing one physical path are not independent recovery options. For a critical Direct Connect deployment I evaluate diverse connections and locations, with a suitably sized Site-to-Site VPN backup where appropriate.
I define routing preferences and verify how BGP reacts to failures. The backup path must carry the required traffic, not merely establish a tunnel while idle. I also validate MTU, encryption requirements, DNS, firewalls, asymmetric routing, and return routes. Direct Connect is private connectivity, but privacy should not be confused with an automatic end-to-end encryption guarantee for every configuration.
A useful exercise removes one path under representative load and measures convergence, packet loss, application retries, and business impact. I test restoration as well, because flapping or premature preference changes can make recovery unstable. Capacity planning includes the reduced state after a failure and the possibility that internet VPN performance differs from the dedicated path. The documented result is a tested connectivity objective with known dependencies, not a claim that buying two links guarantees availability.
106. What would you review before running a sensitive workload on Amazon EKS?
I define the responsibility boundary for the exact EKS operating mode and then review the workload's trust boundaries. AWS manages the EKS control plane, but that does not mean AWS secures my container images, application authorization, Kubernetes RBAC, network policy, or secret handling. Node and runtime responsibilities differ among self-managed nodes, managed node groups, Fargate, and other supported modes.
I check how people and workloads authenticate, restrict privileged pods and host access, and give each workload only the AWS permissions it needs through an appropriate pod identity mechanism. I also review image provenance, vulnerability response, admission controls, network segmentation, audit logging, and outbound access. A namespace is useful organization but is not automatically a strong security boundary for mutually hostile tenants.
Operationally, I verify cluster and add-on compatibility, node-update procedures, resource requests and limits, disruption budgets, and capacity across failure domains. Backups must cover application state and configuration outside the managed control plane. Before approval, I want evidence from denied-access tests and a recovery exercise, not merely a checklist claiming that Kubernetes runs in a private subnet.
107. How would you deploy a container service without dropping in-flight requests?
I coordinate load-balancer deregistration, application shutdown, and replacement capacity. For an ECS service behind an Application Load Balancer, new tasks must become healthy before old tasks are removed according to the deployment configuration. Health checks should indicate readiness to serve useful requests, not merely that a process exists.
When an old task stops, the application should handle the stop signal, stop accepting new work, finish or safely hand off in-flight work, and exit within the configured timeout. Target-group deregistration delay and container shutdown timing must match actual request behavior. A short timeout suitable for a tiny API may break uploads, streaming responses, or long-running transactions.
I test deployment under load, including persistent connections and failing health checks. Deployment alarms and rollback reduce exposure, but rolling back containers does not undo incompatible data changes. For background consumers I separately handle message acknowledgement and visibility, so termination does not lose work or create uncontrolled duplicates. I also keep sufficient capacity during both rollout and rollback. The objective is bounded user impact with observable correctness; no deployment setting can promise zero interruption for every application protocol.
108. How would you prevent Lambda scaling from exhausting a relational database?
I limit concurrent database work to what the database can sustain instead of allowing the function tier to scale independently. This answer assumes Lambda Event Functions using the default execution model. I use appropriate function concurrency controls, and for SQS standard-mode event source mappings I can set maximum concurrency at the source. Provisioned polling mode has different controls and cannot be combined with that maximum-concurrency setting.
If each concurrent invocation opens two database connections and the workload is allowed 100 invocations, it may demand roughly 200 connections before considering other applications. Connection reuse and RDS Proxy can reduce connection-management overhead, but a proxy does not create unlimited database transaction capacity; session pinning and long transactions can reduce multiplexing benefits.
I bound query time, batch carefully, and consider queues for work that need not complete synchronously. The API should reject or defer excess demand deliberately rather than time out after saturating the database. I monitor connections, transaction latency, lock contention, function throttles, and queue age together. Reserved concurrency is not prewarming, and provisioned concurrency is not a substitute for downstream admission control.
109. How would you investigate high Lambda latency and unexpected serverless costs?
For Lambda Event Functions on the default compute model, I separate initialization, handler execution, downstream waits, and retry amplification. I inspect duration percentiles, errors, throttles, invocation volume, memory usage, and traces before deciding that cold starts are the cause. A slow database call will not be fixed merely by prewarming execution environments.
I benchmark representative inputs at several memory settings because memory allocation also affects available CPU. Higher memory can shorten execution enough to change the cost trade-off; the cheapest configured memory is not necessarily the lowest cost per successful transaction. I also inspect payload size, serialization, connection reuse, excessive logging, and recursion or event loops that unexpectedly multiply invocations.
Provisioned concurrency may help predictable initialization-sensitive traffic, but it has its own configuration and cost implications. I compare measured improvements against actual service and Region pricing rather than asserting a universal savings percentage. The cost model includes API Gateway, data stores, queues, network paths, and logs, not just function duration. I validate changes against correctness and tail latency under realistic load; a lower average duration can hide worse failures or duplicate processing.
110. How would you define useful SLOs and alarms for an AWS application?
I define SLOs around user-visible outcomes, then connect them to actionable telemetry. For a checkout API, availability might mean a valid request completes successfully within an agreed latency threshold. I specify the measurement window, eligible requests, and treatment of client errors so that the number cannot improve simply by excluding inconvenient failures.
A hypothetical 99.9% request-success objective over one million eligible requests allows 1,000 unsuccessful requests in that window. That is a planning example, not an AWS SLA. Error-budget consumption and burn rate help determine whether to page immediately, investigate during business hours, or pause risky deployments.
CloudWatch Application Signals can support service-level indicators and objectives where integrated, while application metrics may be needed for business outcomes such as orders accepted but never fulfilled. I alert on symptoms with a clear owner and runbook, and use resource metrics for diagnosis. Low CPU is not evidence that customers can buy. I also test alarms and missing-data behavior, review noisy signals, and ensure the measurement path itself is trustworthy during an incident.
111. How would you investigate a slow request that crosses several AWS services?
I follow one representative request across its boundaries using correlation IDs, structured logs, metrics, and distributed traces. I first establish whether the slowdown is widespread or isolated to an endpoint, tenant, Region, or dependency. Then I inspect the critical path rather than sum every span, because parallel calls can overlap.
For a request passing through API Gateway, a Lambda Event Function, and DynamoDB, I separate ingress latency, function initialization and execution, SDK retries, and database response time. A high application span may include waiting for connection acquisition or backoff, not just remote service work. Instrumentation through supported OpenTelemetry or AWS tracing integrations can reveal those boundaries, but sampling means a missing trace is not proof that a request never occurred.
I correlate the timing with deployments, throttling, queue age, resource saturation, and downstream errors. Logs must avoid secrets and unnecessary personal data. I also examine trace propagation across asynchronous messages, where a workflow can outlive the initial HTTP request. The output should be a falsifiable bottleneck hypothesis, a targeted change, and a before-and-after measurement—not a blanket recommendation to increase every instance size.
112. How would you perform a controlled resilience experiment?
I start with a hypothesis, a narrow blast radius, and explicit permission to run the experiment. For example: losing one application instance should not increase checkout errors beyond an agreed threshold because healthy capacity remains. The experiment needs a steady-state measurement, selected targets, an observation window, and a recovery plan.
AWS Fault Injection Service can orchestrate supported fault actions, and CloudWatch alarms can act as stop conditions. I verify that the alarms measure meaningful customer impact and that the operators can stop the experiment independently. Stopping fault injection does not necessarily undo every consequence already produced, so cleanup and recovery procedures remain necessary.
I first validate the procedure in a suitable nonproduction environment, then separately authorize any production exercise. I avoid combining several novel failures at once because the result becomes hard to interpret. During the exercise I record the fault, detection time, automated response, manual intervention, and data correctness. If the system fails the hypothesis, the useful result is a specific engineering gap with a retest plan. This answer describes a planning method; no fault experiment or AWS action has been executed here.
113. How would you recover a failed CloudFormation deployment safely?
I inspect stack events and the first meaningful failure before attempting another update. The important distinction is whether the stack is still progressing, rolled back successfully, or is stuck in a state such as UPDATE_ROLLBACK_FAILED. Repeatedly submitting changes can obscure the original problem and increase drift.
For a failed rollback, I identify the resource that cannot return to its previous state—perhaps a missing dependency, quota, permission, or manually modified resource—and correct that cause through the approved operational process. I then use the supported continue-rollback workflow. Skipping resources is a last-resort recovery technique because skipped resources may no longer match the template and must be reconciled before future updates.
Bash command
This is an illustrative read-only diagnostic command, not an executed account action. Before deployment I review change sets for replacement of stateful resources and set appropriate retention or snapshot policies. A successful CloudFormation status establishes infrastructure workflow completion, not that the application or its data remained correct throughout the incident.
114. How would you deploy a backward-compatible database schema change?
I use an expand-and-contract migration so old and new application versions can coexist during deployment. First I add a compatible schema shape, then deploy code that can work with both representations, backfill safely, switch reads when verified, and remove the old structure only after the rollback window closes.
For example, renaming full_name to separate name fields is not safely achieved by dropping the old column during a rolling deployment. I might add nullable new columns, backfill with a defined transformation, and maintain compatibility while old instances remain. Backfill rate, locks, indexes, replication lag, and partially transformed data all require measurement.
RDS Blue/Green Deployments can help with supported engine changes, but they are not a universal schema-migration escape hatch. Engine versions and replication mode constrain which changes are supported; physical-replication green environments can be read-only, and logical replication has its own limitations. I verify those constraints for the exact deployment. Rolling application code back is only safe while the retained schema and written data remain compatible. After destructive contraction, rollback may require a forward fix or a separately planned data recovery.
115. How would you compare AWS architectures using unit economics rather than monthly totals alone?
I compare cost per useful business outcome at an agreed reliability and performance level. A larger monthly bill may be efficient if the system serves many more successful transactions, while a lower bill can hide dropped work or worse latency. I define the unit clearly: a completed order, active tenant, processed gigabyte, or another meaningful output.
For an illustrative comparison, an architecture costing $3,000 for 600,000 successful jobs costs $0.005 per job. Another costing $2,400 for 300,000 successful jobs costs $0.008 per job. Those are invented arithmetic inputs, not AWS price quotes, and they exclude any costs not included in the stated totals.
I allocate shared expenses consistently and include compute, storage, requests, data transfer, observability, support arrangements, and operational effort where relevant. I inspect idle capacity and failed or duplicate work separately. Cost allocation tags, account boundaries, and billing exports can improve attribution, but unallocated shared services still need a documented rule. I then vary traffic, failure rates, and commitment utilization to see whether the preferred architecture remains economical as the workload changes.
116. How would you evaluate Savings Plans, reservations, and Spot capacity for a workload?
I separate price commitment from capacity assurance and interruption tolerance. Savings Plans exchange a sustained usage commitment for eligible discounted usage, but they do not themselves reserve EC2 capacity. Reserved Instance benefits depend on the product and scope; a regional discount should not be confused with a zonal capacity reservation.
I first right-size the workload and estimate the stable baseline, then model commitment coverage and utilization under realistic growth and migration scenarios. Committing against a temporary peak can leave unused spend later. For an upcoming event requiring specific EC2 capacity, I evaluate the appropriate capacity-reservation product independently from the discount model.
Spot fits interruptible work with durable checkpoints, retryable tasks, and flexible instance choices. I do not place irreplaceable state only on a Spot instance or assume every interruption gives enough time to finish. Diversification and interruption handling reduce risk but do not guarantee replacement capacity. The comparison includes operational complexity, completion deadlines, and fallback cost. I verify current eligibility, term, Region, and pricing before any purchase; this interview answer does not authorize a financial commitment or quote a savings percentage.
117. How would you reduce cross-AZ and cross-Region transfer costs without weakening reliability?
I map the real data paths before optimizing them. A request may cross zones through a load balancer, NAT path, database connection, cache, or inspection appliance, and the charging rules vary by service and direction. Cross-Region replication adds another independent flow. I use billing and network evidence rather than infer cost from the architecture diagram alone.
Useful changes include reducing chatty calls, compressing suitable payloads, caching safe read results, batching transfers, and using appropriate private service endpoints. Keeping a zonal dependency local can reduce unnecessary traffic, but forcing every dependency into one zone can create an unacceptable availability risk. I compare the savings with failure-domain and capacity consequences.
For a replicated analytics dataset, I ask whether every raw record must cross Regions or whether an approved aggregate is sufficient. That decision also affects recovery and data-governance needs. I verify current pricing for the exact endpoints and topology and include request or processing charges introduced by an alternative design. A lower transfer line item is not a win if it increases total cost, loses required data, or breaks the workload's resilience objective.
118. How would you migrate a database with a short cutover window and a credible rollback plan?
I combine an initial load with ongoing change capture where the source and target support it, then make cutover a controlled change in write ownership. AWS DMS can help move and replicate data, but I separately validate schema compatibility, data types, sequences, indexes, constraints, permissions, and application behavior.
Before the window, I rehearse the full process with representative volume and monitor replication lag and validation results. During cutover, I stop or fence source writes, let the target catch up to a verified boundary, run reconciliation checks, change application connectivity, and validate business transactions. A low reported lag is useful evidence but is not the sole proof that every required object and transformation is correct.
Rollback must be defined before the target starts accepting new writes. If those writes are not replicated back safely, simply pointing clients at the old source would lose them. I therefore define a no-return boundary, reverse-replication or reconciliation strategy where supported, and an explicit decision owner. I retain the source and recovery artifacts until acceptance criteria are met. DMS task completion is one milestone, not proof of a successful application migration.
119. How would you evaluate data residency requirements for a multi-Region AWS design?
I translate the requirement into a concrete data-flow and control inventory with the organization's legal and security teams. Choosing an AWS Region is important, but it does not automatically prove that every relevant datum stays there. I identify primary records, backups, replicas, logs, telemetry, exports, encryption metadata, support workflows, and external integrations.
For each service I verify regional availability, data-location behavior, cross-Region features, and the account partition involved. Global edge services and third-party processors require special attention rather than assumptions based on where the main database runs. An approved multi-Region design must use locations allowed by the actual requirement, not simply the nearest recovery Region.
I then enforce the architecture with scoped permissions, organization guardrails where appropriate, restricted replication and export paths, and monitored configuration. Encryption helps protect confidentiality but is not a substitute for a residency requirement. Recovery exercises must also respect the approved locations. I document unresolved interpretation questions instead of offering a blanket compliance claim. This is a technical assessment method; a service's certifications or a Region choice alone do not determine whether the complete workload satisfies a particular law or contract.
120. How would you prepare an AWS workload for a major traffic event?
I prepare the whole demand path, including quotas, capacity, dependencies, and degraded behavior. A higher service quota is permission to consume more, not a guarantee that a particular EC2 instance type will be available in a particular zone. I distinguish adjustable quotas, fixed limits, scaling rates, and actual provisioned capacity.
I forecast peak arrival rates and bursts, then load-test representative workflows with realistic data and downstream limits. I verify scaling policies, warm-up times, database connection budgets, queue drain capacity, caches, external provider quotas, and observability limits. For critical capacity needs I evaluate supported reservation options through the normal approval process.
The event runbook includes owners, dashboards, freeze criteria, rollback, feature flags, admission control, and customer-safe degradation. For example, delaying a nonessential report may preserve checkout when resources are constrained. I rehearse failure during peak traffic, not only an ideal scaling curve. After the event I reconcile business results and remove temporary capacity through an authorized cleanup plan. No load test, quota request, reservation, or resource creation is performed as part of this article; those are separately controlled operational actions.
AWS Documentation and Further Reading
AWS capabilities, Region availability, quotas, pricing, and support evolve independently by service. This guide assumes the commercial AWS partition and explicitly distinguishes relevant service variants and consistency modes; it makes no universal price, SLA, or latest-release claim. Verify the target Region, engine or platform version, configuration, and current documentation before implementation. Examples were reviewed and locally checked where reported, not executed against AWS.
These 15 curated primary AWS references cover the main architecture, implementation, security, and operational topics. They are a focused reading list rather than every page consulted. Documentation review and local parsing or arithmetic checks do not establish deployed behavior, account permissions, performance, or production readiness.
Similar Posts