정답 · 해설

해설

【핵심 용어】 • API Gateway 스테이지: 동일 API를 새 스테이지(test 등)로 배포해 환경별 검증 가능 • 단일 API 변경 → 새 스테이지 배포 → 검증 → prod 배포 【정답 포인트】 정답: B (기존 API에 검증 추가 → 새 스테이지 배포 → 테스트 → prod 배포) 동일 API에서 검증 로직을 추가하고 별도 스테이지로만 배포하면 prod 영향 없음. 가장 적은 운영 부담. 【오답 체크】 • A, C, D: 새 API/복제 API 생성은 운영 자원 추가 부담

해설

【핵심 용어】 • DynamoDB Streams: 테이블 변경 이벤트(INSERT/MODIFY/REMOVE) 캡처 → Lambda 트리거 • 향후 분석용 모든 이력 보관 = Streams로 변경 캡처 후 S3 적재 【정답 포인트】 정답: C (DynamoDB Stream + Lambda → S3 기록) 앱/파트너 코드 수정 없이 테이블 측 Stream 활성화로 모든 주문/업데이트 자동 기록. 추가 Lambda 한 개만 필요. 【오답 체크】 • A: 기존 Lambda 수정 + 새 API 추가 = 노력↑ • B: Kinesis 도입은 추가 인프라 • D: SNS 추가는 모든 변경 보장 어렵고 코드 수정 필요

해설

【핵심 용어】 • 정적 콘텐츠 글로벌 지연 → CloudFront(에지 캐시)로 해소 • 정적 콘텐츠는 EC2가 아니라 S3에 두고 CloudFront로 서빙 【정답 포인트】 정답: DE • E: 정적 콘텐츠를 S3로 이동 • D: CloudFront로 캐시/엣지 배포 → 글로벌 사용자 지연 즉시 개선. 【오답 체크】 • A: 인스턴스 수 늘려도 글로벌 거리 지연은 그대로 • B: 앱 자체를 Lambda로 재작성은 과한 변경 • C: 수직 확장도 글로벌 지연과 무관

해설

【핵심 용어】 • S3 Pre-signed URL: 임시 서명된 URL로 비공개 객체에 한시적 접근 부여. 인증 없이도 그 URL로 접근 가능 • 유료 구독자에게만 동적으로 발급 가능 【정답 포인트】 정답: B (요청 시 pre-signed URL 발급) 버킷 자체는 비공개 유지, 백엔드가 구독자 검증 후 URL 발급. 유연하고 안전. 【오답 체크】 • A: 익명 다운로드 허용은 무차별 공개 • C: MFA 강제는 일반 사용자에게 비현실적 • D: SSE는 저장 암호화이지 접근 제어가 아님

해설

【핵심 용어】 • GSI: 다른 파티션/정렬 키 조합으로 새 인덱스 생성. 부분 일치는 begins_with 키 조건식 • begins_with는 정렬 키에만 사용 가능 【정답 포인트】 정답: A (GSI: customer_type=PK, email_address=SK + begins_with email_address) 특정 customer_type에 대해 email_address의 부분 일치 검색이 필요. customer_type을 파티션 키로, email_address를 정렬 키로 두면 customer_type=값 + begins_with(email_address, ...) 쿼리 가능. 【오답 체크】 • B: email_address가 PK이면 customer_type별 그룹화 어려움 + begins_with는 PK에 사용 불가 • C: LSI는 테이블 생성 시에만 정의 가능 → '재생성 안 한다' 위반 • D: job_title PK로는 customer_type 필터 어려움

해설

【핵심 용어】 • sam sync --watch: 변경된 리소스만 빠르게 재배포(Lambda 코드만 바뀌면 코드만 푸시) → SAM Accelerate의 핵심 • 풀 빌드/배포 우회로 개발 사이클 단축 【정답 포인트】 정답: D (sam sync --watch) Lambda 코드만 변경되면 그 부분만 동기화하여 매우 빠르게 반영. 【오답 체크】 • A: --force-upload는 모든 아티팩트 재업로드 • B: --no-execute-changeset은 ChangeSet 생성만 수행 • C: sam package는 패키징만 수행, 배포 가속화 아님

해설

【핵심 용어】 • ssm:PutParameter + Type=SecureString: KMS로 암호화된 매개변수 저장 • 커스텀 리소스 안에서 SDK로 시크릿 저장 = 가장 안전한 분리(자격증명이 CFN 응답에 노출되지 않음) 【정답 포인트】 정답: B (Lambda 안에서 ssm:PutParameter SecureString) 커스텀 리소스 응답에 자격증명을 포함하지 않고, Lambda 안에서 직접 Parameter Store에 SecureString으로 저장. CFN 출력/이벤트에 비밀이 노출되지 않음. 【오답 체크】 • A: GenerateSecretString은 회전이 필요한 일반 비밀 생성용. 외부에서 받은 자격증명 저장과는 다름. 또한 CFN 데이터에 노출 가능성 • C: NoEcho는 매개변수 입력 화면에서 마스킹할 뿐, 자격증명 자체 저장은 보안 부족 • D: NoEcho는 Parameter Store 매개변수 속성이 아님(잘못된 속성)

