정답 · 해설

해설

【핵심 용어】 • Cognito User Pools: 사용자 디렉토리. 가입/로그인/사용자 관리 담당. 소셜 로그인(페더레이션) 지원 • Cognito Identity Pools: 인증된/익명 사용자에게 임시 AWS 자격증명을 부여 【정답 포인트】 정답: C (Cognito User Pools) '사용자가 자신의 소셜 미디어 계정으로 가입/등록' = 사용자 디렉토리 생성 + 외부 IdP(페이스북, 구글 등) 페더레이션 = User Pool의 핵심 기능. User Pool은 hosted UI와 SAML/OIDC/소셜 IdP를 통해 회원가입을 처리함. 【오답 체크】 • A: IAM Role은 AWS 리소스에 대한 권한 부여용, 최종 사용자 인증 용도가 아님 • B: Identity Pool은 자격증명 교환용, 사용자 등록/디렉토리 기능이 없음 • D: AWS Directory Service는 Microsoft AD/관리형 디렉토리 서비스(기업용), 일반 앱 회원가입용이 아님

해설

【핵심 용어】 • Lambda@Edge: CloudFront 엣지 로케이션에서 실행되는 Lambda. Node.js/Python 지원, 외부 SDK/AWS API 호출 가능 • CloudFront Functions: 초경량 JS만 실행. 외부 네트워크/SDK 호출 불가 • Viewer Request: 사용자 → CloudFront 도착 시점 【정답 포인트】 정답: A (Lambda@Edge + 실행 역할에 STS 권한 + 프론트엔드 SDK 호출 이전) STS를 호출해 자격증명을 발급받으려면 SDK 실행 환경이 필요함. CloudFront Functions는 SDK 호출이 안 됨. Lambda@Edge는 viewer request에서 동작하며 IAM 역할로 STS를 호출할 수 있어 자격증명 하드코딩을 제거할 수 있음. 【오답 체크】 • B, D: CloudFront Functions는 외부 네트워크 호출/SDK 사용 불가 → STS 호출 불가능 • C: 자격증명을 함수 코드에 옮기는 것도 여전히 하드코딩이라 보안 요구사항에 부합하지 않음

해설

【핵심 용어】 • "Too many connections": Lambda 동시 실행 수 × 함수당 커넥션 수가 RDS 최대 커넥션을 초과해 발생 • RDS Proxy: 커넥션 풀링 관리 서비스. 수많은 단명 Lambda 호출이 적은 수의 영속 DB 커넥션을 공유하게 함 • 핸들러 외부에서 커넥션 초기화: Lambda 컨테이너 재사용으로 cold start 시에만 연결 → 효율↑ 【정답 포인트】 정답: B (핸들러 외부 초기화 + RDS Proxy) CPU/메모리는 여유가 있는데 커넥션만 부족하다는 것은 전형적인 Lambda 폭증으로 인한 커넥션 고갈. RDS Proxy가 풀링으로 이를 해결함. 추가로 핸들러 밖에서 connection 초기화 시 컨테이너 재사용 동안 유지됨. 【오답 체크】 • A: max_connections 늘리면 메모리 부족으로 다른 문제 발생, 근본 해결 아님 • C, D: 'Service needs to return order confirmation immediately' → 비동기 큐 도입은 즉시 응답 요구사항 위반

해설

【핵심 용어】 • Amazon Macie: S3 데이터에서 민감 정보(PII, 신용카드, 금융정보 등)를 자동 발견/분류하는 보안 서비스 • Finding type: SensitiveData:S3Object/Financial(금융), /Personal(개인정보), /Credentials(자격증명) 등 【정답 포인트】 정답: B (Macie + Financial finding type) 신용카드 정보 노출 의심 → Macie가 정확한 도구. 그리고 신용카드는 금융정보 카테고리이므로 'Financial' finding type을 사용. 'Personal'은 SSN, 이름, 주소 등 PII 카테고리. 【오답 체크】 • A, D: Athena는 SQL 쿼리 도구이지 민감 정보 분류 도구가 아님 • C: Macie는 맞지만 Personal finding type은 신용카드와 카테고리가 다름 → Financial이 정답

해설

