Comprehensive understanding of cloud compute options and how to choose between Amazon EC2, AWS Lambda, and managed deployment services such as Elastic Beanstalk. Candidates should be able to compare tradeoffs between control and operational overhead. Amazon EC2 provides full operating system level control, support for long running and stateful processes, custom machine images, fine grain instance sizing, placement groups for network and latency requirements, and suitability for legacy or specialized workloads. AWS Lambda provides a serverless event driven execution model with automatic scaling, per invocation billing, and minimal infrastructure management but introduces cold start latency, concurrency limits, execution duration limits, and resource constraints. Managed deployment services such as Elastic Beanstalk simplify application deployment and lifecycle management by abstracting infrastructure while still allowing configuration of underlying resources. Candidates should also know instance family characteristics for sizing such as burstable T series, general purpose M series, and compute optimized C series; pricing models including on demand, reserved capacity, savings plans, and spot instances; cost optimization techniques such as right sizing and spot use; and scaling and deployment patterns including auto scaling groups, function concurrency management, scheduled scaling, placement groups, and deployment strategies. Key design considerations include stateless versus stateful architecture, startup time impact, observability and monitoring, testing and deployment complexity, security and compliance, and how each option affects reliability, latency and cost.
MediumTechnical
75 practiced
After moving several Lambda functions into a VPC to access RDS, you observe significantly increased cold start latency. Diagnose the likely cause and propose mitigations that reduce cold starts while preserving secure access to the database. Include trade-offs for each mitigation.
Sample Answer
Likely cause (diagnosis)- When you moved Lambdas into a VPC, cold starts jumped because Lambda needs to attach network interfaces (ENIs) or configure Hyperplane networking for VPC access. Historically ENI creation (and ENI warm-up) adds seconds to cold start. Misconfigured subnets/security groups or insufficient IP capacity can amplify delays.Mitigations (with trade-offs)1) Use RDS Proxy (recommended)- What: Fronts DB connections, manages pooled connections; Lambdas can remain outside VPC or in minimal-VPC config.- Benefit: Reduces connection overhead, allows Lambdas to scale without exhausting DB connections, and reduces percold-start DB handshake time.- Trade-offs: Extra cost, single additional service to manage, requires IAM/auth changes.2) Keep Lambdas outside the VPC + use PrivateLink / RDS Proxy / Data API- What: Use RDS Proxy or AWS PrivateLink to access DB securely without full VPC attachment.- Benefit: Avoids ENI creation entirely -> much faster cold starts while preserving secure access.- Trade-offs: More networking setup (endpoints, cross-account networking), possible cost for PrivateLink.3) Provisioned Concurrency for critical functions- What: Keep a pool of warm execution environments.- Benefit: Eliminates cold-start latency for those functions.- Trade-offs: Direct cost proportional to provisioned capacity; doesn’t help every function unless scaled.4) Reduce VPC networking overhead- What: Place Lambdas in private subnets with sufficient IP space, use NAT Gateway sparingly, use AWS-managed VPC networking optimizations (ensure Lambda runtime has recent improvements).- Benefit: Lowers probability of lifecycle/network delay.- Trade-offs: Operational tuning required; limited impact vs. Proxy/Provisioning.5) Use Aurora Serverless / Data API (if using Aurora)- What: Use HTTPS Data API or serverless DB to avoid persistent TCP from function.- Benefit: No VPC ENI for DB access, simplified auth with IAM.- Trade-offs: May require application changes and different performance/price characteristics.Operational best practices- Ensure subnets have plenty of free IPs and Security Groups are minimal.- Monitor cold-starts, ENI creation times (CloudWatch) and DB connection utilization.- Combine approaches: RDS Proxy + keep high-throughput Lambdas with provisioned concurrency for best latency and cost balance.Recommendation summaryStart with RDS Proxy (quick win for connection & latency), use PrivateLink if you must keep Lambdas outside VPC, and add provisioned concurrency only for latency-critical functions. Each choice balances cost, complexity and operational overhead.
EasyTechnical
128 practiced
Explain the primary characteristics and ideal workloads for EC2 instance families: T (burstable), M (general purpose), C (compute-optimized), and R (memory-optimized). For each family describe typical use cases, how CPU/memory behave under sustained load, and one common sizing mistake teams make when selecting instance families.
Sample Answer
T (burstable)- Primary: Low baseline CPU with ability to burst using accrued CPU credits (T3/T4g with unlimited/burst options).- Ideal workloads: Development boxes, small web servers, CI runners, microservices, lightweight databases, and dev/test where occasional bursts are needed.- CPU/memory under sustained load: If sustained CPU > baseline, credits deplete and CPU throttles to baseline; memory is fixed and behaves normally.- Common sizing mistake: Choosing T-series for sustained high-CPU workloads (e.g., heavy background processing) and then encountering throttling and performance variability.M (general purpose)- Primary: Balanced vCPU-to-memory ratio for broad workloads (M5/M6).- Ideal workloads: Application servers, small-to-medium databases, caching layers, container hosts, web apps with steady mixed CPU/memory needs.- CPU/memory under sustained load: Both scale predictably; no credit system—performance is stable for sustained usage within capacity.- Common sizing mistake: Underestimating memory needs and picking a smaller M instance leading to OOMs despite sufficient CPU.C (compute-optimized)- Primary: Higher vCPU per GB RAM, faster CPUs, suitable for compute-bound tasks.- Ideal workloads: High-performance web servers, batch processing, scientific computing, real-time analytics, video encoding, high-concurrency API backends.- CPU/memory under sustained load: Excellent sustained CPU performance; memory can be relatively limited per vCPU.- Common sizing mistake: Picking C-series for memory-heavy applications (e.g., in-memory caches) and running into memory pressure.R (memory-optimized)- Primary: High memory per vCPU for memory-intensive workloads.- Ideal workloads: In-memory databases (Redis, Memcached), large caches, real-time big-data processing (Spark executors), and analytics that hold large working sets.- CPU/memory under sustained load: Memory remains abundant for sustained allocations; CPU capacity is moderate—sustained CPU ok but not as high as C-series.- Common sizing mistake: Choosing R-series for CPU-bound services where CPU throughput matters more than memory, wasting cost on unused RAM.Guidance: Match workload characteristics (burst vs sustained, CPU vs memory) to the family; validate with load tests and monitor CPU credits, CPU utilization, and memory/GC behavior before production sizing.
HardSystem Design
86 practiced
Design an architecture to ensure strong transactional consistency between an EC2-hosted payment service and a Lambda-based notification service that both write to the same DynamoDB table. Address how to guarantee no lost updates, idempotency for notifications, and failure handling when one service succeeds and the other fails. Discuss DynamoDB transactions and patterns for cross-service coordination.
Sample Answer
Requirements:- Strong transactional consistency between payment (EC2) and notification (Lambda) writes to the same DynamoDB table- No lost updates- Notifications are idempotent- Robust handling when one side succeeds and the other failsHigh-level approach (recommended): use DynamoDB transactional writes + outbox pattern + DynamoDB Streams → Lambda consumer. This guarantees atomicity for DB state and a durable notification intent, and gives exactly-once delivery semantics via idempotency keys and conditional writes.Architecture & flow:1. Data model (single table): - PK: paymentId - Sort keys/items: payment#<id> (payment state), outbox#<id> (notification intent) - Attributes: status, version (optional), outboxId, notificationPayload, notificationStatus, idempotencyKey, createdAt2. Payment service (EC2) — single transactional step: - Use TransactWriteItems to atomically: a) Update payment#<id> (set status CREATED→COMPLETED) with a ConditionExpression on version or expected status to avoid lost updates b) Put outbox#<outboxId> with notificationPayload, idempotencyKey, notificationStatus=Pending - If TransactWrite fails, no partial state is written. This prevents lost updates and guarantees the notification intent exists iff payment update committed.3. Notification delivery: - DynamoDB Streams emits the outbox# item insert. - Lambda (consumer) processes stream records, reads notification payload, and sends notification to downstream (email/SNS). - Before sending, perform an idempotency check: use the idempotencyKey stored in outbox and a conditional write to mark notificationStatus=Sent with a ConditionExpression notificationStatus = Pending (or use a sentAt + conditional write). - Only if the conditional update succeeds does Lambda actually send (or send optimistically but persist outcome with conditional write). This prevents duplicate sends across retries.4. Failure handling: - If payment TransactWrite succeeds but Lambda fails to send (or crashes), outbox remains Pending. Lambda retries (stream retry / DLQ). Implement exponential backoff and a DLQ for manual or automated compensating actions. - If payment TransactWrite fails, nothing is written and no outbox emits → no notification. - If notification send succeeds but marking Sent fails, Lambda must retry until the conditional update succeeds; use idempotent send (downstream providers should accept idempotencyKey) to avoid duplicates. - For escalations, a scheduled reconciliation job scans outbox items older than threshold in Pending and retries or alerts.Key patterns & guarantees:- DynamoDB TransactWriteItems ensures atomic write of business state + outbox item — prevents lost updates and guarantees notification intent is durable.- Optimistic locking via ConditionExpression/version prevents concurrent writers from clobbering state.- Outbox + Streams decouples business transaction from notification side effects while preserving atomicity.- Idempotency: include idempotencyKey in outbox and enforce conditional writes to mark Sent; also send idempotency headers to downstream services.- Exactly-once (practical): combined conditional update + idempotent external sends yields effectively-once delivery despite retries.Alternatives & trade-offs:- Two-phase commit across services is heavyweight; DynamoDB transactions + outbox is simpler and scales.- Synchronous notification inside payment transaction is possible only when notification target is a DB write; avoid external network calls inside DB transaction.- If notification must be strictly synchronous before returning to the client, perform blocking send after TransactWrite, but accept increased latency and complexity.Operational considerations:- Monitor Stream and Lambda retries, size of outbox table, and reconciliation job metrics.- Secure idempotencyKeys and use TTL to purge old outbox items after safe retention.- Test failure modes: EC2 crash after TransactWrite, Lambda partial failure, duplicate stream deliveries.This design provides strong consistency for DB writes, prevents lost updates, ensures idempotent notifications, and gives clear failure/retry paths suitable for production at scale.
HardTechnical
89 practiced
A third-party NPM package introduced into a Lambda webhook appears to be exfiltrating sensitive customer data. Describe immediate containment steps you would take (runtime, network, deploy, and access controls), a structured incident investigation plan, short-term code and permission changes, and long-term architectural and process changes to reduce risk from third-party dependencies.
Sample Answer
Immediate containment- Runtime: Immediately disable the affected Lambda (alias rollback to known-good version or switch traffic to a safe fallback). If using provisioned concurrency, scale to 0 or remove trigger.- Network: Remove outbound internet egress by attaching a VPC with no NAT gateway or apply egress-deny security group/NACL rules for that function; block suspicious remote hosts via firewall/NGW/IP lists.- Deploy: Revoke CI/CD deploy tokens for that repo/pipeline and freeze deployments for the service.- Access controls: Rotate service credentials used by the function (IAM keys, DB credentials), revoke any third-party OAuth tokens; enable short-term MFA and increase logging for privileged users.Structured incident investigation plan1. Triage: Record scope — which functions, customers, timeframe. Capture volatile data (function memory, temp /tmp, running metrics).2. Evidence collection: Preserve CloudWatch logs, X-Ray traces, deployment artifacts, package-lock.json, container images, and Lambda layers. Take immutable snapshots.3. Analysis: Static scan of deployed package versions, diff against known-good build, identify outbound endpoints and IOCs, review network flows (VPC flow logs) and DNS queries.4. Impact assessment: Determine data accessed/exfiltrated (S3, DB queries, environment variables), affected customers, regulatory impact.5. Remediation plan: Prioritized steps to remove malicious code, rotate secrets, notify stakeholders and legal.6. Post-incident review: Root cause, timeline, lessons, and update playbooks.Short-term code & permission changes- Replace the offending package: pin to vetted version or remove; rebuild from source with SBOM.- Enforce least-privilege: tighten IAM role to minimal permissions (no broad S3/* or SecretsManager read unless required).- Secrets: Move env secrets out of Lambda environment to encrypted secrets store with fine-grained access and short TTL.- Harden runtime: Add runtime integrity checks (hash verification of node_modules at startup) and denylist modules.Long-term architectural & process changes- Dependency management: Enforce SBOM, supply-chain scanning (Snyk, Dependabot, OSS review), and allowlist approved packages.- Build pipeline: Reproducible builds in isolated build farms, lockfile verification, and artifact signing; store signed artifacts in internal registry.- Network & runtime architecture: Place Lambdas in private subnets with controlled egress via proxy, implement egress gateways with TLS inspection/allowlist, and use dedicated execution roles per-function.- Observability & detection: Enhance telemetry (application-level logs, JSON structured logs, trace correlation), alerting for anomalous outbound traffic and unexpected env access.- Governance: Third-party risk policy, periodic audits, SBOM in procurement, security gates in PRs, and tabletop exercises with incident playbooks.- Culture: Developer training on secure dependency use and mandatory code reviews for dependency changes.Trade-offs and rationale- Immediate isolation minimizes further exfiltration at cost of short downtime; rebuilding and stricter IAM reduce blast radius long-term while requiring engineering effort. Prioritize containment, evidence preservation, and then recovery with least-privilege and supply-chain controls to prevent recurrence.
EasyTechnical
72 practiced
Describe AWS Spot Instances, including how interruptions are signaled and typical interruption modeling. Provide three practical strategies to safely utilize Spot instances to reduce cost (for stateless and checkpointable workloads) and give a concrete example of checkpointing or graceful degradation.
Sample Answer
AWS Spot Instances are spare EC2 capacity offered at significant discounts (often 70–90%) compared to On-Demand by taking the risk that AWS can reclaim that capacity. They’re ideal for fault-tolerant, flexible workloads.Interruption signaling:- AWS provides a two-minute termination/interrupt notice via the instance metadata endpoint (http://169.254.169.254/latest/meta-data/spot/termination-time) and via CloudWatch Events / EventBridge (Spot Interruption Warning).- When capacity is reclaimed, the instance gets the two-minute notice; for Spot Fleets/ASG, AWS may also partially terminate and rebalance.- Typical interruption modeling: interruptions follow supply/demand patterns—higher risk for large, single AZ capacity requests or older instance types; model with an expected interruption rate (e.g., % of hours interrupted per week) and use historical interruption frequency from AWS or your own telemetry.Three practical strategies to use Spot safely:1. Stateless scale-out (web workers, batch): run behind autoscaling groups (mixed instances: On-Demand + Spot). Use health checks and replace terminated Spot instances automatically; keep no local state.2. Checkpointable compute (distributed processing, ML training): design periodic checkpoints to durable storage (S3/EFS). Use the 2‑minute warning to flush in-flight work and persist progress. Combine with Spot and On‑Demand fallbacks in ASG lifecycle hooks.3. Graceful degradation with mixed capacity: run best-effort workers on Spot and critical ones On‑Demand. Implement job stealing—if Spot lost, remaining On‑Demand scale up to handle priority tasks.Concrete checkpointing example:A distributed data-processing job writes progress every N records to S3 with a manifest (job_id, shard, last_offset). On Spot termination notice, the instance atomically writes current offset and marks shard state as “paused.” A coordinator reads manifests and reassigns paused shards to healthy instances, which resume from the last_offset. This ensures minimal rework and uses Spot’s cost savings safely.
Unlock Full Question Bank
Get access to hundreds of EC2 Lambda and Managed Services interview questions and detailed answers.
