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

You need to design a DynamoDB table to support 10,000 writes/sec for a time-series event ingestion API. Explain the importance of partition keys, how to avoid hot partitions, capacity modes (provisioned vs on-demand), and strategies like write sharding and adaptive capacity. Provide one concrete schema suggestion for keys and indexing.

MediumTechnical

62 practiced

Describe how to securely store and rotate application secrets in AWS. Compare AWS Secrets Manager and AWS Systems Manager Parameter Store (SecureString) for rotation capabilities, cost, integration with Lambda/EKS/ECS tasks, and access control patterns. Provide an example of how an application running on EKS can retrieve rotated secrets securely.

Sample Answer

**Approach (short)** Secure secrets: store encrypted, enforce least-privilege access, automate rotation, audit access, and make apps retrieve secrets without embedding creds.

**Compare Secrets Manager vs SSM Parameter Store (SecureString)**

- Rotation capabilities - Secrets Manager: built-in automatic rotation with Lambda rotation templates, native credential lifecycle (RDS, etc.). Best for frequent/automated rotation. - SSM SecureString: no native rotation; you must implement custom Lambda/Step Function to rotate and update parameters.

- Cost - Secrets Manager: per-secret monthly fee + API calls. - SSM SecureString: free tier; lower cost (charges for API usage and advanced parameters if used).

- Integration with Lambda / EKS / ECS - Secrets Manager: native SDKs; ECS task definitions can reference secrets; Lambda can use environment variables via console integration. - SSM SecureString: SDK access and ECS/Lambda integrations via environment injection require custom steps (or Parameter Store support in ECS).

- Access control patterns - Both: store encrypted with KMS. Use IAM policies + resource policies. Prefer: - IAM roles (IRSA for EKS) for pod identities - KMS key policies restricting decrypt to specific roles - AWS CloudTrail for auditing

**EKS example: retrieve rotated secret securely**- Use IRSA: create IAM role allowing secretsmanager:GetSecretValue (or ssm:GetParameter) and annotate service account.- Pod uses AWS SDK to fetch secret at startup and cache; watch for rotation event (e.g., poll or use sidecar).

Example snippet (Go using Secrets Manager):

// assumes pod has IRSA role with secretsmanager:GetSecretValue
sess := session.Must(session.NewSession())
svc := secretsmanager.New(sess)
out, err := svc.GetSecretValue(&secretsmanager.GetSecretValueInput{SecretId: aws.String("my-app/credentials")})
if err != nil { log.Fatal(err) }
secret := *out.SecretString

**Recommended pattern**- Use Secrets Manager for automated rotation and credential lifecycle.- Use IRSA for EKS; restrict KMS decrypt to IRSA role; rotate via Secrets Manager Lambda; apps fetch at runtime or use a small sidecar that refreshes on rotation.

HardTechnical

94 practiced

Discuss DynamoDB Global Tables' conflict resolution and consistency model in multi-region, multi-master setups. If two regions write different values for the same item near-simultaneously, how are conflicts resolved, what consistency guarantees exist, and what application-level techniques help avoid or mitigate write conflicts?

Sample Answer

**Overview (short)** DynamoDB Global Tables use active-active (multi-master) replication across regions with asynchronous, multi-AP replication. Replication is eventually consistent across regions. When concurrent writes occur in different regions, DynamoDB resolves conflicts using a last-writer-wins (LWW) policy based on a per-item timestamp chosen by the service (the write with the later timestamp wins).

**Conflict resolution & consistency guarantees**- Conflict resolution: last-writer-wins (LWW) — the update with the larger system timestamp (from the originating region) wins during replication. There is no built-in merge of conflicting attribute changes.- Consistency: local reads in a region can be strongly consistent only if you use strongly consistent reads (regional) — but those are regional only. Global convergence across regions is eventual; there is no global strong consistency guarantee for simultaneous multi-region writes.

**Practical consequences**- Near-simultaneous writes can silently overwrite each other; you may lose an earlier write if its timestamp is older.- Transactions (TransactWriteItems) are atomic within a region and replicate, but they don’t provide global synchronous ordering across regions.

**Application-level techniques to avoid/mitigate conflicts**- Optimistic locking / versioning: add a version attribute and use conditional expressions (ConditionExpression: version = :v) to reject conflicting updates; retry on conditional failure.- Last-write metadata: include a client-generated timestamp or monotonic counter to control ordering and use it in conditional logic so you control LWW semantics.- Idempotency and dedup keys: clients include idempotency tokens so retries don’t create conflicting state.- Single-writer per key / sharding: partition keys so only one region or process owns writes for a given key (leader election or region-affinity).- CRDTs or mergeable data types: design values that can be merged (sets, counters, operational transforms) to avoid destructive overwrites.- Reconciliation/background repair: run periodic jobs that detect and merge divergent states using application logic.- Use TTLs / tombstones carefully when deletes could conflict with updates.

**Operational practices (DevOps focus)**- Instrument and alert on ConditionalCheckFailed and replication lag metrics (CloudWatch).- Run chaos tests to simulate cross-region conflicts and validate reconciliation.- Document region-affinity and data ownership for teams, and include conflict strategy in runbooks.

Example conditional update (conceptual):

sql

UpdateItem
Key: { id: "123" }
UpdateExpression: "SET value = :new, version = :newv"
ConditionExpression: "version = :oldv"

Adopting optimistic locking or single-writer patterns, plus monitoring and reconciliation, is the safest approach to prevent silent data loss in multi-region, multi-master DynamoDB deployments.

MediumSystem Design

62 practiced

