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.

EasyTechnical

72 practiced

Explain IAM core concepts: users, groups, roles, policies, and permission boundaries. As a Solutions Architect advising a multi-team client, outline a least-privilege strategy that leverages roles, temporary credentials, and role assumption for cross-team and automation access.

Sample Answer

Users, groups, roles, policies, and permission boundaries (core concepts)- User: an identity for a human or service that can have long‑lived credentials (console/API). Best for individual account owner credentials.- Group: a collection of users for easier policy inheritance (no credentials), used to grant common permissions like "Developers".- Role: a describable set of permissions you can assume (no long‑lived creds). Used for cross‑account access, EC2/Lambda service access, CI/CD, or temporary elevated tasks.- Policy: a JSON document that grants or denies actions on resources (identity-based or resource-based). Attach to users, groups, or roles.- Permission boundary: a maximum permissions envelope an identity-based principal cannot exceed — it limits what an IAM entity can be granted, useful for delegating creation rights safely.

Least-privilege strategy (multi‑team + automation)1. Principle: give the minimum actions/resource scope and short duration.2. Roles for teams: create team-specific roles (e.g., dev-role, infra-role) with narrowly scoped policies using resource ARNs, tag conditions, and least privileges. Avoid attaching inline policies to users.3. Cross‑team access: enable cross‑account or cross‑team AssumeRole. Requesters assume the target role via STS:AssumeRole with MFA and logging. Use a deny-by-default approach and require context (source IP, aws:MultiFactorAuthPresent, aws:PrincipalTag).4. Temporary credentials & automation: require automation (CI/CD, lambda, EC2) to use roles (instance/profile, service role, or OIDC for GitHub Actions) that issue short-lived STS tokens. Set minimal session durations (e.g., 1 hour) and refresh tokens programmatically.5. Permission boundaries & guardrails: allow certain IAM admins to create roles but enforce permission boundaries so created roles cannot exceed approved scopes. Use SCPs (if Organizations) to enforce account-level guardrails.6. Operational controls: enable CloudTrail for AssumeRole/STS events, use IAM Access Analyzer, run periodic policy simulations, enforce tag-based access and least-privilege reviews, and require approval/workflow for elevated role creation.

Result: clear separation of duties, no long‑lived shared creds, auditable temporary access, and safe delegation via permission boundaries and role assumption.

HardTechnical

77 practiced

How would you proactively manage AWS service quotas and limits across 100+ accounts to prevent production impact? Describe automation using the Service Quotas API, quota-increase workflows, alerting when usage approaches limits, and architectural fallbacks when a quota is exhausted.

Sample Answer

Situation: Managing quotas across 100+ AWS accounts requires a combination of inventory, proactive automation, monitoring, governance and resilient architecture so production never fails silently when a limit is hit.

Approach (high level):1. Inventory & baseline- Run an account-wide inventory (AWS Config + Service Quotas ListServiceQuotas) to record current quotas, usage, and owner tags into a centralized datastore (DynamoDB/Config aggregator).- Maintain a desired-quota catalog per service (per environment: prod/non-prod) in SSM Parameter Store or a Git-backed config repo.

2. Automated quota-increase workflow- When usage trends/thresholds breach a policy (e.g., 70% of quota), trigger a Step Functions workflow: - Step 1: Check current quota via Service Quotas API (GetServiceQuota). - Step 2: Attempt programmatic increase using Service Quotas RequestServiceQuotaIncrease. - Step 3: If API returns manual-required, create a support case via AWS Support API and attach context (account, load history, expected growth). - Step 4: Post status to ticketing (Jira/ServiceNow) and notify owners (SNS/Slack).- Use cross-account IAM roles for the centralized automation account, least privilege for Service Quotas and Support APIs.

Example automation snippet (Lambda pseudo):

python

from boto3 import client
sq = client('service-quotas')
resp = sq.request_service_quota_increase(ServiceCode='ec2', QuotaCode='L-1216C47A', DesiredValue=200)

