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

112 practiced

Write a Terraform (HCL) snippet that declares an S3 bucket configured with: server-side encryption using an AWS KMS key, versioning enabled, a lifecycle rule that transitions objects to Glacier Deep Archive after 365 days, and a bucket policy that denies public access while allowing a specific AWS account (account-id placeholder) read-only access. (You do not need to create the KMS key resource in the snippet; reference it by ARN.)

Sample Answer

**Approach (brief)**

Below is a Terraform HCL snippet suitable for a Cloud Architect: it creates an S3 bucket with KMS-based server-side encryption, versioning, lifecycle transition to Glacier Deep Archive after 365 days, explicit public-access-block, and a bucket policy that denies public access while allowing a specific AWS account read-only access.

**Terraform snippet**

hcl

variable "bucket_name" { type = string }
variable "kms_key_arn" { type = string }     # e.g. arn:aws:kms:us-east-1:123456789012:key/...
variable "trusted_account_id" { type = string }  # placeholder account-id

resource "aws_s3_bucket" "secure_bucket" {
  bucket = var.bucket_name
  acl    = "private"

  versioning {
    enabled = true
  }

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm     = "aws:kms"
        kms_master_key_id = var.kms_key_arn
      }
    }
  }

  lifecycle_rule {
    id      = "to-deep-archive"
    enabled = true

    transition {
      days          = 365
      storage_class = "DEEP_ARCHIVE"
    }

    noncurrent_version_transition {
      days          = 365
      storage_class = "DEEP_ARCHIVE"
    }

    abort_incomplete_multipart_upload_days = 7
  }
}

resource "aws_s3_bucket_public_access_block" "block" {
  bucket = aws_s3_bucket.secure_bucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_policy" "policy" {
  bucket = aws_s3_bucket.secure_bucket.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      # Deny anything that makes the bucket public
      {
        Sid = "DenyPublic"
        Effect = "Deny"
        Principal = "*"
        Action = "s3:*"
        Resource = [
          "${aws_s3_bucket.secure_bucket.arn}",
          "${aws_s3_bucket.secure_bucket.arn}/*"
        ]
        Condition = {
          Bool = { "aws:Public": "true" }
        }
      },
      # Allow specific AWS account read-only access (ListBucket + GetObject)
      {
        Sid = "AllowAccountReadOnly"
        Effect = "Allow"
        Principal = { AWS = "arn:aws:iam::${var.trusted_account_id}:root" }
        Action = [
          "s3:GetObject",
          "s3:GetObjectVersion"
        ]
        Resource = "${aws_s3_bucket.secure_bucket.arn}/*"
      },
      {
        Sid = "AllowAccountList"
        Effect = "Allow"
        Principal = { AWS = "arn:aws:iam::${var.trusted_account_id}:root" }
        Action = "s3:ListBucket"
        Resource = "${aws_s3_bucket.secure_bucket.arn}"
      }
    ]
  })
}

Explanation and rationale- Uses KMS (kms_master_key_id = kms_key_arn) to enforce SSE-KMS for stronger audit/control.- Versioning enabled to support object immutability/recovery.- Lifecycle moves both current and noncurrent objects to DEEP_ARCHIVE after 365 days.- Public access blocked at both bucket config and policy level; a specific account granted least-privilege read-only permissions.- As Cloud Architect, ensure the referenced KMS key policy and IAM roles in the trusted account allow decrypt/GetObject as needed.

MediumTechnical

74 practiced

Describe AWS S3 performance best practices to handle very high PUT/GET throughput (tens of thousands of requests per second). Discuss object key naming strategies, multipart upload, parallelism, S3 Transfer Acceleration, use of range GETs, and how S3 scaling behavior has evolved (prefix limits changes).

Sample Answer

**Overview (role framing)** As a Cloud Architect I design S3-heavy systems for tens of thousands RPS by combining smart key design, parallelism, multipart uploads, and network optimizations while relying on S3’s evolved autoscaling and resilient retry patterns.

