모의고사 2

두 Lambda 함수를 직접 호출하면 수신 Lambda가 downstream 작업에 강하게 결합되고 concurrent request, retry, failure 전반에 대해 durable FIFO ordering을 제공하지 못합니다. 주의: 순차 호출은 제어되는 것처럼 보이지만 거의 동시에 들어오는 요청을 위한 신뢰성 있는 ordered queue를 만들지 않습니다.

SNS standard topic은 at-least-once delivery를 제공하지만 순서를 보장하지 않습니다. 같은 커넥터와 시간대의 나중 예약이 먼저 전달될 수 있습니다. 주의: fan-out은 지원하지만 standard SNS에는 first-received wins에 필요한 순서 보장이 없습니다.

단일 SQS queue는 각 message를 하나의 consumer에 전달하므로 같은 예약을 할당과 결제 workflow 모두에 자연스럽게 보내지 못합니다. standard queue는 순서도 보장하지 않습니다. 주의: SQS는 작업을 분리하지만 하나의 공유 queue는 두 processor 모두로 보내는 pub/sub fan-out이 아닙니다.

Lambda handler에서 filtering하면 동작은 가능하지만 모든 stream record마다 함수가 호출되고, 개발자가 filtering code를 작성하고 테스트해야 합니다. native event filtering보다 개발 노력이 더 큽니다. 주의: 기능적으로는 가능하지만 문제는 최소 개발 노력을 묻고 있습니다.

DynamoDB Streams는 SNS topic으로 직접 event source mapping을 만들지 않습니다. Lambda 함수나 다른 consumer가 stream을 처리하고 알림을 게시해야 합니다. 주의: SNS는 올바른 알림 대상이지만 DynamoDB Streams의 직접 event source mapping destination은 아닙니다.

CloudWatch alarm은 metric을 평가하며 개별 DynamoDB stream record attribute를 평가하지 않습니다. record별 Status와 TemperatureC 값을 검사해 일치하는 event만 게시할 수 없습니다. 주의: alarm은 운영 threshold에는 적합하지만, 이 문제는 content 기반 event routing입니다.

두 번째 API는 producer 변경이 필요하며, 향후 전용 함수도 그 API를 호출하도록 바꾸지 않으면 업데이트를 놓칩니다. 주의: 다른 endpoint는 단순해 보이지만 아카이브를 각 producer에 결합합니다.

Kinesis Data Streams만으로는 S3에 직접 전달하지 못하고 각 ingest Lambda에 게시 로직을 추가해야 합니다. 주의: Streaming은 가능해 보이지만 테이블이 이미 공통 변경 소스입니다.

Producer가 SNS에 게시하게 하면 현재 및 향후 모든 ingest 함수를 수정해야 하며 데이터베이스 수준 변경 캡처가 아닙니다. 주의: SNS fan-out은 알림에는 유용하지만 producer가 명시적으로 게시한 이벤트만 처리합니다.

AWS_PROXY와 Lambda는 status code와 JSON을 반환할 수 있지만 Lambda라는 compute service를 배포해야 하므로 명시 요구사항을 위반합니다. 주의: Lambda가 쉬워 보이지만 backend-free static API response가 핵심입니다.

HTTP_PROXY는 요청을 기존 HTTP endpoint로 전달합니다. 아직 backend가 없고 외부 placeholder API도 구축해야 하므로 요구사항을 충족하지 않습니다. 주의: API Gateway를 언급하지만 backend 없는 static response가 아닙니다.

Method Request는 request parameter, validation, authorization용입니다. Status code는 Method Response에 선언하고 Integration Response에서 생성 및 mapping해야 합니다. 주의: MOCK은 맞지만 response 구성 위치를 잘못 잡았습니다.

CloudFormation은 MSK Kafka topic과 ACL을 attach 가능한 네이티브 리소스로 모델링하지 않습니다. 주의: 선언적으로 들리지만 해당 Kafka 객체는 네이티브 CloudFormation 범위 밖입니다.