3. Monitoring & alerting- Emit quota usage metrics into CloudWatch (custom metrics) with tags for account, region, env. Use short-term and long-term trend detection (CloudWatch Anomaly Detection or Lookout).- Create alarms at multiple thresholds (70% warning, 85% action, 95% urgent) that trigger the Step Functions workflow and paging via PagerDuty.- Daily/weekly reports for capacity planning pushed to Slack/ops dashboard.

4. Governance & preventative controls- Enforce tagging and quota request guardrails via Service Control Policies and IAM permissions.- Require pre-approved quota increases for prod through an approval pipeline (IAM + Step Functions manual-approval step).

5. Architectural fallbacks when a quota is exhausted- Graceful degradation: feature flags to disable non-critical functionality.- Circuit breakers and throttling at the application layer (API Gateway usage plans, token bucket rate limiters) to protect downstream services.- Backpressure & retries: exponential backoff + jitter, idempotency.- Partitioning: distribute load across accounts/regions or use multi-tenant resource pools (e.g., multiple NAT Gateways, multiple S3 prefixes).- Capacity reservations and pre-warming: e.g., warm Lambda provisioned concurrency, pre-create ENIs/Elastic IP pools, reserved EC2 capacity if quota-bound.- Fallback service: degrade to cached data (DynamoDB DAX, CloudFront) or read-only mode.- Automated failover: if region quota exhausted, route traffic to another region/account with synced state.

6. Continuous validation & runbooks- Scheduled chaos tests: simulate quota exhaustion in non-prod to validate fallbacks and runbooks.- Runbooks with playbooks for manual escalation and rollbacks.- Quarterly reviews with stakeholders, capacity forecasting with growth models.

Trade-offs & reasoning:- Automated increases reduce manual toil but require governance to avoid runaway costs.- Centralized control simplifies visibility but must use cross-account roles to avoid privilege sprawl.- Architectural fallbacks add complexity but are critical for availability when AWS limits are reached unexpectedly.

Result:This approach provides proactive detection, automated remediation where possible, clear human workflows when needed, and resilient architecture so production remains available or degrades safely if a quota is exhausted.

EasyTechnical

116 practiced

Compare AWS Elastic Load Balancer types (Application Load Balancer, Network Load Balancer, Classic Load Balancer). For an HTTP/2 microservices API with WebSockets and TLS termination, which load balancer would you choose and why? Include considerations for cross-zone load balancing and IPv6.

HardTechnical

62 practiced

For a high-write DynamoDB workload that receives time-series data and periodic spikes, detail strategies to avoid hot partitions (e.g., composite keys, time-bucketing), choose between provisioned and on-demand capacity, leverage adaptive capacity, and design load tests to validate throughput and partition distribution.

Sample Answer

Requirements & goal: ingest high-write time-series with periodic spikes while avoiding hot partitions, keeping latency predictable and cost-effective.

