✅ 정답: C. Secrets Manager

AWS Secrets Manager는 database credentials, API key 및 기타 secret을 lifecycle 전반에 걸쳐 쉽게 rotate, 관리, 검색할 수 있게 해줍니다. 사용자와 application은 Secrets Manager API를 호출하여 secret을 가져오므로, 민감한 정보를 plain text로 hardcoding할 필요가 없습니다. Secrets Manager는 Amazon RDS, Amazon Redshift, Amazon DocumentDB에 대한 built-in integration을 통해 secret rotation 기능을 제공합니다.

❌ 오답 해설

A. Systems Manager - AWS 인프라에 대한 가시성과 제어를 제공합니다. 여러 AWS 서비스의 운영 데이터를 통합된 UI에서 볼 수 있고, 운영 작업을 자동화할 수 있지만, secret을 안전하게 저장하고 database credentials를 자동으로 rotate하는 기능은 제공하지 않습니다.

B. KMS - 암호화 key를 쉽게 생성·관리하고, 다양한 AWS 서비스와 application에서 사용할 수 있게 해줍니다. 하지만 KMS는 암호화 key 관리 서비스이지, secret을 저장하고 credentials를 자동 rotate하는 서비스가 아닙니다.

D. SSM Parameter Store - password, database string, license code 등을 parameter 값으로 안전하게 저장할 수 있는 계층적 스토리지를 제공합니다. 하지만 database credentials의 자동 rotation 기능은 지원하지 않습니다. 이것이 Secrets Manager와의 핵심 차이점입니다.

✅ 정답: IAM user access를 Billing and Cost Management console에서 activate해야 한다

기본적으로 IAM user는 AWS Billing and Cost Management console에 대한 접근 권한이 없습니다. account administrator가 사용자에게 접근 권한을 부여해야 합니다. 이를 위해 IAM user access를 Billing and Cost Management console에서 activate하고, IAM policy를 사용자에게 attach해야 합니다. IAM policy가 적용되려면 반드시 IAM user access activation이 선행되어야 하며, 이 activation은 한 번만 수행하면 됩니다.

❌ 오답 해설

사용자들에게 Billing 정보 접근을 제한하는 다른 policy가 있을 수 있다 - 주어진 use case에서 유추할 수 있듯이, 이는 올바른 원인이 아닙니다. 문제의 핵심은 IAM user access activation이 되지 않은 것입니다.

root user만 AWS Billing and Cost Management console에 접근할 수 있다 - 잘못된 설명입니다. AWS Billing and Cost Management 접근 권한은 위에서 설명한 대로 user activation과 policy를 통해 어떤 사용자에게든 부여할 수 있습니다.

IAM user는 AWS Billing and Cost Management에서 생성해야 한다 - IAM은 AWS account의 기능입니다. 모든 IAM user는 사용하려는 서비스와 관계없이 하나의 단일 장소(IAM)에서 생성되고 관리됩니다.

✅ 정답: 'Rolling with additional batch' deployment policy

AWS Elastic Beanstalk은 여러 deployment policy와 설정을 제공합니다. 적절한 deployment policy를 선택하는 것은 비즈니스 요구사항에 따른 tradeoff입니다. 이 방법에서는 Elastic Beanstalk이 추가 batch의 instance를 먼저 launch한 후 rolling deployment를 수행합니다. 추가 batch를 launch하는 데 시간이 걸리지만, deployment 전체 과정에서 동일한 bandwidth를 유지할 수 있습니다. 또한 availability 감소를 방지하며, Rolling 방법보다 deployment 시간이 더 길다는 단점이 있습니다. deployment 중에도 동일한 bandwidth를 반드시 유지해야 하는 경우에 적합합니다.

❌ 오답 해설

'Immutable' deployment policy - 더 느린 deployment 방법으로, 기존 instance를 업데이트하는 대신 항상 새로운 instance에 새 버전을 deploy합니다. deployment 실패 시 빠르고 안전한 rollback이 가능하다는 장점이 있습니다. 두 번째 Auto Scaling group이 환경에 launch되어 새 instance가 health check를 통과할 때까지 기존 버전과 함께 트래픽을 처리합니다. 하지만 비용 효율성 측면에서 Rolling with additional batch보다 비용이 더 많이 듭니다.

