정답 · 해설

해설

【핵심 용어】 • API Gateway 스테이지 변수: 스테이지마다 다른 Lambda alias/ARN, 다른 endpoint를 동적으로 매핑 【정답 포인트】 정답: D (각 버전을 고유 스테이지로 배포 + 스테이지 변수) 서로 다른 버전 테스트는 스테이지 분리가 표준. 【오답 체크】 • A: 헤더 기반 분기는 API 코드 복잡도↑ • B: Lambda authorizer는 인가 도구, 버전 라우팅이 아님 • C: 리소스 정책은 접근 제어, 버전 분리가 아님

해설

【핵심 용어】 • CodePipeline은 단계 순차 실행. 어느 한 단계 실패 시 파이프라인 종료 → 이후 단계 실행 안 됨 • 트리거 브랜치 잘못 → 파이프라인 미발동 【정답 포인트】 정답: AB • A: 변경이 main 브랜치에 안 됨 • B: 앞 단계 실패로 파이프라인 종료 【오답 체크】 • C: CodePipeline은 EC2 클러스터 사용 안 함(완전관리) • D: 'months 무수정'이라 갑자기 잘못됐을 가능성 낮음 • E: 권한도 같은 이유로 가능성 낮음

해설

【핵심 용어】 • SAM DeploymentPreference: Canary10Percent10Minutes(10% 즉시 + 10분 후 100%), Linear(...EveryNMinutes) • AutoPublishAlias: 새 버전 자동 발행 + alias 갱신 【정답 포인트】 정답: A (Canary10Percent10Minutes + AutoPublishAlias) 10% 즉시 + 10분 후 100% = Canary 사전 정의 타입. 【오답 체크】 • B: Linear는 점진적 비율 증가 • C: PreTraffic/PostTraffic은 옵션, AutoPublishAlias가 핵심 • D: 동일 (Linear는 시나리오와 다름)

해설

【핵심 용어】 • 크로스 계정 액세스 표준: 대상 계정에 IAM 역할 생성(권한 부여) + 신뢰 정책에 호출자 계정 명시 → 호출자는 sts:AssumeRole 【정답 포인트】 정답: B (개발 계정에 ec2 권한 IAM 역할 생성 + 공유 계정 신뢰 + Lambda 역할에 AssumeRole 권한) 최소 권한: 권한은 대상 계정에 두고, 호출자에게는 AssumeRole만 부여. 【오답 체크】 • A, C: 권한을 공유 계정 역할에 직접 부여하면 크로스 계정 액세스 작동 안 함 • D: 호출자에게 직접 ec2 권한 부여는 신뢰 모델과 어긋남

해설

【핵심 용어】 • CDK assertions: cdk.assertions로 합성된 템플릿에 대한 단위 테스트 작성 • CDK Aspects: 모든 컨스트럭트에 일관 규칙 적용 가능 【정답 포인트】 정답: BE • B: CDK assertions로 단위 테스트 • E: CDK Aspects로 보안 규칙 적용 + 위반 시 합성 실패 【오답 체크】 • A: cdk.out 직접 비교는 노력↑ • C: 런타임 컨텍스트는 매개변수 전달용 • D: 사용자 정의 스크립트는 표준화/유지 부담↑

해설

【핵심 용어】 • EventBridge rate(15 minutes): 단순 스케줄. Lambda를 타겟으로 직접 등록 【정답 포인트】 정답: A (EventBridge 스케줄 + Lambda 타겟) 서버리스 + 가장 적은 노력. 【오답 체크】 • B: SSM Run Command + 셸 스크립트는 EC2 필요(서버리스 아님) • C: Step Functions의 Wait는 무한루프 형태로 사용해야 → 복잡 • D: EC2 cron은 서버리스 아님

해설

【핵심 용어】 • CloudWatch 사용자 정의 지표: 처리 시간 같은 비즈니스 지표 게시 • CloudWatch Alarm: 정적 임계값(5초) 초과 시 SNS 알림 【정답 포인트】 정답: A (사용자 정의 지표 + 정적 임계값 알람 + SNS 알림) 표준 모니터링 패턴, 운영 부담 최소. 【오답 체크】 • B: SQS + 별도 컨슈머 앱은 운영 부담↑ • C: 평균 임계값은 단발 5초 초과를 놓칠 수 있음 • D: Kinesis는 과한 인프라