Key strategies to avoid hot partitions- Partition key design: use composite key of (metricId, timeBucket) where timeBucket = epoch truncated to a window (e.g., minute/hour). This spreads writes across time-based partitions for same metric.- Add entropy for bursts: append a small shard id or hash suffix (e.g., metricId#tb#shard), rotate shard count based on expected peak QPS (start with 4–16).- Use write fan-out: buffer at producer (Kinesis/MSK) and parallelize writes across shards/clients to avoid single hot writer.- TTL + compacting: set TTL for old points and batch-compress low-value history to reduce storage hot-spots.

Provisioned vs On-demand- On-demand is simpler for unpredictable spikes and low steady-state—AWS handles scaling, but cost-per-write is higher.- Provisioned with auto-scaling is best when steady baseline is predictable and spikes are bounded: set baseline capacity to cover 95th percentile, then use AWS Application Auto Scaling and scheduled/step scaling for expected spikes. Combine with burst buffers (SQS/Kinesis) to smooth spikes.

Leverage Adaptive Capacity- Rely on DynamoDB adaptive capacity to redistribute throughput from idle partitions to hot ones, but don’t depend on it as the only mitigation for sustained hot keys. It helps short-lived imbalances; design keys to avoid single-key sustained hot writes.

Load-testing plan- Simulate at producer layer (Kinesis or direct writers) reproducing steady-state + spike patterns. Tests: - Baseline test: steady writes at expected avg QPS for 1–2 hours. - Spike test: 5–10x bursts of varying duration (10s, 1m, 10m). - Hot-key test: send concentrated writes to a single metricId to validate sharding behavior.- Metrics to capture: ProvisionedConsumedCapacity, ThrottledRequests, Latency (p99), partitionCount, CloudWatch WriteThrottleEvents, DynamoDB table read/write capacity units.- Validate partition distribution via DescribeTable (itemCount/size per partition via CloudWatch is limited—use adaptive metrics and custom instrumentation) and examine consumer-side retries and backoff behavior.- Iterate: if throttles occur, increase shards/time-bucket granularity, add buffering layer, or shift to on-demand.

Trade-offs & recommendations- Prefer provisioned + auto-scaling for predictable steady load (lower cost) + Kinesis buffering for spikes; use on-demand when workload is highly erratic or customer prefers operational simplicity.- Use small time-buckets with shard suffix to minimize hotspot risk; monitor and adapt shard count as usage evolves.

MediumTechnical

66 practiced

For a medium-sized startup with 30 microservices, evaluate the trade-offs between ECS Fargate and Amazon EKS (managed Kubernetes). Discuss cost, operational overhead, scaling, observability, ecosystem compatibility, and vendor lock-in, then recommend a path based on team skills and growth expectations.

Sample Answer

Start by clarifying constraints: 30 microservices, medium startup, AWS-first. Evaluate along requested dimensions and finish with a recommendation based on team skills and growth.

Cost- ECS Fargate: simpler billing model (vCPU + memory per task); no cluster EC2 management. For steady, high baseline load Fargate can be more expensive per vCPU than self-managed EC2. For variable or lower scale, reduced ops costs often offset higher unit price.- EKS: control plane managed (small fee) and node costs vary: managed node groups or spot/EC2 allow lower infra cost at expense of ops complexity. Total cost can be lower at scale.

Operational overhead- Fargate: minimal infra management, faster time-to-production, less ops staffing required.- EKS: more surface area—node management, upgrades, CNI, storage classes—requires SRE/K8s expertise and runbooks.

Scaling- Fargate: task-based autoscaling via ECS Service Auto Scaling and Application Auto Scaling; cold-starts predictable but can be slower.- EKS: richer primitives (HPA/VPA/KEDA) and finer control across pods, daemonsets; better for complex scaling patterns and bin-packing.

Observability- Fargate: integrates with CloudWatch, X-Ray, and third-party agents; limited access to host metrics.- EKS: full visibility into node/pod metrics, logs, and events; mature ecosystem (Prometheus, Grafana, Jaeger) and more advanced troubleshooting.

Ecosystem compatibility- Fargate: works well for standard container workloads and many AWS services; limited if you rely on Kubernetes operators, CRDs, service meshes advanced features.- EKS: full Kubernetes ecosystem—operators, Istio/Linkerd, ArgoCD, Kustomize—best for complex platform needs.

Vendor lock-in- Fargate/ECS: higher lock-in to AWS constructs (task definitions, ECS APIs).- EKS: Kubernetes API is portable; moving clusters across clouds or on-prem is easier, though cloud-specific addons can reintroduce lock-in.

Recommendation (based on team skills & growth)- If the team lacks Kubernetes/SRE expertise, is focused on rapid feature delivery, and expects moderate growth: choose ECS Fargate to minimize operational burden and speed time-to-market. Revisit after ~12–18 months or when traffic/costs justify platform investment.- If the team has existing K8s experience or plans sophisticated platform features (custom autoscaling, operators, multi-cloud portability) and expects significant scale/complexity: choose EKS with managed node groups, strong CI/CD (ArgoCD), and observability stack (Prometheus + Grafana + Jaeger). Start with a small control-plane pilot, automate upgrades, and standardize cluster patterns.

Hybrid path- Start with Fargate for most services and run a small EKS playground for platform-critical services (operators, stateful workloads). This hedges risk while building K8s expertise.

Key next steps- Run a cost model comparing expected vCPU/RAM usage on Fargate vs EC2 at 6–12 month projections.- Pilot one critical service on chosen platform and validate CI/CD, observability, and scaling.- Include runbook and staffing plan (on-call, upgrade cadence) in decision.

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.