모의고사 4

Regional에서 Edge-Optimized로 바꾸는 것은 클라이언트가 API Gateway에 도달하는 방식과 전역 사용자 지연 시간에 영향을 줄 수 있습니다. 하지만 Lambda proxy integration이 요구하는 응답 형식은 바뀌지 않습니다. Lambda가 성공한 뒤 일관되게 502가 나는 증상은 endpoint type보다 잘못된 integration 응답 형식과 더 잘 맞습니다. 주의: API Gateway 설정 변경처럼 보이지만, 결정적인 요구사항은 statusCode, headers, 문자열 body를 포함한 응답 객체입니다.

GET /shipments/{trackingId} 요청에는 일반적으로 요청 body가 없습니다. 또한 로그상 요청은 API Gateway를 지나 Lambda 함수까지 도달했고 Lambda도 성공적으로 완료되었습니다. 잘못된 클라이언트 payload라면 보통 호출 전 400 계열 오류나 mapping template 오류가 더 자연스럽습니다. 핵심은 요청이 아니라 응답 형식입니다. 주의: payload 형식이라는 표현이 그럴듯하지만, 결정적인 단서는 Lambda가 일반 문자열을 반환했다는 점입니다.

인증 문제는 Lambda를 호출하기 전에 API Gateway에서 처리되며 보통 401 Unauthorized 또는 403 Forbidden으로 나타납니다. 이 문제에서는 Lambda가 호출되고 성공적으로 완료되었으므로 요청은 integration까지 도달했습니다. 문제는 호출자 인증이 아니라 API Gateway가 Lambda 출력값을 해석하는 단계에서 발생합니다. 주의: Authorization header는 흔한 API 문제처럼 보이지만, 502와 성공한 Lambda 로그를 설명하지 못합니다.

Lambda alias는 traffic을 특정 version으로 보내지만, CloudFormation이 S3에서 새 ZIP을 가져오게 만들지는 않습니다. 주의: Alias는 배포에 유용해서 관련 있어 보이지만 S3 artifact 변경 감지 문제를 해결하지 못합니다.

Template도 변경되지 않는다면 다른 bucket은 필요하지 않습니다. 실제 trigger는 key/version 참조 변경입니다. 주의: Artifact를 옮기면 redeploy가 될 것처럼 보이지만 핵심 요구 사항은 template에 보이는 Code 변경입니다.

Code signing은 신뢰할 수 있는 package인지 검증하지만, 변경되지 않은 S3 참조를 CloudFormation이 다시 배포하게 만들지는 않습니다. 주의: 이는 배포 보안 기능이지 변경 감지 메커니즘이 아닙니다.

AuthType=NONE은 anonymous invocation을 허용하므로 핵심 보안 요구와 정면으로 충돌합니다. 또한 resource-based policy는 리소스에 연결하고 principal을 지정하는 것이지 IAM group에 연결하는 정책이 아닙니다. 주의: CLI 자동화는 맞아 보이지만, NONE auth type과 resource policy 연결 방식이 요구사항과 맞지 않습니다.

AWS_IAM auth type 자체는 맞지만 340개 별도 identity-based policy를 만드는 것은 불필요한 운영 부담입니다. identity-based policy는 group ARN을 principal처럼 참조하는 방식이 아니라 group, user, role에 연결하는 방식입니다. 주의: AWS_IAM을 고른 점은 맞지만, 권한 모델과 대규모 운영 방식이 어긋납니다.

AuthType=NONE은 anonymous access를 허용하며, IAM group ARN을 Lambda resource policy principal처럼 쓰는 것도 올바르지 않습니다. 따라서 보안 요구와 IAM 정책 모델을 모두 만족하지 못합니다. 주의: 함수별 resource policy가 세밀해 보이지만 anonymous access를 열고 group principal을 잘못 사용합니다.

Lambda는 mock JSON과 다양한 HTTP status code를 반환할 수 있지만 compute 비용과 코드 패키징, IAM, logging 같은 운영 부담이 생깁니다. 요구사항은 backend integration과 compute/VPC 비용이 없는 방식입니다. 주의: Lambda proxy integration이 쉬워 보이지만 backend 없는 MOCK 요구에는 과합니다.

EC2와 ALB는 서버 운영, 비용, 패치, scaling 고려가 필요합니다. 정적 응답을 빠르게 게시하려는 요구와 compute 비용 없음 조건을 모두 위반합니다. 주의: HTTP mock server를 세울 수는 있지만 API Gateway가 native로 처리할 수 있습니다.

