AWS

Explain how AWS IAM Role assumption works across different AWS accounts securely.

One account can use another account's resources without a password or an access key ever changing hands. The role's trust policy decides who is allowed in, its permissions policy decides what they can do once they're there, and STS hands out credentials that expire on their own.

How do you architect a highly available, zero-downtime database migration in AWS RDS?

Zero downtime means you never ask for a maintenance window. Bring the new database up next to the old one, keep it in sync while the old one carries all the traffic, check the data constantly, then switch connections over in a few seconds, with a way back you set up before you need it.

Your EC2 instances in a private subnet need to reach S3 and a third-party API, but must never be reachable from the internet. Design the networking.

Outbound-only access comes from a NAT Gateway in a public subnet, but S3 traffic should skip it entirely through a VPC endpoint, which is free and never leaves the AWS network. Nothing can reach in because there's no route for it to take, not because a rule is blocking it, and that distinction is usually the real follow-up question.

Your traffic is spiky and unpredictable during business hours. Design an EC2 Auto Scaling policy that reacts fast without overspending overnight.

Target tracking should be the default scaling policy, since it only needs one metric and handles the math itself. Layer scheduled actions on top for the predictable part of the day, and treat step scaling as the exception for spikes that need a bigger, immediate jump than target tracking gives you.

When would you use EC2 Spot Instances in production, and how do you design a workload to survive interruptions?

Spot is unused EC2 capacity sold at a steep discount, usually 60 to 90 percent off On-Demand, with the trade that AWS can reclaim it with two minutes of warning. It's a good fit for anything stateless, retryable, or checkpointed, and a bad fit for anything that can't tolerate an interruption.

Reserved Instances, Savings Plans, Spot, and On-Demand: how do you decide what mix to run for a given EC2 workload?

The decision runs on one axis: how predictable is the usage, not how important the workload is. Steady, known baseline load goes on Savings Plans, spiky or unknown load stays On-Demand, and anything interruption- tolerant goes on Spot. Reserved Instances are mostly the older, less flexible version of a Savings Plan today.

How do you cut EC2 costs for workloads that sit idle nights and weekends, without relying on someone remembering to turn things off?

Automate the stop and start instead of asking anyone to remember it. Scheduled Auto Scaling actions or AWS Instance Scheduler both work; the choice mostly comes down to whether the fleet is already behind an Auto Scaling group. Either way, tag-based scoping is what keeps it from ever touching something that shouldn't be stopped.

How do you prepare an EC2-based application to fail over to a second AWS region if the primary region has an outage?

Disaster recovery for EC2 is really three separate problems: getting a bootable image into the DR region ahead of time, having a way to launch capacity there fast, and having something outside both regions to redirect traffic. The RTO and RPO you're targeting decide how much of that you keep running warm versus building on demand.

How do you get visibility into what's happening on an EC2 fleet, and who changed what, without SSHing into boxes to find out?

These are two different questions wearing one sentence. CloudWatch answers "what is the fleet doing right now," metrics, logs, alarms. CloudTrail answers "who did what to it," an audit log of every API call. Confusing the two is the most common way this question goes wrong.

Your application needs to feel fast for users spread across multiple continents. What would you put in front of it, and why?

Amazon CloudFront is a CDN that terminates connections and caches content at edge locations close to the user, so most requests never travel back to the origin region at all. It helps static content the most, but modern CloudFront also improves dynamic requests through TCP/TLS termination at the edge and origin connection reuse.

Design the subnets and routing for a standard three-tier web application: a public web layer, a private application layer, and a private database layer.

Three tiers, three subnet groups, each with a route table that only grants the access that tier actually needs. The database subnet shouldn't be able to reach the internet at all, the app subnet gets outbound-only through NAT, and only the web subnet has a real route to the internet gateway. Everything else follows from that one rule.

You have a dozen VPCs that all need to reach each other and a shared-services VPC. Would you use VPC Peering or Transit Gateway, and why?

Peering connects two VPCs directly and doesn't scale past a handful of them, since connections grow quadratically and traffic can't transit through a peered VPC to reach a third. Transit Gateway is a central routing hub that turns the same problem into one connection per VPC, and it's the right call anywhere past three or four VPCs.

How would you securely connect an on-premises data center to a VPC, and when would you reach for Direct Connect instead of a Site-to-Site VPN?