**Object key naming strategies**- Avoid monotonically increasing prefixes (e.g., timestamp-first) that historically clustered requests. - Use hashed/randomized prefixes, UUID sharding, or natural fan-out (e.g., tenant-id/hash/objectid) to distribute load across internal partitions. - Prefer meaningful partitioning for lifecycle/queries while ensuring high cardinality at the first few characters.

**Multipart upload & parallelism**- Use multipart upload for large objects; choose part sizes (8–100+ MB typical) to balance concurrency and overhead. - Upload parts in parallel threads/processes; retry individual parts on failure. - For downloads, use parallel ranged GETs to fetch different byte ranges concurrently.

**S3 Transfer Acceleration & network**- Enable S3 Transfer Acceleration for high-latency/global clients to reduce RTT via AWS Edge -> optimized path. Cost vs benefit analysis required. - Use enhanced networking, VPC endpoints, and colocated EC2/EKS in same region to reduce latency for service-to-S3 traffic.

**Range GETs**- For very large objects or high read concurrency, split reads into range GETs to parallelize throughput and reduce per-request latency; reassemble client-side.

**Scaling behavior & prefix limits evolution**- Historically S3 had recommended per-prefix request guidance; since 2018 S3 automatically scales to handle very high request rates per prefix and removed strict per-prefix limits. Still, good key distribution reduces hotspots and variability.

**Operational best practices**- Use exponential backoff and jitter for retries, instrument with CloudWatch metrics (RequestCount, 4xx/5xx, 4xx/5xx per key), enable S3 server access logs or CloudTrail for hotspots, and load-test (e.g., s3-perf) to validate architecture.

MediumSystem Design

71 practiced

Design a disaster recovery (DR) strategy between two AWS regions for an RDS-backed application with RTO <= 15 minutes and RPO <= 1 hour. Discuss replication options (cross-region read replicas, Aurora Global Database, backups), failover automation, Route53 DNS considerations, recovery testing, and cost trade-offs for hot/warm/cold standby models.

Sample Answer

**Approach (requirements)** RTO ≤ 15 minutes, RPO ≤ 1 hour — prioritize replication with automated promotion and fast DNS cutover. Explain options, automation, testing, and cost trade-offs for hot/warm/cold.

**Replication options** - Cross‑Region Read Replica (RDS MySQL/Postgres): continuous async replication, can be promoted to standalone writer. Pros: familiar, lower cost than active-active. Cons: replication lag can exceed RPO under heavy write load. - Aurora Global Database: purpose-built for cross‑region low‑lag replication (typically <1s- a few seconds) and fast secondary region recovery via fast cutover. Best for tight RPO/RTO. - Backups/Snapshots: automated snapshots + copy to other region for point-in-time restore (PITR). Good for cold DR, not suitable alone for 15m RTO.

**Failover automation** - Primary mechanism: promote cross‑region replica (RDS promote-read-replica) or perform Aurora secondary region failover (managed by AWS). - Orchestrate with CloudWatch Alarms → EventBridge → Step Functions/Lambda to: validate target, promote DB, update parameter groups, wait for replica status OK. - Route53 health checks and failover routing policy or weighted routing with active health checks to switch traffic. Use automated scripts to update records via API if health checks indicate failure.

**Route53 / DNS considerations** - Use low TTL (60–300s) on application endpoint records to meet 15m RTO. - Prefer alias records to ALB or CloudFront in front of app. If using private endpoints, use Route53 private hosted zone with conditional forwarding. - Implement health checks (ALB + app /health) so DNS only switches when endpoints are healthy. Consider immediate weighted cutover + monitoring to rollback if unhealthy.

**Recovery testing & runbooks** - Maintain runbooks for automated/manual failover, promotion steps, credential rotation, and application config changes. - Quarterly DR rehearsals: promote replica, run smoke tests, measure RTO/RPO, then fail back. Include load tests to observe replication lag. Use blue/green-style rehearsals (pilot light) to avoid production risk. - Automate tests with CI pipelines that restore snapshots into a sandbox region.