'All at once' deployment policy - 가장 빠른 deployment 방법입니다. 짧은 서비스 중단을 수용할 수 있고, 빠른 deployment가 중요한 경우에 적합합니다. 이 방법에서는 모든 instance에 동시에 새 버전을 deploy하므로, application이 사용자에게 일시적으로 unavailable 상태가 되거나 availability가 낮아질 수 있습니다. 고가용성 요구사항에 부적합합니다.

'Rolling' deployment policy - 한 번에 하나의 batch씩 instance에 deploy합니다. deployment 중 대부분의 bandwidth를 유지하며 downtime을 방지합니다. 하지만 문제의 use case는 높은 트래픽과 고가용성을 요구하므로, deployment 중에도 full capacity가 유지되어야 합니다. Rolling 방식은 일부 instance가 업데이트 중일 때 capacity가 줄어들기 때문에 Rolling with additional batch가 더 적합합니다.

✅ 정답: ALB access logs

Elastic Load Balancing은 load balancer로 전송된 request에 대한 상세 정보를 캡처하는 access log를 제공합니다. 각 log에는 request 수신 시간, client의 IP address, latency, request path, server response 등의 정보가 포함됩니다. 이 access log를 사용하여 트래픽 패턴을 분석하고 문제를 troubleshoot할 수 있습니다. Access logging은 Elastic Load Balancing의 선택적(optional) 기능으로, 기본적으로 비활성화(disabled) 되어 있습니다.

❌ 오답 해설

CloudTrail logs - Elastic Load Balancing은 AWS CloudTrail과 통합되어 있습니다. CloudTrail은 Elastic Load Balancing에서 사용자, role 또는 AWS 서비스가 수행한 작업의 기록을 제공합니다. CloudTrail은 Elastic Load Balancing API에 대한 모든 호출을 event로 캡처합니다. 즉, 어떤 API 호출이 이루어졌는지, API 호출의 source IP address, 누가 호출했는지, 언제 호출되었는지 등을 확인하는 데 사용됩니다. request의 latency나 client IP 패턴 분석 용도가 아닙니다.

CloudWatch metrics - Elastic Load Balancing은 load balancer와 target에 대한 data point를 Amazon CloudWatch에 publish합니다. CloudWatch를 사용하여 해당 data point의 통계를 time-series data(metrics)로 조회할 수 있습니다. 시스템이 예상대로 작동하는지 확인하거나 특정 metric을 추적하고 싶을 때 적합한 기능이지, 개별 request의 latency나 client IP를 분석하는 용도는 아닙니다.

ALB request tracing - HTTP request를 추적하는 데 사용할 수 있습니다. load balancer가 수신하는 각 request에 trace identifier가 포함된 header를 추가합니다. request tracing은 latency 관련 데이터를 분석하는 데는 도움이 되지 않습니다.

✅ 정답: S3 및 CloudWatch Logs integration 활성화

AWS CodeBuild는 사용자를 대신하여 함수를 모니터링하고 Amazon CloudWatch를 통해 metric을 보고합니다. 이 metric에는 총 build 수, 실패한 build, 성공한 build, build 소요 시간이 포함됩니다. build를 Project level과 AWS account level, 두 가지 수준에서 모니터링할 수 있습니다. log group에서 Amazon S3 bucket으로 log 데이터를 export하여 커스텀 처리 및 분석에 사용하거나, 다른 시스템에 로드할 수 있습니다. S3에 저장된 log는 Athena로 직접 query하여 분석할 수 있으므로 이 use case에 가장 적합합니다.

❌ 오답 해설

Amazon EventBridge 사용 - EventBridge를 CodeBuild와 통합할 수 있습니다. 하지만 이 문제에서는 log를 저장하고 query를 실행하는 것이 목적이므로, CloudWatch Logs와 S3 integration이 이 맥락에 더 적합합니다.