A Site-to-Site VPN is fast to set up, encrypted by default, and runs over the public internet, which is also its ceiling: bandwidth and latency aren't guaranteed. Direct Connect is a dedicated physical link with predictable performance, but it takes weeks to provision and isn't encrypted on its own. Most serious hybrid setups end up running both.

A subnet holds your most sensitive data. Design the Network ACL rules around it as a second layer of defense behind Security Groups.

A NACL earns its place by doing the one thing a Security Group can't: an explicit, subnet-wide deny that survives a misconfigured Security Group rule. The design is a default-deny rule set with narrow, numbered exceptions, remembering that NACLs are stateless, so return traffic on ephemeral ports needs its own explicit allow.

Two EC2 instances in the same VPC can't reach each other over a port that should be open. Walk through how you'd find out why.

Work outward from the instance rather than guessing at the network: confirm the app is actually listening, then check Security Groups, then NACLs, then the route table, then Flow Logs to see what AWS's own network actually did with the packet. Each layer either clears itself or points straight at the next thing to check.

Multiple teams share one AWS account. How do you structure IAM so each team can only touch the resources they own?

Individual users each get their own IAM role via SSO federation, never a shared login or a long-lived access key, and permissions are grouped by team into roles scoped with resource tags rather than hardcoded ARNs. Past a certain team count, the real fix is separate AWS accounts per team, not tighter policies inside one shared account.

How do you make sure data is encrypted everywhere it lives in AWS, both at rest and in transit, without it becoming a project unto itself?

At rest, nearly every AWS storage service takes a KMS key as a one-time setting at creation, and the actual work is deciding who can use that key, not the encryption itself. In transit, TLS terminated with a Certificate Manager certificate covers the external hop, but internal service-to- service traffic needs its own explicit decision, since nothing enforces it by default.

How do you continuously monitor an AWS account for security and compliance drift, instead of only finding out during an annual audit?

Point-in-time audits catch a configuration that was wrong when someone happened to look. AWS Config evaluates resources continuously against rules and records every configuration change, CloudTrail records who made it, and Security Hub aggregates both into one place with a severity score so drift gets flagged the hour it happens, not the quarter someone checks.

Multi-AZ deployments, read replicas, and Aurora all get mentioned as RDS availability features. What's actually different between them, and when do you use each?

Multi-AZ is a synchronous standby that exists purely for failover, not for serving traffic. A read replica is asynchronous and exists to serve read traffic, with failover as a secondary, slower use. Aurora replaces both mechanisms with a shared, distributed storage layer, which is why an Aurora Replica can do double duty that a standard RDS replica can't.

Your application suddenly can't connect to its RDS database. Walk through how you'd diagnose it.

Rule out the database's own health first, since that's a two-second check in the console, then work through the network path in order: security groups, subnet and public accessibility, DNS, and connection limits. A sudden failure that used to work points hardest at something that changed recently, not at a fundamentally broken setup.

Design a backup and recovery strategy for a production RDS database, including what point-in-time recovery can and can't actually do for you.

Automated backups and point-in-time recovery cover the everyday case, restoring to any second within the retention window, but every restore creates a brand-new instance rather than repairing the existing one, and neither protects against a whole-region outage on its own. Cross-region snapshot copies and manual snapshots fill the two gaps that leaves.

Your RDS bill keeps climbing every month. What levers do you actually have to bring it down?

RDS cost breaks into three independent knobs: compute (instance type and purchase option), storage (type and provisioned amount), and everything that scales with those two but isn't obviously tied to them, like snapshot retention and cross-AZ data transfer. Most real savings come from right-sizing and switching purchase options, not from a single trick.

How do you safely rotate IAM credentials or database secrets without downtime?

The safe pattern is overlapping validity. Create the new secret while the old one still works, get code that accepts either one deployed everywhere, confirm the new one is actually being used, then revoke the old one. Rotating in a single step guarantees a window where something is still holding a credential that no longer works.

What happens if an Auto Scaling instance never becomes healthy?

Auto Scaling terminates and replaces an instance that never passes health checks, which is fine once and expensive in a loop. How long you burn depends on the grace period, the check thresholds, and which health check type the group is actually using. The fix is working out why it's unhealthy: usually startup config, a wrong health endpoint, or a grace period shorter than boot time.