70+ AWS Cloud Engineer Interview Questions & Answers (2026)

Answer: The Shared Responsibility Model defines who is responsible for what in AWS security:

• AWS is responsible for (“Security OF the Cloud”): Physical security of data centers (locks, cameras, guards), network infrastructure (routers, switches), hypervisor security, managed service infrastructure. AWS secures the infrastructure you run on.
• You are responsible for (“Security IN the Cloud”): IAM and access control (who can do what), encryption of data in transit and at rest, operating system and application patching, network configuration, firewall rules, security groups. You secure your applications and data.

Concrete examples:

• EC2: AWS secures the physical servers and hypervisor. You must patch the OS, manage firewall rules, control IAM permissions.
• RDS: AWS manages backups, patches the database engine, and ensures physical security. You must manage database users, encrypt sensitive columns, control network access via security groups.
• S3: AWS ensures the storage infrastructure is secure. You must manage bucket policies, IAM permissions, encryption keys, and versioning.
• Key insight: With managed services, AWS takes on more responsibility. With EC2, you take on more. Always understand who owns what.

Answer:

• Availability Zone (AZ): An isolated data center within a region (examples: us-east-1a, us-east-1b, us-east-1c). Connected by low-latency, high-bandwidth network. If one fails, others continue. Data doesn’t automatically replicate between AZs.
• Region: A geographic area containing multiple AZs (examples: us-east-1 Virginia, eu-west-1 Ireland, ap-southeast-1 Singapore). Completely independent. Data doesn’t replicate between regions unless you explicitly configure it.

When to use each:

• Multi-AZ deployment (High Availability): Deploy application across 2–3 AZs in the same region. Use Multi-AZ RDS, Application Load Balancer across AZs, Auto Scaling groups spanning AZs. If one AZ fails (rare), another takes the load immediately. Latency is minimal since AZs are close.
• Multi-Region deployment (Disaster Recovery): Deploy across multiple regions for geographic redundancy. Required for regulatory compliance (data residency), protection against regional outages, and serving global users with low latency. Use Route 53 for failover, RDS read replicas across regions, S3 cross-region replication.
• Cost consideration: Multi-AZ adds minimal cost (just extra compute/RDS replica). Multi-region is expensive (duplicate infrastructure across regions). Choose based on RTO/RPO and business criticality.

Answer: The Well-Architected Framework guides cloud architecture design:

• 1. Operational Excellence: Run and monitor systems effectively. Use CloudWatch for monitoring, CloudTrail for auditing, Systems Manager for patch management, Infrastructure as Code (CloudFormation) for repeatability.
• 2. Security: Protect data and systems. Implement least privilege IAM, encrypt data in transit (TLS) and at rest (KMS), use security groups and NACLs, enable logging and monitoring, patch systems promptly.
• 3. Reliability: Design for failure. Deploy across multiple AZs, use Auto Scaling for availability, implement health checks, plan for RTO (Recovery Time Objective) and RPO (Recovery Point Objective), use managed services with SLAs.
• 4. Performance Efficiency: Use resources effectively. Right-size instances (not oversized), use caching (CloudFront, ElastiCache), optimize database queries, choose the right database (SQL vs NoSQL), monitor performance metrics.
• 5. Cost Optimization: Run at lowest cost. Use Reserved Instances for predictable load, Spot Instances for batch jobs, right-sizing based on usage, lifecycle policies for old data, tag resources for cost allocation.
• 6. Sustainability: Minimize environmental impact. Use efficient architectures, leverage managed services (AWS optimizes them at scale), right-size to avoid waste, use serverless when possible (Lambda consumes less power than EC2).

Answer: EC2 instance types are organized by family, each optimized for different workloads:

• General Purpose (M, Mac): Balanced compute, memory, and networking. Use for web servers, small databases, application servers. m5.large, m6i.xlarge.
• Compute Optimized (C): High CPU relative to memory. Use for batch processing, media transcoding, scientific modeling, high-performance web servers. c5.2xlarge.
• Memory Optimized (R, X): High memory-to-CPU ratio. Use for in-memory databases, caches, real-time analytics. r5.2xlarge for Redis/Memcached, x1e for SAP HANA.
• Storage Optimized (I, H, D): High IOPS and throughput. Use for NoSQL databases, data warehouses, Elasticsearch. i3en for NVMe SSD storage.
• Accelerated Computing (P, G, F): GPUs and specialized hardware. Use for machine learning (p3 with NVIDIA GPUs), graphics rendering (g4 for video encoding), FPGA workloads.

How to choose: Start with general purpose (t2/t3 for non-prod), benchmark your workload, use CloudWatch metrics (CPU, memory, network) to identify bottlenecks, then right-size to the appropriate type.

Answer: The choice depends on your requirements:

Decision: Use Lambda for sporadic, short-lived tasks (file processing, API backends, scheduled jobs). Use EC2 for always-on applications, long-running jobs, or when you need full control over the OS.

Answer: S3 offers different storage classes optimized for different access patterns and cost:

• S3 Standard: Default class. Frequent access, low latency, high availability. Most expensive per GB. Use for active data, websites, content distribution. $0.023/GB.
• S3 Standard-IA (Infrequent Access): Lower storage cost but retrieval fee. Minimum 30-day storage. Use for backups, disaster recovery data accessed occasionally. $0.0125/GB + $0.01 per retrieval.
• S3 Glacier Instant: Archive storage with instant retrieval. Minimum 90-day storage. Use for compliance archives accessed rarely. $0.004/GB + retrieval fee.
• S3 Glacier Flexible:** Cheapest, but retrieval takes 1–12 hours. Minimum 90-day storage. Use for long-term archives (regulatory archives, rarely accessed logs). $0.0036/GB.
• S3 Deep Archive: Ultra-cheap for 7+ year retention. Retrieval takes 12 hours. $0.00099/GB. Use for regulatory archival (financial records, medical records).

Cost example: 1 TB of data stored 1 year: Standard = $276/year. Glacier Flexible = $3.65/year (98% savings). Lifecycle policies automatically transition data to cheaper classes.

Best practice: Use S3 Standard for first 30 days, then transition to Standard-IA after 30 days, Glacier after 90 days, and Deep Archive after 1 year. Implement with S3 Lifecycle Policies.

Answer:

• S3 (Object Storage): Unlimited scalability, accessible via HTTP/HTTPS. No fixed size. Flat hierarchy (buckets and objects). Use for backups, logs, static websites, data lakes, media files. Good for write-once-read-many (WORM). Access latency is higher (milliseconds).
• EBS (Block Storage): Persistent block storage for EC2. Must be attached to an instance. Fixed size (provisioned). Low latency (microseconds). Use for OS volumes, databases, high-performance needs. Snapshots for backup. Can’t be shared across instances (except multi-attach).
• EFS (File Storage): Shared file system across multiple EC2 instances. NFS protocol. Scales automatically. Use for shared application data, home directories, content repositories. Higher latency than EBS but lower than S3. More expensive than EBS.

Answer: A typical 3-tier VPC design:

• VPC CIDR: 10.0.0.0/16 (65,536 IPs)
• Web Tier (Public Subnets): 10.0.1.0/24 (AZ-a), 10.0.2.0/24 (AZ-b). Contains Application Load Balancer. Route table: 0.0.0.0/0 → Internet Gateway. Security group: Allow inbound 80/443, outbound to app tier.
• App Tier (Private Subnets): 10.0.11.0/24 (AZ-a), 10.0.12.0/24 (AZ-b). Contains EC2 instances. Route table: default traffic → NAT Gateway in public subnet. Security group: Allow inbound from ALB security group, outbound to DB tier.
• DB Tier (Private Subnets): 10.0.21.0/24 (AZ-a), 10.0.22.0/24 (AZ-b). Contains RDS Multi-AZ. Security group: Allow inbound only from app tier security group.
• Key points: Public subnets route to Internet Gateway for inbound internet access. Private subnets route to NAT Gateway (in public subnet) for outbound internet access. Security groups implement least privilege — web allows 80/443, app talks to DB, DB only listens to app. NACLs can add additional stateless filtering.

Answer:

In practice: Use Security Groups for most cases (easier to reason about, stateful). Use NACLs for additional subnet-level filtering or deny specific IPs/ranges.

Answer:

Rule of thumb: RDS for structured, transactional data (financial systems, e-commerce). DynamoDB for high-volume, simple access patterns (user sessions, IoT sensor data, real-time notifications).

Answer:

• Multi-AZ: Synchronous replica in different AZ. Automatic failover if primary fails (typically <1 minute RTO). Writes go to primary, reads from primary (replicas used only for failover). Higher cost (~2x). Used for high availability, not read scaling.
• Read Replicas: Asynchronous copies of the database (same or different region). Reads can hit replicas (reducing load on primary). No automatic failover. Can promote a replica to standalone DB. More cost-effective than Multi-AZ. Used for read scaling and regional disaster recovery.
• Combined: Enable both Multi-AZ (for HA) + read replicas (for scaling reads). Primary has synchronous Multi-AZ replica in another AZ, plus asynchronous read replicas in other regions for read scaling and DR.

Answer: Principle of Least Privilege means each user/role should have only the minimum permissions needed to do their job. Never use admin/full access.

How to implement:

• Start with deny-all, explicitly grant needed permissions
• Use IAM roles (not root account credentials) for EC2 instances and Lambda
• Create specific policies for specific jobs (e.g., “EC2ReadOnly,” “S3BackupWrite”)
• Use resource-level permissions to limit access to specific S3 buckets, RDS instances
• Implement conditions (e.g., allow access only from specific IP ranges, only during business hours)
• Example: Developer needs to deploy to S3. Instead of S3FullAccess, grant: s3:GetObject, s3:PutObject on specific bucket, s3:ListBucket on specific bucket only.

Answer: KMS (Key Management Service) manages encryption keys for data at rest and in transit.