AWS Lambda integration 사용 - Lambda는 boto3 라이브러리를 사용하여 프로그래밍 방식으로 log를 읽는 데 좋은 선택입니다. 하지만 CloudWatch와 S3 integration은 이미 built-in으로 제공되며, 해당 use case를 관리하는 데 더 최적화된 방법입니다.

AWS CloudTrail을 사용하여 log를 S3로 전달 - AWS CodeBuild는 AWS CloudTrail과 통합되어 있으며, CloudTrail은 CodeBuild에서 사용자, role 또는 AWS 서비스가 수행한 작업의 기록을 제공합니다. CloudTrail은 CodeBuild의 모든 API 호출을 event로 캡처합니다. 이는 서비스 모니터링에 중요한 기능이지만, build 횟수, 성공/실패 비율, 소요 시간 등의 build metric을 분석하는 현재 시나리오에는 적합하지 않습니다.

✅ 정답: ASG가 EC2 instance를 terminate한다

동일한 수의 instance를 유지하기 위해, Amazon EC2 Auto Scaling은 Auto Scaling group 내의 실행 중인 instance에 대해 주기적으로 health check를 수행합니다. unhealthy instance를 발견하면 해당 instance를 terminate하고 새로운 instance를 launch합니다. Amazon EC2 Auto Scaling은 unhealthy instance를 terminate하기 위한 scaling activity를 생성한 후 terminate하고, 이후 terminate된 instance를 대체하기 위해 새로운 instance를 launch하는 또 다른 scaling activity를 생성합니다.

❌ 오답 해설

ASG가 EC2 instance를 group에서 detach하고, 계속 실행 상태로 둔다 - Auto Scaling group의 목표는 비정상 instance를 제거하고 대체하는 것입니다. 단순히 detach하고 실행 상태로 두는 것은 ASG의 목적에 맞지 않습니다.

ASG가 instance를 계속 실행하고 application을 재시작한다 - ASG는 application에 대한 제어 권한이 없습니다. ASG는 instance 수준에서만 관리하며, application의 재시작은 ASG의 역할이 아닙니다.

ASG가 root EBS drive를 format하고 User Data를 다시 실행한다 - 이런 동작은 발생하지 않습니다. ASG는 EBS drive의 format을 임의로 변경할 수 없으며, User Data는 instance 최초 부팅 시에만 한 번 실행됩니다.

✅ 정답 1: container image는 Lambda Runtime API를 구현해야 한다

container image를 Lambda에 deploy하려면, container image가 Lambda Runtime API를 구현해야 합니다. AWS open-source runtime interface client가 이 API를 구현합니다. 선호하는 base image에 runtime interface client를 추가하여 Lambda와 호환되도록 만들 수 있습니다.

✅ 정답 2: Lambda는 multi-architecture container image를 지원하지 않는다

Lambda는 multi-architecture base image를 제공합니다. 하지만 function용으로 빌드하는 image는 하나의 architecture만 target해야 합니다. Lambda는 multi-architecture container image를 사용하는 function을 지원하지 않습니다.

❌ 오답 해설

Lambda는 Windows 및 Linux 기반 container image를 모두 지원한다 - Lambda는 현재 Linux 기반 container image만 지원합니다. Windows 기반은 지원하지 않습니다.

Lambda Runtime API를 사용하여 container를 로컬에서 테스트할 수 있다 - 로컬에서 container를 테스트할 때는 Lambda Runtime Interface Emulator를 사용합니다. Runtime API가 아닌 Runtime Interface Emulator가 올바른 도구입니다.

Lambda function을 container image로 deploy할 수 있으며, 최대 크기는 15GB이다 - Lambda function을 container image로 deploy할 수 있는 최대 크기는 10GB입니다. 15GB가 아닙니다.

✅ 정답: Zonal Reserved Instances

특정 Availability Zone에 대해 Reserved Instance를 구매하면 이를 Zonal Reserved Instance라고 합니다. Zonal Reserved Instance는 capacity reservation과 할인을 모두 제공합니다. Capacity Reservation을 통해 특정 Availability Zone에서 Amazon EC2 instance에 대한 capacity를 임의의 기간 동안 예약할 수 있습니다. 이를 통해 Savings Plan이나 Regional Reserved Instance가 제공하는 billing 할인과는 독립적으로 Capacity Reservation을 생성하고 관리할 수 있습니다.

