Amazon Web Services Core Services Questions

Comprehensive knowledge of the foundational Amazon Web Services that are commonly used to design, deploy, and operate cloud applications. This includes compute services such as Amazon Elastic Compute Cloud for virtual machines and instance families, Amazon Web Services Lambda for serverless functions, and Amazon Elastic Beanstalk for managed application platforms; storage services such as Amazon Simple Storage Service for object storage, Amazon Elastic Block Store for block volumes, and Amazon Elastic File System for shared file storage; database services such as Amazon Relational Database Service for managed relational databases, Amazon DynamoDB for NoSQL, and Amazon ElastiCache for in memory caching; networking and content delivery including Amazon Virtual Private Cloud networking concepts, subnets, security groups, load balancers, and Amazon CloudFront; container and orchestration options such as Amazon Elastic Container Service and Amazon Elastic Kubernetes Service; and management and security services including Identity and Access Management, Amazon CloudWatch monitoring and logging, Auto Scaling, and cost and service limit considerations. Candidates should understand core service characteristics, common configuration choices and trade offs, operational considerations such as high availability and fault tolerance, basic security and compliance approaches, performance and cost optimization, and guidance for selecting one service over another for typical application patterns.

MediumTechnical

76 practiced

Compare Amazon EBS volume types gp2, gp3 and io2 in terms of baseline performance, IOPS and throughput provisioning, cost model, durability SLA, and typical use cases. For a highly transactional OLTP database with steady high IOPS and low latency needs, explain how you would choose type, size, and IOPS configuration.

Sample Answer

**Brief comparison (gp2 vs gp3 vs io2)**

- Baseline performance - gp2: Baseline = 3 IOPS per GiB; small volumes burst using credits. - gp3: Baseline performance is independent of size; you get base performance and can provision IOPS/throughput separately. - io2: Provisioned IOPS SSD designed for sustained, low-latency I/O; performance independent of size.

- IOPS & throughput provisioning - gp2: IOPS scales with size (3 IOPS/GiB); no separate IOPS provisioning. - gp3: Provision up to 16,000 IOPS and up to 1,000 MiB/s throughput independently of size. - io2: Provision up to 64,000 IOPS (io2 Block Express higher) and up to 1,000 MiB/s; designed for very high sustained IOPS.

- Cost model - gp2: Pay per GiB; IOPS implicit in size — cost increases with size to get more IOPS. - gp3: Pay per GiB + per provisioned IOPS + per provisioned throughput — generally cheaper when you need high IOPS but small size. - io2: Higher per GiB and per IOPS cost; premium for durability, consistency and high IOPS.

- Durability / SLA - gp2/gp3: Standard EBS durability (~99.999% annual durability for volumes). - io2: Higher durability target and better SLA for uptime/consistency; designed for mission-critical apps.

- Typical use cases - gp2: General purpose workloads where size correlates to throughput (dev/test, general apps). - gp3: General purpose with independent performance needs; databases with steady IOPS but moderate durability needs. - io2: High-performance OLTP, large DBs, enterprise workloads needing high durability and consistent low latency.

Choosing for a highly transactional OLTP DB (steady high IOPS, low latency)1. Clarify requirements: required sustained IOPS (e.g., 10k), throughput (MB/s), latency target (<5 ms), capacity, RTO/RPO, budget.2. Decision rules: - If sustained IOPS ≤ 16k and budget-sensitive: choose gp3 and provision IOPS and throughput to match needs (cheaper than enlarging gp2). - If IOPS > 16k, need the highest durability, or strict SLA/consistency: choose io2 (or io2 Block Express).3. Sizing example: - Need 10,000 IOPS and 250 MiB/s throughput with 1 TiB storage: - gp3: provision 10,000 IOPS and 250 MiB/s, set size to required capacity (1 TiB). Cost = GiB + IOPS + throughput. - io2: provision 10,000 IOPS if you need higher consistency/durability; expect higher cost.4. Other considerations - Use provisioned IOPS snapshots/backup strategy (snapshots, multi-AZ/replication). - Monitor with CloudWatch, tune DB (connection pooling, query optimization) to reduce IOPS. - Consider instance EBS-optimized limits, NVMe/ENAs, and placement with provisioned IOPS.

Recommendation (cloud engineer perspective): for most steady high-IOPS OLTP where IOPS ≤ 16k and cost matters, pick gp3 and explicitly provision IOPS and throughput. If you require enterprise-grade durability/consistency or >16k IOPS, pick io2 (or io2 Block Express) despite higher cost.

HardTechnical

95 practiced

You must migrate a 20TB transactional PostgreSQL database to Amazon RDS for PostgreSQL with minimal downtime. Provide a detailed migration plan covering compatibility checks, initial bulk export/import or physical seeding, continuous replication (CDC), validation checks, cutover steps including DNS and application switch, rollback strategies, and AWS services or tools you would use to achieve minimal user-visible downtime.