• How it works: You create a master key in KMS. When data needs to be encrypted (S3, RDS, EBS), AWS uses this key to encrypt the data. The encrypted data is stored, and the key is protected by AWS (never leaves KMS).
• Envelope encryption: KMS generates a data key from the master key, uses it to encrypt your data, then encrypts the data key. You store the encrypted data and encrypted data key together. Only KMS can decrypt the data key, so only authorized users can decrypt your data.
• Services supporting KMS: S3, RDS, EBS, DynamoDB, Lambda, CloudTrail, Redshift, and more.
• Best practice: Enable encryption by default (default keys or customer-managed keys). Use customer-managed keys for sensitive data so you control key rotation and access policies.

Answer (applying Well-Architected Framework):

1. Content Delivery (Performance): CloudFront CDN caches static assets at 200+ edge locations globally. Reduces latency to <100ms for 99% of users. Static content (images, CSS, JS) expires in 1 year, refreshed via cache invalidation.

2. Multi-Region Active-Active (Reliability): Deploy in us-east-1, eu-west-1, ap-southeast-1. Route 53 geoproximity routing sends users to nearest region. All regions serve read traffic; writes replicate. RTO <5 min, RPO <1 min.

3. Compute (Auto-Scaling): ALB + Auto Scaling groups across 3 AZs in each region. Target capacity: 80%. Scale up if CPU >70%, scale down if <30%. Warm pools maintain ready instances for instant scaling.

4. Database (Consistency + Performance): Aurora Global Database for primary + read replicas. Write to primary (us-east-1), read from replicas. <1 sec replication latency. Automated failover to read replica if primary fails.

5. Caching (Performance): ElastiCache Redis cluster in each region (session store, frequently accessed data). 99% cache hit rate reduces DB queries by 100x.

6. Monitoring (Operational Excellence): CloudWatch metrics (p99 latency, error rate, cache hit rate). X-Ray tracing for request tracking. Alarms for >100ms p99 latency or >1% error rate.

7. Cost (Cost Optimization): Spot instances for non-critical batch jobs (70% savings). Reserved instances for baseline capacity. CloudFront reduces egress costs (cheaper than EC2 direct). Aurora pricing optimized (pay per transaction, not reserved capacity).

Answer:

• Phase 1 (Week 1–2) – Assessment: Identify database type (Oracle, SQL Server), schema size, current load, dependencies. Analyze if Oracle → RDS Oracle or consider Aurora if willing to refactor SQL. Estimate migration window.
• Phase 2 (Week 3–4) – Setup: Create target RDS instance (Multi-AZ, backup retention 30 days). Set up AWS DataSync to transfer 50GB. Enable automated backups. Test restore from backup.
• Phase 3 (Week 5–6) – Dry Run: Use DMS (Database Migration Service) to do full migration in non-prod environment. Validate data consistency, run application tests, measure performance. Create runbook for cutover.
• Phase 4 (Week 7) – Cutover: Final sync using DMS (only changed data since last run, <5 min). Switch connection strings to RDS. Monitor for 24 hours. Keep on-prem database available for rollback for 1 week.
• Cost & Timeline: DMS transfer cost ~$0.36/GB ($18 for 50GB). RDS cost ~$500/month. Total migration cost ~$1,000. 7-week timeline includes testing.

• Use the Well-Architected Framework as your lens: Frame every answer around Operational Excellence, Security, Reliability, Performance, Cost, and Sustainability. Interviewers love seeing this.
• Think about trade-offs: “S3 costs less but has higher latency than EBS. For a database, EBS is better. For backups, S3 is cheaper.” This shows nuanced thinking.
• Draw architecture diagrams: When asked “design a system,” grab a whiteboard. Draw subnets, instances, load balancers, databases, caching layers. Labels matter.
• Discuss monitoring and observability: Good architects monitor their systems. Mention CloudWatch, X-Ray, application logs. This shows operational maturity.
• Connect to your experience: “In my previous role, we had a similar challenge with high database latency. We solved it by adding ElastiCache…” Real stories beat textbook answers.
• Ask clarifying questions: Real architects ask questions before designing. “Is this a real-time system or batch? How many concurrent users? What’s our budget?” shows you think like an architect.

• Over-engineering for requirements: Don’t suggest multi-region, auto-scaling, NoSQL databases for a simple internal tool. Understand actual requirements first.
• Ignoring cost: AWS is cheap for scale but expensive if misconfigured. Always talk about cost optimization: Reserved Instances, lifecycle policies, right-sizing.
• Forgetting security: Every design needs IAM, encryption, network isolation, logging. It’s not an afterthought; it’s integral.
• Being vague about services: “Use a database” is weak. “Use RDS Aurora for relational data because it scales reads with replicas and has Multi-AZ failover” is strong.
• Memorizing without understanding: If you can’t explain why you chose a service, interviewers will probe deeper and expose gaps.
• Ignoring operational concerns: You chose RDS, but how do you backup, monitor, patch, and handle failover? Ops maturity matters.