**Cost / standby models (trade-offs)** - Hot (active-active multi-region or multi-master Aurora): highest cost, lowest RTO/RPO (minutes, seconds). Use when business-critical. - Warm (active/passive with cross‑region replica or Aurora Global standby): moderate cost. Meets RTO 15m and RPO 1h if replication lag is monitored and capacity reserved. Recommended balance for these SLAs. - Cold (backup-only snapshots, cross‑region copy): lowest cost, long RTO (hours), not suitable here.

**Recommendation (Cloud Architect)** For RTO ≤15m and RPO ≤1h choose Aurora Global DB if using Aurora (best RPO/RTO and automated cutover). If using RDS MySQL/Postgres, implement a continuously‑running cross‑region read replica with automated promotion workflow, Route53 low‑TTL failover, replication‑lag monitoring and quarterly DR drills. Include encryption, parameter sync, IAM policies, and cost/architecture reviews with stakeholders.

EasyTechnical

63 practiced

List S3 security best practices you would apply to protect sensitive data in S3 buckets. Include Block Public Access, bucket policies vs IAM policies, server-side encryption options (SSE-S3, SSE-KMS, SSE-C), enforcing TLS, VPC endpoints (gateway and interface) for private access, access logging, and auditing. Explain how you would securely allow functions in another account to read from the bucket.

Sample Answer

**Overview — goal:** Protect sensitive S3 data using defense in depth: deny public access, encrypt at rest, enforce secure transport, limit network exposure, and enable logging/auditing.

**Block Public Access**- Enable Account- and Bucket-level Block Public Access to prevent accidental ACL/policy public grants.- Keep ACLs off; prefer bucket policies/IAM for explicit access.

**Bucket policies vs IAM policies**- Use IAM policies for principal-scoped permissions (users/roles).- Use bucket policies for resource-scoped controls, cross-account access, or to enforce conditions (e.g., TLS required, VPC endpoints).- Prefer explicit deny in bucket policy for broad protections (deny s3:* if NotPrincipal is in-org, deny non-TLS, deny if public).

**Server-side encryption options**- SSE-S3 (managed keys): simple, S3 manages keys — good baseline.- SSE-KMS: use KMS CMKs for envelope encryption, key policies & IAM grants for fine-grained control, CloudTrail logs KMS usage — recommended for sensitive data.- SSE-C: customer-provided keys — operationally complex; avoid unless required.- When using SSE-KMS, grant decrypt to cross-account principals via KMS grants or key policy (avoid overly permissive key policies).

**Enforce TLS**- Add bucket policy requiring aws:SecureTransport = true to deny non-TLS requests.

**VPC endpoints (private access)**- Gateway endpoint (com.amazonaws.<region>.s3) for private S3 access from VPC — efficient, route table based.- Interface endpoint (PrivateLink) for control-plane features or when finer IAM/VPC security is needed.- Combine endpoint policy to restrict which buckets/actions are allowed from the VPC.

**Logging & auditing**- Enable S3 Server Access Logging (to a separate, locked bucket).- Enable CloudTrail data events for object-level logging.- Use AWS Config rules, GuardDuty, and Amazon Macie for sensitive-data discovery and drift/alerting.- Retain logs in WORM/immutable storage and protect with separate KMS key.

**Cross-account read for functions**- Best practice: create an IAM role in the function account and let the function assume it. On the bucket: - Add a bucket policy allowing s3:GetObject to the role ARN, include condition aws:SourceAccount and aws:SourceArn (lambda ARN) to reduce spoofing. - If objects are SSE-KMS-encrypted, update KMS key policy to allow the role decrypt or grant a KMS grant. - Optionally require access only via a VPC endpoint by adding aws:SourceVpce condition. - Keep least-privilege (prefix-limited) and require MFA for sensitive admin actions.