【핵심 용어】 • Cognito Identity Pool: 인증/미인증 사용자 모두에게 임시 자격증명 부여 가능 • 인증 vs 미인증 역할: Identity Pool은 두 종류 IAM 역할을 매핑 【정답 포인트】 정답: BD (Identity Pool + 인증/미인증용 역할 분리) 게스트 사용자도 샘플 콘텐츠에 접근해야 하고, 가입 전환을 추적해야 함 → Identity Pool이 인증된 자격증명/미인증 자격증명을 별도로 발급하면 동일한 ID를 추적 가능. 권한은 두 종류 역할로 분리. 【오답 체크】 • A: User Pool은 익명/미인증 사용자 토큰 발급 안 함 → 게스트 처리 불가 • C: CloudFront는 인증 처리/자격증명 교환 서비스가 아님 • E: 단순히 접근 허용은 게스트 추적/전환 측정 요구사항을 충족하지 못함

해설

【핵심 용어】 • AWSLambdaBasicExecutionRole: CloudWatch Logs 권한만 포함 • AWSLambdaVPCAccessExecutionRole: ENI 생성/관리 권한 추가 → VPC 안에서 Lambda 실행 시 필수 • Lambda를 VPC에 연결: 동일 VPC 내 RDS 등 사설 리소스에 접근 가능 【정답 포인트】 정답: B (VPCAccessExecutionRole + 보안그룹 인바운드 허용) Lambda를 VPC 사설 서브넷에 배포해야 RDS 사설 인스턴스에 접근 가능. 이때 ENI 생성을 위해 VPCAccessExecutionRole이 필수. RDS 보안그룹은 Lambda 보안그룹으로부터 인바운드 허용해야 함. 【오답 체크】 • A: BasicExecutionRole은 ENI 권한이 없어 VPC 내 Lambda가 동작하지 않음 • C, D: Interface VPC endpoint는 VPC에서 Lambda API를 호출하는 용도(역방향), 본 문제와 반대 방향임

해설

【핵심 용어】 • AMI는 리전별 리소스: ID가 리전마다 달라서 한 리전 AMI를 다른 리전에서 직접 참조 불가 • Copy AMI: 다른 리전으로 복사 시 새로운 AMI ID 부여 【정답 포인트】 정답: B (AMI 복사 + 새 AMI ID로 us-west-1 템플릿 갱신) 오류 원인은 AMI ID가 us-west-1에 존재하지 않기 때문. 가장 적은 운영 부담의 해결책은 AMI를 us-west-1로 복사한 뒤, 그 리전의 새 AMI ID로 템플릿을 업데이트. 【오답 체크】 • A: AWS 표준 AMI 사용 시 커스텀 구성을 잃음. 게다가 us-east-1 환경 변경도 불필요한 변경 • C: AMI를 처음부터 다시 빌드하는 것은 운영 부담이 큼 • D: CloudFormation 자동화를 포기 → 모범사례 위배

해설

【핵심 용어】 • Lambda Layer: 여러 함수가 공유하는 라이브러리/런타임 패키지. 버전 관리 지원 • 최대 5개 layer를 함수에 첨부 가능 【정답 포인트】 정답: C (Lambda Layer) Layer는 라이브러리 중앙화, 손쉬운 업데이트, 자동 버전 관리를 모두 만족하는 Lambda 전용 메커니즘. 가장 적은 개발 노력. 【오답 체크】 • A: CodeArtifact는 빌드 시 패키지 저장소. Lambda 런타임이 직접 사용하지 않음 → 추가 작업 필요 • B: 컨테이너 이미지 전환은 빌드/배포 파이프라인 변경 필요 → 큰 노력 • D: EFS는 마운트/네트워크 구성 필요. 라이브러리 버전 관리 기능도 별도 구현 필요

해설

【핵심 용어】 • All-at-once: 모든 인스턴스에 한 번에 배포. 다운타임 있음, 가장 빠름 • Rolling: 인스턴스 묶음 단위로 배포 • Immutable: 새 ASG에 새 인스턴스 생성 후 교체. 가장 안전, 가장 느림 【정답 포인트】 정답: D (All at once) 테스트 환경이라 다운타임 허용 가능, '가장 빠른 배포'가 요구사항. All-at-once는 즉시 모든 인스턴스 교체로 가장 빠름. 【오답 체크】 • A: Immutable은 가장 안전하지만 새 인스턴스 프로비저닝 시간으로 가장 느림 • B: Rolling은 묶음 단위 점진 배포로 시간이 오래 걸림 • C: Rolling with additional batch도 추가 배치 생성으로 시간 추가

해설