❌ 오답 해설

Regional Reserved Instances - Region에 대해 Reserved Instance를 구매하면 이를 Regional Reserved Instance라고 합니다. Regional Reserved Instance는 capacity reservation을 제공하지 않습니다. 할인만 제공합니다.

둘 다 / 둘 다 아님 - 위에서 설명한 대로, Zonal Reserved Instance만 capacity reservation을 제공합니다.

✅ 정답: API를 기존 stage 또는 새 stage에 redeploy한다

API를 생성한 후, 사용자가 호출할 수 있도록 반드시 deploy해야 합니다. API를 deploy하려면 API deployment를 생성하고 stage에 연결합니다. stage는 API의 lifecycle 상태(예: dev, prod, beta, v2)에 대한 논리적 참조입니다. API stage는 API ID와 stage name으로 식별됩니다. API를 업데이트할 때마다 기존 stage 또는 새 stage에 redeploy해야 합니다. API 업데이트에는 route, method, integration, authorizer 수정 및 stage 설정 이외의 모든 변경 사항이 포함됩니다.

❌ 오답 해설

개발자들이 API Gateway의 API execution component에 대한 IAM permission이 필요하다 - Amazon API Gateway API에 대한 접근 제어는 IAM permission으로 수행됩니다. deploy된 API를 호출하거나 API caching을 refresh하려면 API 호출자에게 API Gateway의 execution component에 대한 IAM 권한을 부여해야 합니다. 하지만 현재 시나리오에서 개발자들에게 필요한 것은 "execution component"가 아니라 API를 생성, deploy, 관리하는 데 도움이 되는 **"management component"**에 대한 권한입니다. 따라서 이 옵션은 올바르지 않습니다.

API 접근을 위해 Lambda authorizer 활성화 - Lambda authorizer(이전에는 custom authorizer)는 Lambda function을 사용하여 API에 대한 접근을 제어하는 API Gateway 기능입니다. 이 기능도 접근 제어에 도움이 되지만, 현재 시나리오에서 문제를 겪고 있는 것은 사용자가 아니라 개발자입니다. 접근 제어 문제가 아니라 변경 사항 반영 문제입니다.

API의 development state에 Stage Variables 사용 - Stage variables는 REST API의 deployment stage에 대한 구성 속성으로 정의할 수 있는 name-value 쌍입니다. 환경 변수처럼 작동하며 API 설정 및 mapping template에서 사용할 수 있습니다. Stage variables는 현재 use case에서 설명하는 시나리오와 관련이 없습니다.

✅ 정답: EBS volume은 AZ에 종속(locked)된다

Amazon EBS volume은 instance에 attach할 수 있는 내구성 있는 block-level storage device입니다. EBS volume은 유연하여, 현재 세대의 instance type에 연결된 현재 세대의 volume에 대해 live production volume에서 크기를 동적으로 증가시키고, provisioned IOPS capacity를 수정하고, volume type을 변경할 수 있습니다. EBS volume을 생성하면 단일 하드웨어 구성 요소의 장애로 인한 데이터 손실을 방지하기 위해 해당 Availability Zone 내에서 자동으로 복제됩니다. EBS volume은 동일한 Availability Zone에 있는 EC2 instance에만 attach할 수 있습니다. 따라서 us-east-1a에서 생성된 EBS volume을 us-east-1e의 instance에 attach할 수 없습니다.

❌ 오답 해설

EBS volume은 Region에 종속(locked)된다 - EBS volume은 Region이 아닌 Availability Zone에 종속됩니다. Region 단위가 아니라 더 좁은 AZ 단위로 제한됩니다.

필요한 IAM permission이 누락되어 있다 - IAM permission이 없는 경우도 가능성은 있지만, permission 문제가 아니더라도 여전히 AZ에 종속되어 있어 attach가 불가능합니다. 이 시나리오에서의 근본 원인은 AZ 불일치입니다.

EBS volume이 encrypted 되어 있다 - encryption 여부는 EBS volume을 attach하는 능력에 영향을 주지 않습니다.