Sample Answer

**Plan summary (goal: minimal user-visible downtime for 20TB Postgres → RDS for PostgreSQL)**

**1. Compatibility & prep**- Run AWS Schema Conversion Tool (SCT) and pg_dump --schema-only on prod to detect incompatible types, extensions, functions. - Inventory extensions; ensure RDS supports them or implement alternatives (use RDS extensions list). - Size IOPS, connections, parameter groups; provision RDS instance class, storage (gp3/io1) and parameter tuning.

**2. Initial bulk seed (physical + logical hybrid)**- Because 20TB is large, avoid full logical dump. Create a physical replica on EC2: - Stop/disable autovacuum checkpoints tuning temporarily. - Use pg_basebackup (streaming WAL) to provision an EC2 PostgreSQL replica in same AZ/VPC; apply WAL until caught up.- On EC2 replica, perform a consistent base backup export with pg_dumpall --schema-only for schema verification and pg_dump with parallel workers for data that’s feasible, or use file-level copy for base data to speed logical loads where possible.- Alternatively: use AWS DMS full-load from source to RDS in parallel tasks (recommended for schema+data at scale).

**3. Continuous replication / CDC**- Enable WAL level = logical on source (if supported), or use AWS DMS CDC with sensible task settings (batchApply, control table retention) or set up native logical replication (replication slots + publications) from source to RDS.- If using EC2 replica: set up logical replication from EC2 -> RDS (pglogical or native publication) to capture ongoing changes with minimal lag.

**4. Validation & testing**- Run row-count checks, checksums (md5 of sampled partitions), and query result comparison for critical business queries.- Use AWS DMS data validation feature and custom scripts. Monitor replication lag, error tables, and CloudWatch metrics.

**5. Cutover steps**- Schedule maintenance window. Put application into read-only or quiesce writes (if possible) briefly.- Final sync: pause writes, ensure replication applied all WALs; perform final WAL flush and promotion: - If AWS DMS: stop CDC, ensure no pending changes. - If logical replication: ensure subscription caught up, then promote RDS to primary endpoint.- Update application DB connection strings / secrets to point to RDS endpoint. Use Route53 CNAME or secret rotation in AWS Secrets Manager to switch endpoints atomically.- Monitor app and rollback window (30–60 minutes).

**6. Rollback strategy**- If rollback required, keep source DB writable and freeze switch: redirect traffic back to original DB endpoint; if DNS timed out, use application-config rollback. Maintain last WAL snapshots and backup to restore any lost transactions.- Plan backout runbook: cut traffic, verify source consistency, revert DNS/Secrets, re-enable writers.

**7. Tools & AWS services**- AWS SCT (schema), AWS DMS (full load + CDC), AWS CLI, CloudWatch, SNS, Route53, Secrets Manager, KMS/ IAM for security, EC2 for temporary replica, S3 for intermediate backups, EBS snapshots.

**8. Monitoring & post-cutover**- Monitor CloudWatch, pg_stat_replication, slow queries. Run performance tuning, analyze indices, and tune RDS parameter group.- Keep source for fallback until stable; decommission after verification.

This approach balances speed (physical seeding), reliability (CDC with DMS/native logical replication), and safe cutover with rollback paths and validation.

MediumTechnical

92 practiced

An EC2-hosted web server is showing sustained high CPU and slow response under moderate load. Outline a step-by-step troubleshooting plan using AWS tools and OS-level techniques to identify whether the problem is CPU-bound, IO-bound, memory-starved, or network-saturated. Provide short-term mitigations and long-term remediation options.

Sample Answer

**Situation & goal**Troubleshoot sustained high CPU and slow responses on an EC2 web server to determine whether it's CPU-, I/O-, memory-, or network-bound, then propose short-term mitigations and long-term fixes.

**Step-by-step troubleshooting**

1. AWS-level quick checks- Check CloudWatch EC2 metrics: CPUUtilization, CPUCreditBalance (T instances), DiskReadOps/Bytes, DiskWriteOps/Bytes, NetworkIn/Out, StatusCheckFailed.- Inspect CloudWatch Logs / ELB access logs / ALB target health for latency spikes and 5xx errors.- Use X-Ray (if instrumented) to find slow traces.

2. Connect and run OS-level diagnostics (via SSM Session Manager or SSH)- CPU:

bash

top -b -n1 | head -20
ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head

- I/O:

bash

iostat -x 1 3
iotop -o

- Memory:

bash

free -m
vmstat 1 5
ps aux --sort=-rss | head

- Network:

bash

ss -tunp
iftop -t -s 10
tcpdump -nn -s0 -c 200 port 80

- Kernel/locks: dmesg, sar, /proc/vmstat

3. Correlate timelines- Align CloudWatch metric spikes with OS metrics and application logs to identify root cause.