해설

【핵심 용어】 • DynamoDB GetItem 권한: dynamodb:GetItem on table ARN • 실패 원인: IAM 사용자에게 해당 테이블 읽기 권한 없음 【정답 포인트】 정답: D (해당 IAM User에게 demoman-table 읽기 권한 부여 정책 필요) 명령 자체는 정상 → 권한 부족이 가장 가능성 높은 오류 원인. 【오답 체크】 • A: GetItem이 정확한 액션, put-item으로 바꾸는 것은 의미 다름 • B: AWS Support에 테이블 액세스 활성화 요청은 잘못된 절차 • C: DynamoDB는 CLI 정상 지원

해설

【핵심 용어】 • Viewer Protocol Policy: 사용자 ↔ CloudFront 구간 HTTPS 강제 • Origin Protocol Policy: CloudFront ↔ 오리진(앱) 구간 HTTPS 강제 【정답 포인트】 정답: BD • D: Viewer Protocol Policy를 'HTTPS Only' 또는 'Redirect HTTP to HTTPS'로 설정 • B: Origin Protocol Policy를 'HTTPS Only'로 설정 양 구간 모두 TLS 적용. 【오답 체크】 • A: KMS는 저장 암호화용, 전송 암호화에 사용되지 않음 • C: HTTP 포트만 443으로 바꿔도 프로토콜이 HTTP면 의미 없음 • E: Restrict Viewer Access는 서명 URL/쿠키 기능, 암호화와 별개

해설

【핵심 용어】 • KMS 자동 키 회전: 대칭 KMS 키(AWS 생성 키 자료)에서만 매년 자동 회전 지원 • 비대칭 키/가져온 키 자료(BYOK): 자동 회전 미지원 • S3 관리 키(SSE-S3): 사용자 직접 KMS 사용/회전 제어 못 함 【정답 포인트】 정답: B (대칭 고객 관리 KMS 키 + AWS 생성 키 자료) 매년 자동 회전 지원 = 대칭 + AWS 생성 키. KMS 사용 요건도 충족. 【오답 체크】 • A: SSE-S3는 KMS 사용 안 함, 자동 회전도 직접 제어 불가 • C: 비대칭 KMS 키는 자동 회전 미지원 • D: 임포트된 키 자료는 자동 회전 미지원

해설

【핵심 용어】 • CodePipeline 단계 추가: CodeBuild를 새 단계 공급자로 사용 • CodeBuild Test Reports: 테스트 결과를 자동 파싱해 콘솔에서 시각화 • 테스트 → 배포 전: 실패 시 배포 자체를 막아 안정적 【정답 포인트】 정답: C (테스트 환경 배포 이전 단계에 CodeBuild 단계 추가, 실패 시 단계 실패) 단위 테스트는 배포 전에 실행되어야 의미가 있음. CodeBuild의 Test Reports 기능이 노력 최소화로 시각화 제공. 【오답 체크】 • A: pre-commit hook은 로컬 의존, 강제력 없음 → 누락 위험 • B: 배포 후 테스트는 실패해도 이미 배포된 상태 • D: Jenkins 도입은 추가 인프라 운영 부담

해설

【핵심 용어】 • aws:SourceVpce 조건 키: 요청이 통과한 VPC 엔드포인트 ID • 다수 엔드포인트 허용: 단일 정책 안에 여러 SourceVpce 값을 배열로 지정. 'StringNotEquals + Deny' 형태가 일반적(나열되지 않은 엔드포인트는 거부) 【정답 포인트】 정답: D (단일 버킷 정책 + StringNotEquals에 여러 SourceVpce 값 나열) 허용된 엔드포인트들의 ID 목록을 한 번에 명시하고, 그 목록에 해당하지 않으면 거부하는 단일 정책으로 관리. 【오답 체크】 • A: 정책을 여러 개 만들어 'NotEquals'를 분산하면 의도와 반대(서로 OR로 작용해 모두 차단) • B: aws:SourceVpc는 VPC ID, 엔드포인트별 통제 불가 • C: 와일드카드 vpce*는 사실상 모든 엔드포인트 차단을 우회로 만들어 의도와 다름

해설

【핵심 용어】 • Lambda 핸들러 외부 초기화: 콜드 스타트 시 1회만 실행되어 컨테이너 재사용 동안 캐싱 → 비용/지연 최소화 • Secrets Manager 또는 S3에 인증서 보관 후 동적 로드: 함수 재배포 없이 갱신 가능 • 자원 기반 정책으로 다 계정에서 동일 자료 접근 【정답 포인트】 정답: AE • A: Secrets Manager에 Root CA Cert 저장 + 리소스 기반 정책으로 다 계정 접근 허용 • E: 핸들러 외부에서 인증서 로드 + 트러스트 스토어 갱신(콜드 스타트 시 1회) 【오답 체크】 • B: Parameter Store는 SecureString 4KB 한도(고급은 8KB) → 10KB CA cert 저장 어려움 • C: S3도 가능하나 Secrets Manager가 비밀 관리 모범사례에 더 가까움(비교 우위) • D: 핸들러 안에서 매 호출마다 트러스트 스토어 갱신 → 비효율

