정답 · 해설

해설

【핵심 용어】 • Secrets Manager 회전 + Lambda 런타임 동적 조회: Lambda 버전이 고정되어도 시크릿은 항상 최신 • Parameter Store는 자동 회전 미지원 【정답 포인트】 정답: A (Secrets Manager + 회전 + 런타임 조회) 버전이 고정된 Lambda(별칭이 특정 버전 가리킴)도 호출 시 시크릿을 가져오므로 항상 최신 자격증명 사용. 2주 회전 자동화 가능. 【오답 체크】 • B: 코드에 자격증명 포함 = 보안 위반 + 매번 재배포 • C: 환경변수는 함수 버전과 함께 동결되어 이전 버전이 새 자격증명 못 받음 • D: Parameter Store는 자동 회전 기본 미지원

해설

【핵심 용어】 • SigV4 서명 위치 두 가지: ① HTTP Authorization 헤더 ② 쿼리 문자열의 X-Amz-Signature(presigned URL) 【정답 포인트】 정답: AD • A: Authorization 헤더에 서명 추가는 표준 방식 • D: presigned URL의 경우 X-Amz-Signature 쿼리 파라미터로 추가 【오답 체크】 • B: 세션 쿠키는 SigV4 표준 위치 아님 • C: 헤더 이름은 Authorization (Authentication 아님) • E: WWW-Authenticate는 서버→클라이언트 챌린지용

해설

【핵심 용어】 • AWS::SecretsManager::Secret: CloudFormation 리소스. GenerateSecretString 속성으로 보안 비밀 자동 생성 • Dynamic reference '{{resolve:secretsmanager:...}}': 다른 리소스에서 시크릿 값을 참조 【정답 포인트】 정답: D (Secrets Manager 리소스 + dynamic reference) CloudFormation 네이티브 리소스로 비밀 생성/저장/참조까지 모두 처리. 별도 Lambda 커스텀 리소스 불필요. 가장 적은 개발 노력. 【오답 체크】 • A: GetAtt로 비밀번호를 평문 노출하는 모델은 보안상 부적절(Lambda 응답 데이터에 비밀 포함) • B: CodeBuild로 비밀 생성 → 파이프라인 구성 추가 필요 • C: 커스텀 리소스 + Secrets Manager 결합은 D보다 노력 큼

해설

【핵심 용어】 • DynamoDB: NoSQL, 단일 자릿수 ms 지연으로 키-값/문서 조회 • 메타데이터 인덱싱: 파티션 키/GSI로 빠른 조회 【정답 포인트】 정답: A (DynamoDB) 메타데이터 + 단일 자릿수 ms 지연 = DynamoDB의 핵심 강점. 【오답 체크】 • B: EC2는 컴퓨팅 서비스, 데이터 저장 자체가 아님 • C: Lambda는 실행 환경 • D: RDS는 ms 단위 보장이 어렵고 인덱싱/스키마 부담

해설

【핵심 용어】 • Lambda@Edge: 반드시 us-east-1(N. Virginia)에서 생성/배포. 그 후 글로벌 엣지에 복제 • CloudFront 자체는 글로벌 서비스 【정답 포인트】 정답: B (Lambda@Edge는 us-east-1에서만 생성 가능) SAM이 eu-west-1에 배포되면 Lambda@Edge 생성 단계에서 실패. 이 함수는 us-east-1에서만 정의해야 함. 【오답 체크】 • A: CloudFront는 글로벌 서비스로 us-east-1 외에서도 'Distribution' 자체 생성 가능(엔드포인트 측면 글로벌) • C: 단일 SAM에 다중 Lambda는 가능 • D: CloudFront origin 제약 없음

해설

【핵심 용어】 • Write-through: DB 쓰기 시 캐시도 동시에 갱신 → 캐시 항상 최신, 실시간 대시보드 적합 • Lazy-loading: 읽기 미스 시에만 캐시 채움 → stale 가능성 • Write-behind: 캐시 먼저 쓰고 나중에 DB 반영 → 데이터 손실 위험 • Read-through: 캐시 미스 시 캐시가 직접 DB 조회 【정답 포인트】 정답: D (Write-through) 실시간 대시보드는 데이터의 최신성이 중요. Write-through는 모든 쓰기를 즉시 캐시에 반영하므로 stale 데이터 없이 즉시 조회 가능. 【오답 체크】 • A, C: Read/Lazy-loading은 미스 시 갱신이라 첫 접근 지연/stale 가능 • B: Write-behind는 비동기 쓰기로 일관성 위험

해설

【핵심 용어】 • Lambda Layer: 최대 250MB(unzip), 외부 라이브러리/공통 코드 분리 저장 • Lambda 패키지 크기 제한: 50MB(zip), 250MB(unzip) — Layer 사용 시 코드 본체 크기 절약 【정답 포인트】 정답: A (Lambda Layer) 100MB 외부 라이브러리는 Layer로 분리하면 함수 본체에서 빼고 공유 가능. 가장 적은 운영 부담. 【오답 체크】 • B: S3 버킷을 'mount'할 수 없음 → 오답 • C: /tmp는 512MB까지 가능하지만 콜드 스타트마다 다운로드 필요, 운영 부담 • D: EFS는 가능하지만 VPC 구성 + 마운트 설정 필요 → A보다 부담

