모의고사 5

Maximum event age는 Lambda가 이미 비동기적으로 호출된 뒤 retry/discard 동작을 제어합니다. 동기 API Gateway 호출을 비동기로 바꾸지는 않습니다. 주의: 비동기와 관련된 Lambda 설정을 언급하지만 invocation type을 바꾸는 설정은 아닙니다.

몇 분 걸리는 REST API workflow에는 API Gateway timeout을 늘리는 것이 올바른 제어가 아닙니다. 해결책은 Lambda timeout을 기다리는 것이 아니라 요청을 분리하는 것입니다. 주의: 동기 경로를 늘리려 하지만 호출 패턴을 바꾸지 않습니다.

X-Amz-Target은 Lambda invocation type header가 아닙니다. API Gateway는 비동기 Lambda 호출을 요청하려면 X-Amz-Invocation-Type: Event를 전달해야 합니다. 주의: Header 이름이 AWS service integration 제어처럼 들리지만 Lambda invocation mode에는 잘못된 header입니다.

Parameter Store는 SecureString 값을 보관할 수 있지만, 이 선택지는 관리형 RDS/Aurora 자격 증명 rotation 기능이 아닌 일반적인 rotation 설정에 의존합니다. 주의: Aurora는 유지하지만 자동 데이터베이스 암호 rotation에 맞게 설계된 서비스를 놓칩니다.

워크로드는 DynamoDB가 아니라 Aurora PostgreSQL로 이전되고 있으며, Parameter Store는 관리형 데이터베이스 rotation에 가장 적합하지 않습니다. 주의: DynamoDB도 AWS 데이터베이스이지만 이 문제의 데이터베이스가 아닙니다.

Secrets Manager는 secret에 맞지만 DynamoDB는 명시된 Aurora PostgreSQL 클러스터 요구사항을 충족하지 않습니다. 주의: secret 서비스는 매력적이지만 데이터베이스 플랫폼이 틀렸습니다.

CloudFormation parameter는 template 암호화와 함께 사용하더라도 적절한 secret 배포 메커니즘이 아니며 stack 도구나 user data에서 여전히 잘못 다뤄질 수 있습니다. 주의: template을 암호화하면 보호되는 것처럼 보이지만 관리형 secret 조회를 제공하지 않습니다.

S3는 암호화된 객체를 저장할 수 있지만 bootstrap 중 secret을 다운로드하는 방식은 CloudFormation 네이티브 secret 확인이 아니며 객체 접근 노출을 추가합니다. 주의: S3는 내구성 있는 스토리지이지 이 요구사항의 secret manager가 아닙니다.

EFS는 공유 파일 시스템이지 secret 저장소가 아니며, secret을 위해 마운트하면 접근 범위와 운영 복잡성이 증가합니다. 주의: EFS 암호화는 저장 데이터를 보호하지만 CloudFormation 네이티브 secret 확인을 제공하지 않습니다.

plaintext data key를 저장하면 KMS의 보안 목적이 무너지고, encrypted data key는 local encryption key로 직접 사용할 수 없습니다. 주의: GenerateDataKey의 두 output을 모두 포함하지만 역할을 뒤바꿨습니다.

CiphertextBlob 저장은 맞지만 2~25 MB 파일을 암호화하는 데 KMS Encrypt를 사용하는 것은 잘못된 API pattern입니다. 주의: KMS 중심으로 들리지만 KMS Encrypt는 작은 blob용이지 multi-megabyte 파일 encryption용이 아닙니다.

plaintext key material을 저장하고 encrypted key를 KMS Encrypt와 함께 사용하려 하므로 저장과 encryption 단계가 모두 잘못되었습니다. 주의: GenerateDataKey와 KMS Encrypt를 언급해 공식적으로 보일 수 있지만 envelope encryption 기본을 위반합니다.

Gateway Load Balancer는 네트워크 appliance를 삽입하고 확장하기 위한 서비스이지, Lambda를 단순 HTTPS API로 노출하기 위한 서비스가 아닙니다. 주의: Gateway라는 단어가 API와 관련 있어 보이지만 이 서비스는 네트워크 appliance 문제를 해결합니다.

Network Load Balancer는 단순 서버리스 POST route를 위한 최소 구성 Lambda HTTP front end가 아닙니다. 주의: Load balancer도 애플리케이션을 노출할 수 있지만, 이 시나리오는 가벼운 Lambda endpoint를 요구합니다.