✅ 정답: dynamodb:UpdateItem, dynamodb:GetItem

Amazon DynamoDB transaction을 사용하면 여러 action을 그룹화하여 단일 all-or-nothing TransactWriteItems 또는 TransactGetItems 작업으로 제출할 수 있습니다. AWS IAM을 사용하여 transactional 작업이 DynamoDB에서 수행할 수 있는 action을 제한할 수 있습니다. Put, Update, Delete, Get action에 대한 permission은 기본 PutItem, UpdateItem, DeleteItem, GetItem 작업에 사용되는 permission에 의해 관리됩니다.

핵심은 DynamoDB API의 UpdateItem action입니다. 이 action은 기존 item의 attribute를 편집하거나, item이 테이블에 존재하지 않으면 새 item을 추가합니다. attribute 값을 put, delete, add할 수 있으며, 기존 item에 대한 conditional update도 수행할 수 있습니다.

따라서 dynamodb:PutItem은 이 use case에 필요하지 않습니다. UpdateItem만으로 upsert 기능을 충분히 수행할 수 있으므로, IAM policy에는 DynamoDB 테이블에서 item을 get하고 update하는 permission만 포함하면 됩니다.

❌ 오답 해설

dynamodb:UpdateItem, dynamodb:GetItem, dynamodb:PutItem - PutItem은 불필요합니다. UpdateItem이 이미 item이 없을 때 새로 생성하는 기능을 포함하고 있으므로, 최소 permission 원칙에 위배됩니다.

dynamodb:AddItem, dynamodb:GetItem - dynamodb:AddItem이라는 DynamoDB IAM action은 존재하지 않습니다.

dynamodb:GetRecords, dynamodb:PutItem, dynamodb:UpdateTable - GetRecords는 DynamoDB Streams에서 사용되는 action이며, UpdateTable은 테이블 설정을 변경하는 action입니다. 이 use case와 관련이 없는 permission들입니다.

✅ 정답: 20

1개의 read capacity unit은 최대 4KB 크기의 item에 대해 초당 1회의 strongly consistent read를 나타냅니다. 4KB보다 큰 item을 읽어야 하는 경우, DynamoDB는 추가 read capacity unit을 소비합니다.

계산 과정:

1. Item Size ÷ 4KB (올림 처리)
   • 6KB ÷ 4KB = 1.5 → 2 RCU (per item)
2. item당 RCU × 초당 read 횟수
   • 2 × 10 = 20 RCU

❌ 오답 해설

10 - 6KB를 4KB로 나누지 않고 item당 1 RCU로 계산한 경우입니다. 4KB 초과이므로 올림 처리가 필요합니다.

30 - 잘못된 계산 결과입니다.

60 - eventually consistent read가 아닌 strongly consistent read이므로 2배로 곱할 필요 없습니다. 오히려 eventually consistent read가 strongly consistent의 절반의 RCU를 사용합니다.

✅ 정답 1: data producer가 exponential backoff로 retry하도록 구성

✅ 정답 2: 데이터 stream 내의 shard 수를 늘려 충분한 capacity를 제공

Amazon Kinesis Data Streams의 capacity 한도는 data stream 내의 shard 수에 의해 정의됩니다. data throughput 또는 PUT record 수로 인해 한도가 초과될 수 있으며, capacity 한도를 초과하면 put data 호출이 ProvisionedThroughputExceeded exception과 함께 거부됩니다.

• 일시적인 데이터 입력 비율 증가 → data producer의 exponential backoff를 통한 retry로 결국 요청이 완료됩니다.
• 지속적인 데이터 입력 비율 증가 → data stream 내의 shard 수를 늘려 put data 호출이 지속적으로 성공할 수 있도록 충분한 capacity를 제공해야 합니다.

❌ 오답 해설

KPL 대신 Amazon Kinesis Agent 사용 - Kinesis Agent는 data producer와 함께 작동합니다. KPL 대신 Kinesis Agent를 사용하는 것은 도움이 되지 않습니다. 제약 조건은 Kinesis Data Stream의 capacity 한도이지 producer의 종류가 아닙니다.