해설

【핵심 용어】 • Elastic Beanstalk Immutable 배포: 기존 환경에 영향 없이 새 인스턴스에 새 버전 배포 → 헬스체크 통과 후 트래픽 전환 • 무중단 + 플랫폼 버전 변경 시에도 안전 【정답 포인트】 정답: C (Immutable 업데이트) 새 EC2에 코드+플랫폼을 함께 배포하고 헬스체크 통과 후 ELB 등록 → 0 다운타임. 플랫폼 버전 동시 변경에 적합. 【오답 체크】 • A: 환경 클론 후 URL 스왑은 가능하지만 환경 두 개 운영 시 비용↑, 동일 효과를 Immutable로 단일 환경에서 가능 • B: All-at-once는 다운타임 발생 • D: Rolling은 부분 인스턴스 사용 중에 새 코드 적용 → 일시적 혼합 트래픽

해설

【핵심 용어】 • Lambda 단위 테스트: 로컬 또는 CI에서 함수 코드 직접 호출 → SQS는 모킹/이벤트 페이로드로 시뮬레이션 • aws lambda invoke --payload <테스트 이벤트>: 배포된 함수에 테스트 이벤트 직접 호출 【정답 포인트】 정답: D (aws lambda invoke + 테스트 이벤트) SQS를 실제로 띄우지 않아도 SQS 이벤트 형태의 JSON을 invoke로 전달해 함수 동작 검증 가능. CI/CD에 가장 단순하게 통합. 【오답 체크】 • A: 매 빌드마다 CFN 스택 생성/삭제는 과한 부담 • B, C: 실제 SQS를 운영하는 통합 테스트로, 단위 테스트의 범위가 아님

해설

【핵심 용어】 • BatchGetItem: 한 번의 호출로 다수 키를 여러 테이블에서 조회 가능 → 네트워크 트래픽 최소화 • 단일 호출로 여러 테이블 데이터 가져오기 = BatchGetItem 【정답 포인트】 정답: A (한 번의 BatchGetItem으로 두 테이블 조회) BatchGetItem은 RequestItems 매개변수에 여러 테이블 키 셋을 동시에 지정 가능. 단일 네트워크 라운드트립으로 전부 조회. 【오답 체크】 • B: 여러 query를 N번 실행 → 네트워크 트래픽↑ • C: 두 번의 BatchGetItem 호출도 가능하지만, 한 번에 가능한 A가 더 효율적 • D: Scan은 모든 항목을 읽으므로 비효율

해설

【핵심 용어】 • API Gateway 스테이지: dev/test/prod 등 동일 API의 환경 분리 • 스테이지 변수(Stage Variables): 스테이지별로 다른 Lambda alias/ARN 등을 동적 라우팅 【정답 포인트】 정답: C (다중 스테이지 + 환경별 Lambda + 스테이지 변수) 전형적인 다중 환경 패턴. 스테이지 변수가 ${stageVariables.lambdaArn}으로 환경별 Lambda를 가리킴. 【오답 체크】 • A: 단일 스테이지에 쿼리 파라미터 분기 → 환경 격리/모니터링 어려움 • B: 단일 Lambda 안에 환경 분기 = 코드 복잡도↑ • D: 단일 스테이지/단일 Lambda 안에 환경 분기 → 환경 분리 미흡

해설

【핵심 용어】 • Lambda를 VPC에 연결하면 더 이상 인터넷에 자동 접속하지 않음. 사설 서브넷이라면 NAT Gateway 필요 • 사설 서브넷 + 인터넷 송신 = NAT Gateway(퍼블릭 서브넷에 위치) → IGW 【정답 포인트】 정답: C (NAT Gateway 통한 라우팅) Lambda가 사설 서브넷에 있으면 IGW로 직접 라우팅 불가(공인 IP 없음). NAT Gateway를 퍼블릭 서브넷에 두고 사설 서브넷의 0.0.0.0/0 라우팅을 NAT으로 보내야 인터넷 접근 가능. 【오답 체크】 • A, B: 기본 NACL/SG는 일반적으로 모든 아웃바운드 허용. 첫 점검 대상이 아님 • D: 사설 서브넷에 IGW를 직접 라우팅해도 동작하지 않음

해설

【핵심 용어】 • SSM Parameter Store Advanced 매개변수: 정책 기능 지원(Expiration, ExpirationNotification, NoChangeNotification) • Standard 매개변수: 정책 미지원 【정답 포인트】 정답: C (Advanced + Expiration + ExpirationNotification 정책) Advanced 매개변수만 만료/만료 알림 정책을 기본 지원. 가장 적은 운영 부담. 【오답 체크】 • A: Standard는 정책 미지원 • B, D: Lambda/EC2 cron으로 직접 구현은 운영 부담↑

해설