Global Accelerator는 기존 endpoint로의 라우팅 성능을 개선하지만 그 자체로 Lambda 함수를 HTTP로 노출하지는 않습니다. 주의: 공개 endpoint 성능을 개선할 수는 있지만 endpoint 서비스 자체가 아니라 추가 계층입니다.

메모리 증가는 CPU와 networking을 개선할 수 있지만, keep-warm invoke는 scaling이나 burst 중 충분한 initialized 환경를 보장하지 못합니다. 주의: scheduled warming은 일부 cold start를 줄일 수 있지만 결정적이지 않습니다.

initialization 최적화는 유용하지만 트래픽이 scale될 때 새 환경는 여전히 cold start될 수 있습니다. 주의: duration은 개선하지만 호출 전에 setup이 완료되어야 한다는 요구 사항은 충족하지 못합니다.

Reserved concurrency는 capacity를 보호하고 concurrency를 제한하지만 initialized 실행 환경를 만들지는 않습니다. 주의: Concurrency reservation은 provisioned concurrency와 자주 혼동됩니다.

IAM user의 long-lived access keys는 AWS 보안 모범 사례에 어긋나고 key rotation, 배포, 유출 위험 등 운영 부담을 늘립니다. ECS workload에는 role과 temporary credentials를 사용하는 것이 적합합니다. 주의: 기술적으로 동작할 수 있어 보이지만 least privilege와 낮은 운영 부담 요구에 맞지 않습니다.

AWS RAM은 일부 advanced Systems Manager parameter 공유에 사용할 수 있지만, 문제는 advanced tier나 RAM 관리 요구를 제시하지 않습니다. ECS task가 다른 계정의 parameter를 읽는 가장 표준적이고 넓게 적용되는 방식은 소유 계정의 role을 assume하는 것입니다. 주의: AWS RAM이 cross-account를 떠올리게 하지만 이 상황의 기본 패턴은 scoped IAM role assumption입니다.

S3로 내보내면 구성 데이터의 두 번째 복사본이 생기고, 동기화와 drift, 접근 제어, scheduled job 운영 부담이 늘어납니다. Dev-Render로 복사하지 말라는 의도와도 맞지 않습니다. 주의: S3는 공유 위치처럼 보이지만 복제와 운영 부담을 만들 뿐입니다.

Lambda 함수에는 Amazon EBS volume을 연결할 수 없습니다. EBS는 EC2 인스턴스용 block storage입니다. 이 임시 invocation별 워크로드에는 구성 가능한 ephemeral storage가 지원되는 로컬 저장소 선택지입니다. 주의: EBS는 고성능 저장소처럼 들리지만 Lambda에 연결할 수 없습니다.

Elastic Network Adapter를 Lambda 함수에 직접 연결할 수 없습니다. 또한 핵심 병목인 같은 대형 S3 객체를 반복해서 읽는 문제도 해결하지 못합니다. 주의: 네트워킹 용어가 더 단순한 로컬 저장소 최적화에서 주의를 돌릴 수 있습니다.

매번 S3에서 직접 읽으면 구현은 단순하지만 invocation마다 전체 네트워크 전송을 3-5번 수행합니다. 성능 최적화 설계는 바로 이것을 피해야 합니다. 주의: S3는 내구성과 확장성이 높지만 반복 full read는 피할 수 있는 지연을 더합니다.

Integration request template에서 $util.error를 발생시키는 것은 문서화된 mock integration selection 메커니즘이 아니며, 깔끔한 mock response 선택 대신 request template 처리 실패를 일으킬 수 있습니다. Mock integration은 response selection을 위해 statusCode 값을 출력해야 합니다. 주의: Selection pattern은 API Gateway에 실제로 있지만, 이 답은 mock statusCode mapping이 기대되는 곳에 error routing pattern을 적용합니다.

$context.responseOverride.status는 integration response가 존재한 뒤 response mapping context에서 사용합니다. 문제는 mock integration의 integration request mapping template 업데이트를 묻고 있습니다. 주의: Status override는 API Gateway 기능이지만 잘못된 단계에 배치했습니다.

Stage variables는 정적 구성 값입니다. 요청마다 method response status를 동적으로 선택하지 않습니다. 주의: Stage variables는 deployment parameter화에 사용할 수 있지만 요청별 response routing logic은 아닙니다.