**Additional controls**- MFA Delete for accidental/bad deletes (requires root + MFA).- Lifecycle policies to move/archive sensitive data.- Periodic access reviews and automated remediation (Config + Lambda).

This approach gives layered protection: deny-by-default, encryption, network isolation, logging, and careful cross-account grants with KMS integration.

HardSystem Design

59 practiced

Design a cost-optimized architecture to run large batch processing jobs on unpredictable bursts of compute demand. Use S3 for data staging and consider Spot instances, AWS Batch or ECS, checkpointing of work items, handling Spot interruptions, and fallback to on-demand capacity. Explain orchestration, data locality, retry behavior, and monitoring for job completion.

Sample Answer

**Solution summary (requirements & goals)** Design a cost-optimized, resilient batch system using S3 for staging, Spot for low cost, automatic fallback to On‑Demand, checkpointed work items, and observability for completion.

**High-level architecture** - S3: input shards + output sinks + per-job manifest. - Orchestrator: AWS Step Functions (or Lambda + Step Functions) to coordinate job phases. - Compute: AWS Batch with Compute Environments using mixed instance types: Spot first (capacity-optimized/lowest-price), On‑Demand fallback. Alternatively ECS Fargate with capacity providers. - Work queue/state: SQS for task dispatch; DynamoDB for durable checkpoint metadata and lease info. - Checkpoint storage: DynamoDB entries point to S3 object offsets or task indices.

**Orchestration & data flow** 1. Step Functions reads manifest, breaks job into tasks (shards) and enqueues SQS messages. 2. AWS Batch workers poll SQS, fetch input from S3, consult DynamoDB for last checkpoint, resume processing, write intermediate results to S3, update DynamoDB checkpoint atomically. 3. On task completion worker marks message done and emits success metric/event.

**Spot interruptions & checkpointing** - Workers handle SIGTERM/Instance Hibernate hook: on interruption, immediately persist current progress to S3 and update DynamoDB checkpoint, then requeue remaining work. - Task granularity tuned: tasks are short-lived (~minutes) or implement frequent micro-checkpoints (per N records) to bound rework. - Use DynamoDB conditional writes to ensure idempotent checkpoint updates.

**Fallback & capacity management** - AWS Batch Compute Environment configured with Spot allocation strategy and On‑Demand base/fallback; set min/desired/ max to allow scaling. - If Spot capacity constrained, Batch will allocate On‑Demand automatically; alert if cost delta large.

**Retry behavior & idempotency** - SQS visibility timeouts tuned to expected task duration with exponential backoff for transient errors. - Retry policy: limited attempts (e.g., 3) with dead-letter queue. - Workers designed idempotent: reprocessing reads checkpoint to resume rather than duplicating output.

**Data locality & performance** - Use instances in same AZs as S3 endpoints; enable S3 Transfer Acceleration or S3 multipart for large objects. - For high I/O, consider EBS or local NVMe scratch to cache hot data and stream back to S3.

**Monitoring & job completion** - CloudWatch metrics: tasks started/succeeded/failed, checkpoint age, SQS queue depth, Spot interruption metrics. - AWS Batch job statuses, Step Functions execution history, DynamoDB metrics and custom CloudWatch metrics emitted by workers. - Alerts: SQS depth > threshold, job stalled (no progress), cost anomaly. - Final aggregation step in Step Functions verifies all tasks succeeded (or dead-letter resolution), builds manifest of outputs in S3, and signals completion via SNS/Webhook.

**Trade-offs & cost controls** - Spot reduces cost but increases complexity (checkpointing, interruptions). - Tighter checkpoints reduce rework but add overhead. - Use Savings Plans/Reserved for predictable baseline; Spot for bursty delta. - Implement cost-alerting and per-job cost caps.

This design balances cost, resiliency, and operational observability appropriate for enterprise-scale bursty batch workloads.

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.