【핵심 용어】 • aws:SecureTransport: 요청이 HTTPS(SSL/TLS)인지 확인하는 글로벌 조건 키 • 전송 중 암호화 강제: SecureTransport=false일 때 Deny 정책으로 평문 차단 【정답 포인트】 정답: A (S3 버킷 정책으로 SecureTransport=false 시 Deny) 전송 중 암호화 강제는 표준 패턴. 버킷 정책에 "Effect: Deny + Condition: aws:SecureTransport=false" 적용하면 HTTP 요청은 모두 차단됨. 【오답 체크】 • B: x-amz-acl=public-read는 객체 ACL 설정 차단용, 전송 암호화와 무관 • C: SDK 강제는 IAM 정책으로 표현 불가, SDK라도 HTTP 호출 가능 • D: bucket-owner-read는 객체 소유권 ACL 관련, 전송 암호화 무관

해설

【핵심 용어】 • ALB 라우팅 규칙: 호스트 헤더, 경로, 쿠키 등 조건으로 트래픽 분기 • 베타 트래픽 분기: 별도 Auto Scaling 그룹/타겟 그룹을 만들고 라우팅 조건으로 분기 【정답 포인트】 정답: A (새 ASG/타겟 그룹 + ALB 규칙에 version=beta 쿠키 조건) 기존 ALB를 유지한 채 베타용 ASG/타겟 그룹만 추가하고, 라우팅 규칙에 쿠키 조건만 추가하면 가장 단순. 테스트 시스템이 의도적으로 쿠키를 보내 베타로 라우팅됨. 【오답 체크】 • B: 새 ALB까지 만드는 건 과한 인프라 • C, D: Lambda@Edge/CloudFront는 글로벌 CDN 단계에서 분기 → 단순 내부 베타 테스트엔 과도

해설

【핵심 용어】 • EC2의 S3 접근 실패 디버깅: ① IAM Role 정책(인스턴스 프로파일) ② S3 버킷 정책 ③ VPC 엔드포인트/네트워크 • EC2에는 보통 IAM Role(인스턴스 프로파일)을 부여하지 IAM User를 부여하지 않음 【정답 포인트】 정답: AB • A: EC2에 부착된 IAM Role의 정책에 S3 권한이 있는지 확인 • B: 버킷 정책이 해당 주체의 접근을 허용하는지 확인 둘 다 액세스 평가에 영향을 주는 핵심 요소. 【오답 체크】 • C: EC2에는 IAM User가 아닌 IAM Role을 부착. 표현 자체가 잘못됨 • D: S3 라이프사이클 정책은 객체 만료/전환 규칙이지 액세스 권한과 무관 • E: 보안그룹은 EC2 인바운드/아웃바운드 트래픽 제어. S3는 퍼블릭 엔드포인트라 일반적으로 OB 거부 정책이 없음(서브넷 라우팅/엔드포인트 별도)

해설

【핵심 용어】 • CloudWatch agent(통합형): EC2 시스템 로그/앱 로그/지표를 CloudWatch Logs로 자동 수집 • 중앙 집중 로그 관찰 = 가장 적은 변경으로 도달하는 모범 답안 【정답 포인트】 정답: D (EC2에 CloudWatch agent 설치 → 로그를 CloudWatch로 푸시) 앱 코드 변경 없이 인스턴스에 에이전트 설치/구성만으로 로그를 중앙에서 조회 가능. 가장 적은 변경. 【오답 체크】 • A: Lambda 재작성은 큰 변경 • B: OpenSearch + Logstash는 인프라 추가/관리 부담 큼 • C: 인스턴스를 1대로 줄이는 것은 고가용성 요구 위반

해설

【핵심 용어】 • S3 → Lambda 트리거 방식: ① 버킷의 "이벤트 알림"으로 직접 Lambda 트리거 ② EventBridge로 'Object Created' 이벤트 → 규칙으로 Lambda 트리거 • EventBridge 트리거는 Lambda 측에서도 트리거(소스 EventBridge 규칙) 추가 【정답 포인트】 정답: AC • A: Object Created 패턴의 EventBridge 규칙 생성 • C: 기존 Lambda에 EventBridge 트리거 추가하여 그 규칙을 선택 이 두 단계로 .csv 업로드 시 Lambda가 자동 호출됨. 【오답 체크】 • B: 새 Lambda를 스케줄로 폴링하면 실시간 호출이 아님(요구사항: 업로드 시 호출) • D: 별도 Lambda로 폴링은 비효율 • E: Lifecycle은 객체 만료/전환용, Lambda 호출 메커니즘이 아님

해설