Kinesis Data Streams 대신 Amazon SQS 사용 - SQS를 사용한다고 해서 Kinesis Data Stream의 ProvisionedThroughputExceeded exception을 해결하는 데 도움이 되지 않습니다. use case의 문제를 근본적으로 해결하지 못하는 옵션입니다.

Kinesis enhanced fan-out 사용 - enhanced fan-out은 여러 consumer가 stream에서 병렬로 데이터를 검색하는 경우에 사용해야 합니다. 이 문제의 제약 조건은 stream의 capacity 한도(data input 측)이므로, consumer 측의 fan-out은 도움이 되지 않습니다.

✅ 정답: 하나의 SNS topic + filter policy

Amazon SNS topic은 통신 채널 역할을 하는 논리적 access point입니다. topic을 통해 여러 endpoint(AWS Lambda, Amazon SQS, HTTP/S, 이메일 등)를 그룹화할 수 있습니다.

기본적으로 Amazon SNS topic subscriber는 topic에 publish된 모든 message를 수신합니다. message의 일부만 수신하려면 subscriber가 topic subscription에 filter policy를 할당해야 합니다. filter policy는 subscriber가 수신할 message를 정의하는 속성이 포함된 JSON 객체입니다.

이 use case에서는 Lambda function이 특정 attribute가 포함된 message를 단일 SNS topic에 publish하고, 각 파트너의 topic subscription에 적절한 filter policy를 적용하면 됩니다. 새로운 파트너 추가 시에도 filter policy만 설정하면 되므로 확장성이 뛰어납니다.

❌ 오답 해설

각 파트너별로 별도의 SNS topic 설정 (2개 옵션 모두) - 각 파트너의 업데이트를 별도의 SNS topic으로 분리할 필요가 없습니다. 하나의 SNS topic에 서로 다른 filter policy를 적용하는 것만으로 충분합니다. 파트너가 늘어날 때마다 새 SNS topic을 생성해야 하므로 비효율적입니다.

각 파트너별로 별도의 Lambda function 설정 - 각 파트너마다 별도의 Lambda function을 생성할 필요가 없습니다. 하나의 공유 Lambda function으로 주문을 처리하고 단일 SNS topic에 업데이트를 보내는 것만으로 충분합니다. 파트너 추가 시마다 Lambda function을 만드는 것은 비효율적이며 확장성이 떨어집니다.

✅ 정답: Envelope Encryption을 사용하고 코드 내에서 file로 데이터를 참조

AWS KMS는 최대 4KB의 데이터를 직접 encrypt하는 것을 지원하지만, Envelope Encryption은 상당한 성능 이점을 제공합니다. AWS KMS로 데이터를 직접 encrypt하면 네트워크를 통해 전송해야 합니다. Envelope Encryption은 훨씬 작은 data key만 네트워크를 통해 요청 및 전달되므로 네트워크 부하를 줄입니다. data key는 application 또는 AWS 서비스에서 로컬로 사용되어, 전체 데이터 블록을 AWS KMS로 보내고 네트워크 latency를 겪을 필요가 없습니다.

AWS Lambda environment variable의 최대 크기는 4KB입니다. 또한 KMS의 직접 'Encrypt' API도 데이터 payload에 대해 4KB 상한이 있습니다. 1MB를 encrypt하려면 Encryption SDK를 사용하고, encrypted file을 Lambda function과 함께 패키징해야 합니다.

❌ 오답 해설

KMS direct encryption을 사용하고 file로 저장 - KMS direct encryption으로는 최대 **4KB(4096 bytes)**의 임의 데이터만 encrypt할 수 있습니다. 1MB 이상의 데이터에는 적합하지 않습니다.

Envelope Encryption을 사용하고 environment variable로 저장 - Lambda environment variable의 최대 크기는 4KB이므로, 1MB 이상의 데이터를 environment variable에 저장할 수 없습니다.

KMS Encryption을 사용하고 environment variable로 저장 - KMS direct encryption의 상한이 4KB이고, Lambda environment variable의 최대 크기도 4KB이므로, 두 가지 제약 모두에 걸립니다.

✅ 정답 1: cross-Region Read Replica 사용