Design a CI/CD pipeline on AWS for a containerized microservice: source in GitHub, build, container image registry, automated tests, and deploy to production on ECS or EKS. Describe which AWS services you would use (CodeBuild/CodePipeline or Jenkins on EC2), how you'd integrate ECR, how to handle credentials, approval gates, and rollback strategy for failed releases.

Sample Answer

**Overview & requirements clarification**- GitHub → build → container registry → automated tests → deploy to ECS/EKS → approvals & safe rollback.- Constraints: containerized microservice, AWS native preferred, secure creds, production approval.

**High-level architecture**- GitHub (webhook) triggers AWS CodePipeline.- CodeBuild builds Docker image, runs unit tests, pushes to Amazon ECR.- Integration tests run in a separate CodeBuild stage (or ephemeral ECS/EKS test namespace).- Manual approval action before prod.- Deploy to ECS (Fargate) via CodeDeploy (blue/green) or to EKS via ArgoCD/Flux or CodeBuild invoking kubectl/helm.

**Services & choices**- Use CodePipeline + CodeBuild + ECR + CodeDeploy for fast AWS integration and least ops.- Alternative: Jenkins on EC2/EKS if complex custom logic or existing investment.

**Credentials & secrets**- Use IAM roles for CodeBuild with least privilege to ECR, SSM Parameter Store/Secrets Manager for runtime secrets, and IRSA for EKS pods.- Store GitHub webhook secret and registry credentials in Secrets Manager; CodePipeline/CodeBuild assume roles via AWS-managed KMS keys for encryption.

**Image tagging & immutability**- Tag images with semantic + build id/sha (e.g., service:v1.2.3-commitsha).- Set lifecycle policy in ECR to remove old images.

**Approvals & gating**- Pipeline stages: Source → Build (unit tests) → Push to ECR → Integration tests → Manual approval → Staging deploy (smoke tests) → Prod deploy.- Use CodePipeline manual approval or SNS/Slack integration for on-call approvals.

**Deployment strategy & rollback**- ECS: Use CodeDeploy blue/green with traffic shifting and health checks on ALB; automatic rollback on failed health checks or alarms.- EKS: Blue/green or canary via Argo Rollouts / Flagger + Service mesh Istio/Linkerd; use readiness/liveness probes and Prometheus alerts to trigger automated rollback.- Maintain a quick rollback path: keep last stable image tag and a pipeline action that re-deploys it automatically on failure or via runbook.

**Observability & verification**- Integrate CloudWatch logs/metrics, X-Ray, and Prometheus/Grafana for EKS.- Gate deployment on successful smoke tests and monitoring alarms for error rate/latency; trigger rollback and notify via SNS/Slack.

**Trade-offs**- CodePipeline reduces maintenance; Jenkins offers flexibility/custom plugins. For AWS-first environments, native services speed delivery and improve security.

HardSystem Design

63 practiced

Design a high-throughput streaming ingestion pipeline on AWS that reliably ingests millions of events per minute, processes them, and writes aggregates to DynamoDB (for fast lookups) and raw archives to S3. Compare Kinesis Data Streams vs Amazon MSK (Kafka) for this workload and discuss ordering, at-least-once delivery, shard/partition planning, and downstream scaling.

Sample Answer

**High-level design**- Ingest layer: API Gateway / ALB → fleet of producers (SDK clients) → streaming tier (Kinesis Data Streams or Amazon MSK).- Processing: horizontally scaled consumers (Kinesis Client Library/Enhanced Fan-Out Lambdas or Kafka consumers in ECS/EKS with Kafka Connect).- Outputs: aggregated results → DynamoDB (single-table, partition key = aggregate key + time-bucket), raw events → S3 (partitioned by date/hour/stream/shard).- Supporting: IAM, CloudWatch/Prometheus, KMS encryption, VPC for MSK, S3 lifecycle, DynamoDB autoscaling/On-Demand or provisioned with DAX if needed.

**Kinesis vs MSK Comparison**- Ordering - Kinesis: ordering per shard; use partition key to guarantee ordering for a key. - MSK(Kafka): ordering per partition; same strategy using partitioner.- Delivery semantics - Both provide at-least-once; consumers must be idempotent. Use dedupe keys (event-id) or write-after-read patterns.- Shard/Partition planning - Estimate throughput (million+ events/min → ~16k events/sec). Kinesis: 1 shard = 1MB/s ingest + 1000 TPS for writes; calculate shards, enable enhanced fan-out for parallel consumers. MSK: size partitions to match broker throughput and consumer parallelism; ensure replication factor 3 and appropriate broker count.- Downstream scaling - Kinesis: Lambda auto-scales per shard (one Lambda instance per shard) or use KCL with workers; add shards with resharding. Monitor IteratorAge, PutRecord throttling. - MSK: scale consumers horizontally; balance partitions across consumers; use Kafka Connect for DynamoDB (sink connector) and S3 (sink connector) with buffering and exactly-once-ish semantics via idempotent sinks.

**Reliability & Operational considerations**- Idempotency in DynamoDB: use conditional writes (attribute_not_exists) or upsert with version tokens; batch writes with exponential backoff.- Checkpointing: KCL/Kafka offsets committed after durable success; implement transactional commit for aggregates.- Monitoring & alerts: consumer lag, iterator age, throttling, CPU, GC, broker disk; automate scaling (shard splitting/merging or broker autoscaling) and use infrastructure-as-code (Terraform/CDK).- Cost/trade-offs: Kinesis simpler managed service; MSK offers richer ecosystem and throughput per broker but more ops (patching, brokers, ZK/Control Plane). Choose Kinesis for faster ops, MSK for large ecosystems/custom partitioning needs.

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.