각 계정의 EC2에서 script를 실행하는 방식은 수동하고 지속 인프라가 무거우며 이후 일관된 업데이트에도 취약합니다. 주의: private 클러스터에는 도달할 수 있지만 지속적인 운영 부담이 늘어납니다.

단일 cross-account Lambda는 모든 private VPC로 복잡한 networking과 권한이 필요해 계정별 stack보다 관리하기 어렵습니다. 주의: 중앙화가 효율적으로 들리지만 private MSK networking에서는 취약합니다.

HTML을 response template에 두는 부분은 맞지만 integration response Content-Type을 application/json으로 구성하므로 HTML 요구사항을 위반합니다. 주의: 본문 위치가 일부 맞기 때문에 잘못된 Content-Type을 놓치기 쉽습니다.

HTML은 request template이 아니라 integration response template에 있어야 하며, mock request는 응답 선택을 위한 statusCode를 제공해야 합니다. 주의: text/html 응답 언급이 매력적이지만 내용이 integration의 잘못된 쪽에 있습니다.

HTML을 request template에 두고 application/json을 반환하므로 mock response 패턴과 필요한 content type을 모두 만족하지 못합니다. 주의: request에 text/html을 사용하는 것이 관련 있어 보이지만, 클라이언트는 response Content-Type을 봅니다.

private REST API는 구성된 VPC endpoint와 private network 경로에서만 접근할 수 있습니다. 사용자 디바이스에서 실행되는 React Native 앱은 일반적으로 private API를 직접 호출할 수 없습니다. 주의: key는 숨기지만 private API endpoint가 public 모바일 접근 요구와 맞지 않습니다.

private REST API와 Lambda를 결합한 선택지입니다. private API는 직접 모바일 클라이언트에 적합하지 않고, static header를 추가해 요청을 전달하는 데 Lambda는 불필요합니다. 주의: Lambda는 key를 숨길 수 있지만 비용을 추가하고 private endpoint 접근성 문제를 해결하지 못합니다.

public REST API와 Lambda를 사용해 key를 숨길 수는 있지만, API Gateway가 third-party HTTP API를 직접 proxy하고 필요한 header를 주입할 수 있을 때는 가장 비용 효율적인 선택이 아닙니다. 주의: 비밀성은 해결하지만 단순 header 전달 요구에 compute hop을 추가합니다.

PutObject에서 aws/s3를 지정하는 것은 server-side encryption입니다. 객체는 TLS로 보호되어 S3에 전송된 뒤 S3에서 암호화되므로, 전송 전에 file이 암호화된다는 보장은 하지 못합니다. 주의: AWS KMS를 언급하지만 핵심 요구사항은 task를 떠나기 전 client-side encryption입니다.

SSE-S3와 KMS GenerateDataKey를 혼합한 잘못된 설명입니다. SSE-S3는 KMS를 사용하지 않으며, GenerateDataKey를 사용한다면 client-side envelope encryption을 해야 합니다. 주의: SSE-S3와 GenerateDataKey가 보이지만 일관된 구현이 아닙니다.

customer managed KMS key를 upload request에 지정하면 SSE-KMS가 활성화되지만 여전히 server-side encryption입니다. plaintext object가 TLS로 S3에 전송된 뒤 저장 시 암호화되므로 전송 전 암호화 요구사항을 충족하지 않습니다. 주의: AWS KMS를 사용하지만 결정적 요구사항은 client-side encryption입니다.

buildspec은 이미 aws s3 sync를 사용하고 있고 S3 website endpoint에는 최신 파일이 있습니다. 주의: 업로드 단계를 반복해도 CloudFront 캐시는 지워지지 않습니다.

S3 객체를 제거하고 다시 배포해도 TTL 만료 전 CloudFront가 캐시된 응답를 버리도록 강제하지 못합니다. 주의: origin은 바뀌어도 CloudFront는 캐시된 객체를 계속 제공할 수 있습니다.

CORS는 브라우저의 cross-origin 접근을 제어하며, CloudFront가 오래된 HTML 또는 JavaScript를 제공하는지와는 관련이 없습니다. 주의: 증상은 cross-origin 요청 차단이 아니라 캐시 freshness입니다.