【핵심 용어】 • CodeDeploy Lambda 배포 전략: All-at-once / Linear (선형) / Canary (카나리) • Canary: 일부 트래픽 즉시 전환 → N분 후 나머지 전환 • 사전 정의 Canary 예: Canary10Percent5Minutes 【정답 포인트】 정답: D (Canary 10% 즉시 + 5분 후 전체 전환) 운영 시간(점검창) 내가 아닐 때도 다운타임 없이 빠르게 배포해야 하면서 노출 최소화 → Canary가 적합. Linear보다 빠르고 안전. 【오답 체크】 • A: in-place + 즉시 전환은 오류 노출 큼 • B: Linear 10%/min은 약 10분 소요 → 더 김 • C: All-at-once는 오류 노출 즉시 100%

해설

【핵심 용어】 • Secrets Manager: DB 자격증명 자동 회전 기본 지원, 회전 일정 설정 가능 • Parameter Store SecureString은 자동 회전을 지원하지 않음 【정답 포인트】 정답: B (Secrets Manager + 30일 회전) 자동 회전 + 안전한 비밀 저장 모범사례. 【오답 체크】 • A: 환경변수 = 평문 코드 외부 노출 • C: SecureString 매개변수 자동 회전은 기본 미지원 • D: S3에 자격증명 저장은 모범사례에 어긋남

해설

【핵심 용어】 • CodeBuild buildspec.yml: env.secrets-manager 또는 env.parameter-store로 외부 시크릿 참조 • Secrets Manager: 자동 회전 지원 【정답 포인트】 정답: C (Secrets Manager 환경변수 참조 + 자동 회전) 보안 + 자동 회전 = Secrets Manager. CodeBuild가 빌드 시 시크릿을 동적 주입. 【오답 체크】 • A: buildspec에 평문 하드코딩 = 보안 위반 • B: Parameter Store SecureString은 자동 회전 미지원 • D: 평문 환경변수 = 보안 위반

해설

【핵심 용어】 • API Gateway Mock Integration: 백엔드 없이 응답을 즉시 반환. HTTP 상태 코드/응답 메시지 시뮬레이션 가능 • 통합 응답에서 statusCode 매핑 【정답 포인트】 정답: A (단일 메서드의 Mock 통합에 분기 로직) 로직 한 번에 성공/오류를 모두 반환 가능. Lambda 없이 가장 적은 노력으로 통합 테스트. 【오답 체크】 • B: 두 개 리소스로 분리는 불필요한 중복 • C, D: Lambda를 만들면 API Gateway만으로 끝나는 일을 더 복잡하게 만듦

해설

【핵심 용어】 • Fargate에서 X-Ray: daemon은 별도 인스턴스가 없으므로 사이드카 컨테이너로 X-Ray daemon을 같은 태스크에 띄움 • X-Ray SDK는 Daemon에 UDP로 트레이스 전송 (X-Ray API 직접 호출 아님) 【정답 포인트】 정답: AD • A: Fargate는 EC2 호스트 접근 불가 → daemon을 사이드카로 배포. 태스크 역할에 X-Ray 권한 부여 • D: 앱은 X-Ray SDK로 계측, daemon에 트레이스 전송 【오답 체크】 • B: Fargate는 daemonset 개념(EC2/EKS) 사용 불가 • C: PutXrayTrace API를 앱에서 직접 호출하지 않음(SDK가 처리) • E: cloudwatch:PullLogs는 존재하지 않는 액션 + X-Ray와 무관

해설

【핵심 용어】 • 최소 권한 원칙: 정확한 액션, 정확한 리소스 ARN로 한정 • 단일 객체 읽기: s3:GetObject + arn:aws:s3:::DOC-EXAMPLE-BUCKET/doc.txt 【정답 포인트】 정답: A (정답 옵션이 텍스트로 비어 있지만 일반적으로 정답은 단일 GetObject + 정확한 객체 ARN을 가진 옵션) 원문은 표 형태로 정책 JSON을 보여주는데, ListBucket이나 와일드카드 없이 단 하나의 객체에 대한 GetObject만 허용하는 것이 최소 권한. 【오답 체크】 • 와일드카드 *(전체 버킷) 허용은 과도 • ListBucket 추가도 본 요구(단일 파일 읽기)에는 불필요 • 다른 액션(PutObject 등) 포함도 과도

해설

【핵심 용어】 • Rebase: 자기 브랜치를 기준 브랜치 최신 커밋 위에 재배치하여 깔끔한 히스토리로 충돌 해결 • Merge vs Rebase: rebase가 충돌을 한 번씩만 다루며 단계별 해결 가능 【정답 포인트】 정답: D (feature 브랜치를 main에서 rebase) 오래된 분기로부터 발생한 충돌은 rebase가 가장 깔끔. 새 브랜치 만들기/체크인 재시도보다 노력↓. 【오답 체크】 • A: 새 클론/새 브랜치는 변경분만 옮기는 추가 작업 필요 • B: 변경 적용을 수동으로 옮기는 작업 → 노력↑ • C: 시각화는 도움은 되지만 충돌 해결 자동화는 아님