【핵심 용어】 • AWS::Region: CloudFormation 의사 매개변수(Pseudo Parameter). 스택이 배포되는 리전을 자동 반환 • 의사 매개변수: 사용자가 정의하지 않아도 항상 사용 가능 【정답 포인트】 정답: A (AWS::Region pseudo parameter) 자기 자신이 배포되는 리전을 자동으로 채우는 가장 효율적인 방법. 【오답 체크】 • B: 사용자가 매번 입력해야 하므로 자가 채움 요구 위반 • C: StackId에서 split 하는 건 가능하지만 복잡, 효율적 답이 아님 • D: SSM Parameter Store에 별도 등록 필요 → 운영 부담 큼

해설

【핵심 용어】 • Lambda Function URL auth_type=AWS_IAM: SigV4 서명 + IAM 정책 평가로 호출 제어 • lambda:InvokeFunctionUrl: Function URL 호출용 IAM 액션 • 아이덴티티 기반 정책 vs 리소스 기반 정책: 이 액션은 둘 다로 표현 가능 【정답 포인트】 정답: A (AWS_IAM 인증 + QA 그룹에 InvokeFunctionUrl 허용 정책 부착) 인증 비활성(NONE)은 누구나 호출 가능 → 보안상 부적절. AWS_IAM 인증을 켜고, QA 그룹에 모든 함수 ARN 허용 정책을 부착하면 그룹 전체가 모든 함수 호출 가능. 그룹 단위 정책 한 개로 끝. 【오답 체크】 • B, D: NONE auth는 인증을 사실상 하지 않음 → 잘못된 보안 모델 • C: 함수마다 정책 한 개씩 만들면 운영 부담↑, A의 그룹 단일 정책이 더 효율적

해설

【핵심 용어】 • DynamoDB Streams: 테이블 변경(insert/update/delete) 캡처 → Lambda 트리거 가능 • 거의 실시간 처리 + 코드 최소 변경 【정답 포인트】 정답: B (DynamoDB Streams 활성화 + Lambda 트리거) 앱 코드 변경 없이 테이블에서 Stream만 켜고 Lambda를 연결하면 변경 시 자동 호출. 【오답 체크】 • A: 1시간 cron은 실시간이 아님 • C: 앱이 EventBridge로 직접 보내려면 코드 수정 필요 • D: 동기 처리는 쓰기 응답 지연 + 실패 시 트랜잭션 복잡

해설

【핵심 용어】 • Secrets Manager: 보안 비밀 저장 + 자동 회전 기본 지원 • Parameter Store: 회전 자체는 미지원(별도 구현 필요) • RDS IAM 인증은 SQL Server를 지원하지 않음 【정답 포인트】 정답: C (Secrets Manager + 일별 회전) 주별 회전 요구를 가장 직관적으로 만족. SQL Server 자격증명 자동 회전이 기본 기능. 【오답 체크】 • A: KMS 키 회전과 시크릿 값 회전은 다름. 키 회전은 평문 비밀번호 변경이 아님 • B: SQL Server는 RDS IAM 인증 미지원 • D: 사용자 데이터 + 환경변수는 보안 모범사례 위반

해설

【핵심 용어】 • WebSocket API의 라우트 키: $connect, $disconnect, $default 등이 미리 정의된 라우트 • ElastiCache: 클라이언트 연결 상태(예: connectionId, 연결 횟수) 저장 가능 【정답 포인트】 정답: DE • E: $connect/$disconnect 라우트를 백엔드에 구현해 연결/해제 이벤트를 수신 • D: 그 이벤트를 ElastiCache에 기록 → 빈번 연결/해제 클라이언트 식별 가능 식별 후 연결을 끊는 것은 @connections 관리 API로 가능. 【오답 체크】 • A, B: HTTP/REST API 전환은 WebSocket 기능 자체가 사라져 요구 위반 • C: "콜백 URL"은 클라이언트 연결을 끊는 표준 방법이 아님

해설

【핵심 용어】 • CodeCommit: AWS 관리형 Git 저장소. 버전 관리, 변경 이력, PR 검토 등 지원 • CodeBuild: 빌드 서비스(저장소 아님) 【정답 포인트】 정답: C (CodeCommit) 장기 보관 + 다중 버전 + 변경 추적 + 동료 피드백 = Git 워크플로 = CodeCommit. 【오답 체크】 • A: CodeBuild는 빌드 실행 서비스 • B: S3는 일반 객체 저장, Git 워크플로 없음 • D: Cloud9은 IDE이지 저장소가 아님