해설

【핵심 용어】 • AWS Config 관리형 룰 'secretsmanager-secret-unused': 일정 기간 사용되지 않은 시크릿을 비준수로 평가 • EventBridge 규칙으로 비준수 알림 자동 발송 【정답 포인트】 정답: B (Config 관리형 룰 + EventBridge 알림) 별도 운영 코드 없이 Config가 자동 평가하고, EventBridge로 알림. 다운타임도 없음. 【오답 체크】 • A: GetSecretValue 알람도 가능하지만 직접 측정 + 임계값 설정 부담, Config 룰이 더 표준적 • C: 일부러 비활성하면 다운타임 위험 • D: X-Ray는 트레이싱 도구, 사용 여부 분석 표준 도구가 아님

해설

【핵심 용어】 • EventBridge schedule: rate(10 minutes) 같은 표현으로 주기적 Lambda 호출 가능 (서버리스, 자동화) • Lambda 직접 트리거 가능 【정답 포인트】 정답: C (EventBridge 스케줄 규칙으로 Lambda 호출) 10분 주기 자동 호출의 표준 서버리스 패턴. 【오답 체크】 • A: EC2 + crontab은 서버리스 아님 • B: 환경변수만 설정한다고 호출 자동화되지 않음 • D: SNS는 메시지 발송 토픽이지 스케줄러 아님

해설

【핵심 용어】 • CloudFormation dynamic reference '{{resolve:secretsmanager:...:SecretString:...}}': 비밀을 평문으로 노출하지 않고 CFN 리소스에서 사용 • 환경변수에는 시크릿 이름만 저장하고 런타임에 SDK로 조회 【정답 포인트】 정답: D (Secrets Manager + dynamic reference + 런타임 조회) MasterUserOptions에 dynamic reference로 비밀 주입, Lambda는 런타임에만 시크릿 값을 조회. 환경변수에는 평문이 아닌 이름만 보관 → 가장 안전. 【오답 체크】 • A, C: 환경변수에 평문 비밀 저장은 보안 부족(NoEcho는 입력 화면 마스킹용) • B: Parameter Store도 가능하지만 회전이 자동이 아니며 D보다 보안 약함

해설

【핵심 용어】 • 다중 EC2 + ELB 환경에서 세션 데이터: 인스턴스 외부의 공유 캐시(ElastiCache)에 저장 → 어느 인스턴스에서나 접근 가능 【정답 포인트】 정답: A (ElastiCache) 인스턴스 외부의 인메모리 저장소이므로 ELB가 어떤 인스턴스로 라우팅해도 동일 세션 조회 가능. 【오답 체크】 • B: EBS는 단일 인스턴스 부착, 공유 어려움 • C: 인스턴스 스토어는 인스턴스 종료 시 데이터 손실 • D: 루트 파일 시스템은 인스턴스에 종속

해설

【핵심 용어】 • X-Forwarded-For: ALB가 원래 클라이언트 IP를 전달하는 표준 헤더 • 요청 IP 분석 시 핵심 【정답 포인트】 정답: C (X-Forwarded-For) 원본 클라이언트 IP는 X-Forwarded-For에서 확인. 【오답 체크】 • A: X-Forwarded-Proto는 프로토콜(http/https) 정보 • B: X-Forwarded-Host는 호스트 정보 • D: X-Forwarded-Port는 포트 정보

해설

【핵심 용어】 • Step Functions: 상태 기계로 분기/대기/재시도 표현. Wait state로 정확한 시간 대기 가능 • 외부 API 한도 처리: 실패 시 Wait → 재시도 【정답 포인트】 정답: A (Step Functions로 실패 모니터링 + Wait state로 대기) 외부 API 한도 초과 응답을 받으면 Wait state로 일정 시간 대기 후 다시 호출. 운영 효율적. 【오답 체크】 • B: SQS 폴링은 Lambda 동시성 제어 정도이지, 분 단위/일 단위 한도 인식 처리는 어려움 • C: 알람으로 Lambda 인스턴스 정지는 표준 동작 아님 • D: Firehose는 데이터 전달 서비스로 API 호출 한도 관리에 부적합

해설

【핵심 용어】 • AWS X-Ray: 분산 추적 서비스. 서비스 간 호출 segments/subsegments로 시각화, 병목/오류 식별 【정답 포인트】 정답: C (X-Ray) 분산 Lambda 성능 이슈 진단에 가장 적합. 세그먼트와 오류 추적 가능. 【오답 체크】 • A: CloudWatch Logs는 메타데이터 추적엔 도움이지만 분산 트레이스 시각화는 부족 • B: CloudTrail은 API 호출 감사용 • D: Inspector는 보안 평가 도구