HTTP_PROXY에는 실제 upstream endpoint가 필요하므로 backend 의존성이 생깁니다. 또한 Lambda layer는 Lambda 함수에 연결하는 것이며 API Gateway에 직접 붙이는 구성 요소가 아닙니다. 주의: proxy와 Lambda layer 개념을 섞어 놓은 선택지입니다.

customer managed KMS key는 키 생성, 정책, 권한, 관리를 필요로 하므로 AWS owned key 요구사항과 충돌합니다. 주의: 데이터는 암호화하지만, 고객 관리 부담이 가장 큰 키 옵션을 선택합니다.

alias/aws/dynamodb는 고객 계정의 AWS managed KMS key이며 AWS owned key가 아닙니다. 주의: AWS managed가 AWS owned와 비슷해 보이지만 서로 다른 키 소유 모델입니다.

고객은 AWS owned key를 만들거나 KMSMasterKeyId에 AWS owned key ARN을 제공할 수 없습니다. 주의: 필요한 키 유형을 반복하지만 해당 작업은 불가능합니다.

network rule은 맞지만 AWSLambdaBasicExecutionRole에는 Lambda가 VPC ENI를 생성하고 관리하는 데 필요한 EC2 권한이 없습니다. 주의: CloudWatch Logs 권한만으로는 Lambda VPC networking에 충분하지 않습니다.

VPC 구성 없는 Lambda 함수는 private Aurora IP에 직접 접근할 수 없으며, Lambda interface endpoint는 Lambda 서비스 API 호출용입니다. 주의: endpoint라는 단어가 private하게 들리지만 Lambda 런타임에서 Aurora로 가는 data path가 아닙니다.

execution role 정책만으로는 함수를 VPC subnet에 attach하지 못하고, Lambda API endpoint 역시 데이터베이스 connectivity를 제공하지 않습니다. 주의: VPC access 권한은 포함하지만 실제 VPC 구성이 빠져 있습니다.

Step Functions는 workflow orchestration을 정의하지만, 여기서 필요한 인프라 템플릿과 로컬 Lambda 이벤트 디버깅 workflow가 아닙니다. 주의: ASL은 state machine에는 유용하지만 이 문제는 주로 orchestration 문제가 아닙니다.

CloudFormation은 리소스를 정의할 수 있지만 별도 pipeline 생성은 기존 pipeline 요구사항을 위반하고 SAM local 편의 기능도 빠집니다. 주의: CloudFormation은 SAM의 기반이지만 option의 pipeline 접근이 잘못되었습니다.

SAM 자체는 적절하지만 CodePipeline 외부에서 배포하면 기존 pipeline stage 요구사항을 위반합니다. 주의: 자동화 script라도 out-of-band 배포입니다.

codecommit:Put*는 필요한 범위보다 넓고 관련 없는 write API를 허용할 수 있습니다. 요청된 정확한 branch permission set이 아닙니다. 주의: Wildcard write 계열은 pipeline을 동작하게 만들 수 있지만 least privilege에는 실패합니다.

codecommit:Update*도 광범위한 wildcard 계열이며 branch 생성 또는 삭제를 위한 명시적 permission이 아닙니다. 주의: Update라는 단어가 branch 변경과 관련 있어 보이지만 CodeCommit branch lifecycle은 이름이 정해진 action을 사용합니다.

codecommit:*는 전체 CodeCommit access를 부여하므로 임시 branch 생성과 삭제를 훨씬 넘어섭니다. 주의: Full access는 AccessDenied를 피하겠지만 전형적인 least-privilege 위반입니다.

sam package와 sam deploy는 resource를 AWS로 배포하고 console test는 배포된 함수를 실행합니다. 이는 local-only 요구사항과 모순됩니다. 주의: SAM은 관련되어 있지만 package/deploy는 local invocation이 아니라 deployment command입니다.

cdk deploy는 stack을 AWS에 프로비저닝하고 console test는 원격 Lambda 함수를 사용합니다. 문제는 배포 없이 노트북에서 테스트하라고 요구합니다. 주의: cdk synth는 필요하지만 cdk deploy는 잘못된 다음 단계입니다.

sam local start-lambda는 Invoke를 호출하는 client를 위해 Lambda service API를 emulate하는 endpoint를 시작합니다. 이벤트로 함수 하나를 한 번 실행하려는 경우 sam local invoke가 더 직접적입니다. 주의: local SAM command이지만 단일 함수 테스트 전용 명령은 아닙니다.