해설

【핵심 용어】 • Beanstalk 배포 옵션 중 새 인스턴스에만 적용: - Immutable: 새 ASG 생성 → 새 인스턴스에 배포 - Blue/green: 별도 환경에 배포 후 URL 스왑 • 기존 인스턴스 변경: All at once / Rolling / Rolling with batch 【정답 포인트】 정답: BD (Immutable, Blue/green) 새 인스턴스에만 변경 적용되는 두 옵션. 【오답 체크】 • A, C, E: 기존 인스턴스를 직접 업데이트하는 방식

해설

【핵심 용어】 • DynamoDB 저장 시 암호화 옵션: AWS 소유 키 / AWS 관리 키 / 고객 관리 키(CMK) • 사용자 키 사용 = CMK 선택, ARN 지정 【정답 포인트】 정답: B (KMS CMK + DynamoDB 테이블 생성 시 ARN 지정) 고객 키 + KMS 자동 통합 = CMK. 【오답 체크】 • A: 자체 암호화는 쿼리 어려움/비효율 • C: SDK에 kms:Encrypt 매개변수 추가는 DynamoDB SDK 패턴 아님(테이블 자체에서 암호화 구성) • D: AWS 관리 키는 회사 자체 키 요구 위반

해설

【핵심 용어】 • API Gateway Canary 배포: 스테이지에 카나리 활성, 일정 비율(예: 20%)을 새 배포로 라우팅, 나머지는 기존 배포 • 단일 사용자 오류 노출 최소화 【정답 포인트】 정답: D (API Gateway 스테이지 카나리 설정, 20% 트래픽) 기존 스테이지 유지 + 신규 변경 일부만 카나리 → 안전한 점진 배포. 【오답 체크】 • A: 변경을 부분만 배포하는 것은 비실용 • B: Route 53 가중치 정책은 가능하지만 단일 도메인 단일 스테이지 카나리가 더 단순 • C: ALB 추가는 인프라 부담↑

해설

【핵심 용어】 • API Gateway WebSocket API: 양방향 실시간 통신. connection ID로 특정 클라이언트에 푸시 가능 • @connections POST API로 서버 → 클라이언트 메시지 발신 【정답 포인트】 정답: A (WebSocket API + connection ID 매핑 + 처리 완료 시 푸시) 검증 결과를 페이지 새로고침 없이 즉시 UI에 반영하는 표준 서버리스 패턴. 【오답 체크】 • B: EC2 WebSocket 서버는 운영 부담↑ • C: 이메일 알림은 즉시 UI 갱신이 아님 • D: SNS는 브라우저 직접 푸시 채널이 아님

해설

【핵심 용어】 • Lambda Authorizer 캐싱: 동일 토큰/소스 IP에 대해 결과를 일정 시간 캐시(기본 ~5분). 캐시 동안 함수 재실행 안 됨 • 사용자 속성 변경이 즉시 반영되지 않을 수 있음 【정답 포인트】 정답: A (Lambda authorizer 캐싱 활성화) 속성이 바뀌어도 캐시된 결과가 사용 → Engineering 그대로 보고됨. 【오답 체크】 • B: Cognito user pool 자체에 'authorization caching' 옵션 없음 • C, D: IAM 역할 태그는 액세스 토큰 클레임과 무관

해설

【핵심 용어】 • SQS FIFO 큐: 순서 보장 + 정확히 한 번 처리(중복 제거) + 메시지당 최대 256KB(또는 SQS 확장으로 더 큼) • 5-10분 처리 = 가시성 타임아웃 충분 【정답 포인트】 정답: D (Lambda + SQS FIFO 큐) 중복 방지 + 순서 보장 = FIFO. Lambda 이벤트 소스로 자동 폴링. 【오답 체크】 • A: Firehose는 배치 적재이고 순서 보장 없음 • B: SNS는 메시지 큐가 아니며 순서 미보장 • C: 표준 SQS는 순서 미보장 + 중복 가능

해설

【핵심 용어】 • AWS Step Functions Local + Mocked service integrations: 외부 서비스 호출 없이 상태 머신을 로컬에서 시뮬레이션 【정답 포인트】 정답: D (Step Functions Local + Mock 통합) SQS/S3 등 외부 서비스 호출을 모킹하여 로컬에서 워크플로 검증. 【오답 체크】 • A: CodeGuru Profiler는 성능 프로파일링 • B: 'Step Functions Local Docker Image'는 로컬 실행이지만 모킹 지원 명시는 D • C: SAM CLI는 Lambda 로컬 실행, Step Functions 워크플로 자체를 시뮬레이션 못 함