**Interpretation checklist**- CPU-bound: sustained high %cpu, user/kernel CPU growth, processes using CPU in top.- IO-bound: high await I/O, high DiskUtil, iostat showing high %util and tps, iotop shows heavy writers/readers.- Memory-starved: high swap usage, free memory low, OOM events in dmesg.- Network-saturated: high NetworkIn/Out, packet drops, socket backlog, ELB latency, tcpdump shows retransmits.

**Short-term mitigations**- CPU: scale out (add instances, increase ASG desired), throttle noncritical jobs, restart runaway processes.- I/O: move heavy I/O to separate volume, increase EBS throughput (switch to io2 or gp3 with higher IOPS), enable bursting or provisioned IOPS.- Memory: restart memory-hungry services, add swap (temporary), scale vertically (bigger instance).- Network: move to larger instance ENI limits, enable enhanced networking (ENA), use ALB/ELB to balance, reduce response size (gzip).

**Long-term remediation**- Autoscaling + health checks, right-size instances using CPU/Memory/IO profiles, use separate tiers (caching with ElastiCache, async processing with SQS + workers), optimize app (database query tuning, connection pooling), use provisioned EBS IOPS or EFS for shared storage, implement observability (CloudWatch dashboards, X-Ray, Prometheus/Grafana), run load testing and establish SLOs.

**Follow-up**Produce a timeline report with correlated metrics, root cause, action taken, and proposed changes (cost estimate + rollout plan).

EasyTechnical

75 practiced

What is Amazon CloudFront and what problems does it solve for global applications? Explain edge caches, TTLs, origin configurations (S3, ALB, custom), and how you can extend CloudFront behavior using Lambda@Edge or CloudFront Functions for low-latency customization at the edge.

HardTechnical

109 practiced

You must design the database tier for a global e-commerce app that requires strictly consistent inventory counts at checkout across regions. Evaluate options including RDS multi-AZ, RDS read-replicas, Aurora Global Database, DynamoDB global tables, leader-follower with single-writer and region-local caches. Recommend an architecture that provides correctness and explain the latency and complexity trade-offs.

Sample Answer

**Recommendation (short)** Use a single-writer, strongly-consistent architecture: place a single primary transactional DB for inventory (Aurora/RDS Multi-AZ writer) in one region and route all checkout (inventory-decrement/confirm) transactions to that writer. Serve reads from region-local read-replicas or caches for UX, but always validate/commit inventory via the primary writer. Use careful routing, retries, idempotency keys and regional proxies to control latency and correctness.

**Why this for strict correctness** - Strict consistency at checkout requires a single source of truth for the decrement/commit operation. Multi-master or async replication (Aurora Global, RDS read-replicas, DynamoDB global tables) can have replication lag that allows lost-competition races or oversell unless you implement complex distributed consensus.- A single-writer transactional DB guarantees ACID inventory updates and prevents oversell.

**Architecture sketch** - Primary region: Aurora (or RDS) writer Multi-AZ for HA. Transactional endpoints handle checkout decrement + order creation in one DB transaction. - Other regions: read-replicas for fast catalog/availability reads + region-local cache (TTL + cache-warm). - Global routing: regional API endpoints forward checkout requests to primary writer via private peered link / Global Accelerator / regional proxy; use gRPC/HTTP with retries and idempotency tokens. - Optional: local optimistic reservation (short TTL token) to reduce round-trips, followed by a guaranteed commit at primary.

**Latency vs complexity trade-offs** - Latency: every checkout requires a cross-region RTT to primary. Expect ~50–200 ms extra depending on region proximity and network; user-visible checkout latency increases. Optimizations: route to nearest edge and do async UI updates, show “reserving…” state, or implement fast local reservation + background commit. - Complexity: moderate. You must implement routing, idempotency, retries, and careful cache invalidation. HA is straightforward with Multi-AZ; cross-region failover of the primary writer requires planned promotion and DNS/route updates. - Alternatives considered: - Aurora Global / RDS read-replicas: good for read scale/DR, but replication is asynchronous — not safe for strict global consistency on writes. - DynamoDB Global Tables: eventual cross-region replication; while DynamoDB supports transactional writes per region, multi-region strong consistency isn’t available without single-writer pattern; multi-master risks conflicts. - True distributed consensus (RAFT/Paxos across regions): offers strong consistency but very high complexity and latency; typically overkill.

**Operational notes / best practices** - Implement idempotency tokens and exponential backoff to handle network blips. - Monitor replication lag, checkout latencies, and oversell metrics. - Provide a clear runbook for primary-region failover; test regularly.

This approach trades added checkout latency for deterministic correctness and lower operational complexity than building a geo-consensus database.

Unlock Full Question Bank

Get access to hundreds of Amazon Web Services Core Services interview questions and detailed answers.

Join thousands of developers preparing for their dream job.