source DB instance의 부하를 줄이는 것 외에도, Read Replica를 사용하여 production DB 환경에 대한 DR 솔루션을 구현할 수 있습니다. source DB instance가 실패하면 Read Replica를 standalone source server로 promote할 수 있습니다. Read Replica는 source database와 다른 Region에도 생성할 수 있으므로, 특정 Region의 가용성 문제가 발생해도 서비스를 복구하는 데 도움이 됩니다.

✅ 정답 2: 단일 AWS Region에 backup을 생성하는 automated backup 활성화

Amazon RDS는 Multi-AZ deployment를 사용하여 DB instance에 대한 고가용성과 failover를 지원합니다. Amazon RDS의 automated backup 기능은 database instance에 대한 point-in-time recovery를 가능하게 합니다. Amazon RDS는 database와 transaction log를 backup하고, 사용자가 지정한 retention period 동안 저장합니다. Multi-AZ 구성에서는 primary에 대한 I/O 영향을 줄이기 위해 standby에서 backup이 수행됩니다. Automated backup은 단일 AWS Region으로 제한되며, manual snapshot과 Read Replica는 여러 Region에서 지원됩니다.

❌ 오답 해설

multi-AZ deployment에서 여러 Region에 걸쳐 backup을 생성하는 automated backup 활성화 - 잘못된 설명입니다. Automated backup은 단일 AWS Region으로 제한됩니다. 여러 Region에 걸쳐 지원되는 것은 manual snapshot과 Read Replica입니다.

RDS Provisioned IOPS(SSD) Storage 사용 - Amazon RDS Provisioned IOPS Storage는 빠르고 예측 가능하며 일관된 I/O 성능을 제공하도록 설계된 SSD 기반 storage 옵션입니다. RDS database의 성능을 향상시키지만, disaster recovery 옵션이 아닙니다.

RDS DB cluster의 database cloning 기능 사용 - Database cloning은 Aurora에서만 사용 가능하며, RDS에서는 사용할 수 없습니다.

✅ 정답: 여러 origin으로 CloudFront를 구성

Amazon CloudFront는 .html, .css, .js, 이미지 파일 등 static 및 dynamic web content의 배포를 가속화하는 웹 서비스입니다. CloudFront는 edge location이라는 전 세계 데이터 센터 네트워크를 통해 content를 전달합니다. 사용자가 content를 요청하면 가장 낮은 latency를 제공하는 edge location으로 요청이 라우팅됩니다.

단일 CloudFront web distribution을 구성하여 여러 origin에서 다양한 유형의 요청을 처리할 수 있습니다. 예를 들어, static content는 S3 origin에서, dynamic content는 ALB origin에서 제공하도록 설정할 수 있습니다.

❌ 오답 해설

CloudFront의 Lambda@Edge 기능 사용 - AWS Lambda@Edge는 다양한 컴퓨팅 요구사항과 커스터마이징을 지원하는 범용 serverless compute 기능입니다. Lambda@Edge는 연산 집약적(computationally intensive) 작업에 가장 적합합니다. 단순히 static/dynamic content를 제공하는 이 use case와는 관련이 없습니다.

Global Accelerator 사용 - AWS Global Accelerator는 AWS의 글로벌 네트워크 인프라를 사용하여 사용자 트래픽 성능을 최대 60%까지 향상시키는 네트워킹 서비스입니다. 두 개의 고정 static public IP를 제공하며, 가장 가까운 healthy endpoint로 트래픽을 자동 re-route합니다. Global Accelerator는 non-HTTP use case(gaming/UDP, IoT/MQTT, VoIP) 또는 static IP address가 필요한 HTTP use case에 적합합니다. cacheable content와 dynamic site delivery에는 CloudFront가 더 적합합니다.

CloudFront의 Origin Groups 사용 - Origin Groups는 고가용성이 필요한 시나리오에서 origin failover를 설정하기 위한 것입니다. primary origin이 사용 불가능하면 자동으로 secondary origin으로 전환합니다. Origin Groups는 origin 장애 시나리오를 위한 것이지, 요청 라우팅을 위한 것이 아닙니다.