해설

【핵심 용어】 • API Gateway 스테이지 변수: 스테이지마다 다른 값(URL, 함수 ARN 등)을 동적으로 주입 【정답 포인트】 정답: B (스테이지 변수에 외부 엔드포인트 저장) 스테이지마다 다른 third-party 엔드포인트를 변수로 주입하여 코드 수정 없이 환경별 운영. 【오답 체크】 • A: Lambda layer는 코드 종속성 패키지, 환경별 엔드포인트 동적 주입에 부적합 • C: 쿼리 매개변수는 클라이언트가 채워야 함 • D: AppConfig도 가능하지만 API Gateway 통합엔 스테이지 변수가 더 단순

해설

【핵심 용어】 • sam sync: 변경된 리소스만 빠르게 동기화하는 SAM Accelerate 모드. 풀 빌드/배포 우회 【정답 포인트】 정답: A (SAM + sam sync) 점진적 변경만 신속 배포 → 빠른 개발 사이클. 【오답 체크】 • B: sam init은 신규 프로젝트 생성 • C: cdk synth는 합성만, 배포 아님 • D: cdk bootstrap은 환경 부트스트랩, 배포 가속화 아님

해설

【핵심 용어】 • API Gateway MOCK 통합: 백엔드 없이 정적 응답 반환. 통합 요청에서 statusCode 매핑, 통합 응답에서 본문 정의 【정답 포인트】 정답: B (MOCK 통합 + 통합 요청/응답에 JSON과 상태 코드 매핑) 프런트엔드가 정확한 구조와 상태 코드로 즉시 통합 시작 가능. 【오답 체크】 • A: AWS_PROXY는 Lambda 호출 필요(불필요한 인프라) • C: HTTP_PROXY는 외부 API 필요 • D: 메서드 요청 단계는 검증 단계, 상태 코드 매핑 위치가 아님(통합 요청/응답이 정확)

해설

【핵심 용어】 • Kubernetes deployment 롤아웃: 이미지 태그 변경 시에만 새 리비전 발생 • 동일 태그 재사용은 캐시된 이미지 사용 → 변경 미반영 【정답 포인트】 정답: C (이미지 태그를 새 버전으로 업데이트하지 않음) 태그가 동일하면 K8s는 변경을 감지 못 하고 기존 이미지 사용. 새 태그로 푸시 + 매니페스트 갱신 필요. 【오답 체크】 • A: 새 계정 생성 자체는 본 시나리오와 무관 • B: 새 태그 추가는 가능하나 매니페스트가 그 태그를 참조해야 함 • D: D는 정답 시나리오와 비슷하지만, 실제 문제 원인은 태그 미갱신

해설

【핵심 용어】 • EC2에 IAM Role 부착 + 최소 권한 정책: 표준 모범사례 • ListBucket(버킷 ARN) + *Object(객체 ARN) 분리 부여 【정답 포인트】 정답: B (IAM Role + 최소 권한 정책: ListBucket + *Object on 특정 버킷) 자격증명 관리 불필요 + 최소 권한. 【오답 체크】 • A: 액세스 키 보관 + s3:* = 모범사례 위반 • C: AmazonS3FullAccess는 과한 권한 • D: 버킷 정책에 EC2 인스턴스를 직접 명시할 수 없음(IAM 주체 필요)

해설

【핵심 용어】 • KMS GenerateDataKey: 평문 데이터 키 + 암호화된 데이터 키 한 쌍 반환 • Envelope encryption: 평문 키로 큰 데이터 암호화 → 메모리에서 즉시 폐기, 암호화된 키만 디스크에 저장 → 복호화 시 KMS Decrypt로 평문 키 복원 【정답 포인트】 정답: A (암호화된 키를 디스크에 저장 + 평문 키로 데이터 암호화) 표준 envelope encryption 패턴. 【오답 체크】 • B: 평문 키를 디스크에 저장하면 보안 의미 없음 • C: KMS Encrypt API는 4KB 한도 → 1MB 파일 직접 암호화 불가 • D: 동일하게 평문 키 저장 + KMS Encrypt 부적절