정답 · 해설

해설

【핵심 용어】 • Rolling with additional batch: 현재 용량 유지(추가 배치 사용), 점진 배포. 비용 최소화 • Immutable: 새 ASG로 전체 교체, 가장 안전하나 비용↑ 【정답 포인트】 정답: B (Rolling with additional batch) 전체 용량 유지 + 무중단 + 비용 최소화 모두 만족. Immutable보다 추가 비용 적음. 【오답 체크】 • A: All at once는 다운타임 발생 • C: Blue/green은 환경 두 개 운영 → 비용↑ • D: Immutable은 새 인스턴스 풀 생성 → B보다 비용↑

해설

【핵심 용어】 • AWS SAM CLI: sam local invoke / start-api / start-lambda / generate-event 지원 • Lambda 환경에 가까운 Docker 컨테이너로 함수 실행 → 정확한 시뮬레이션 【정답 포인트】 정답: C (SAM CLI: generate-event + local invoke) SAM CLI는 Lambda 실행 환경을 거의 그대로 재현해 로컬 테스트 가능. CI/CD에서도 동일 명령으로 실행. 【오답 체크】 • A: 'cdk local invoke'는 존재하지 않는 명령 • B: 일반 단위 테스트 프레임워크는 Lambda 환경 시뮬레이션 부족 • D: Node.js 베이스 컨테이너는 Lambda와 다름

해설

【핵심 용어】 • EC2 인스턴스에 IAM 역할 부착하려면 역할의 신뢰 정책(Trust Policy)에 ec2.amazonaws.com 서비스 주체 허용 필요 • Trust Policy 누락 → 역할이 인스턴스에 사용될 수 없음 【정답 포인트】 정답: C (EC2 서비스 주체에 대한 신뢰 정책 작성 후 역할 연결) 역할 자체의 정책은 EC2가 그 역할을 "AssumeRole" 할 수 있어야 적용됨. 신뢰 정책에 ec2.amazonaws.com이 빠지면 액세스가 거부됨. 【오답 체크】 • A: 와일드카드 리소스 → 권한 과도 • B: dynamodb:* → 최소 권한 위반 • D: 신뢰 관계 대상은 dynamodb가 아닌 ec2 서비스

해설

【핵심 용어】 • Envelope encryption: 데이터 키로 데이터를 암호화하고, 데이터 키 자체는 KMS 키로 암호화 → 암호화된 데이터 키를 암호문에 포함 • AWS Encryption SDK가 자동 처리 【정답 포인트】 정답: B (SDK가 데이터 암호화 키를 암호화해 암호문에 함께 저장) 복호화 시 SDK가 자동으로 암호화 키를 추출/복호화하므로 사용자가 별도로 관리할 필요 없음. 【오답 체크】 • A: 직접 관리 필요는 SDK 자동화 모델과 반대 • C: S3 자동 저장 기능 없음 • D: EC2 Userdata는 부팅 스크립트 영역

해설

【핵심 용어】 • Lambda 실행 역할: 임시 자격증명을 자동으로 사용. 하드코딩 불필요 • 역할에 최소 권한 정책 부착이 모범사례 【정답 포인트】 정답: C (Lambda 실행 역할 + 특정 객체 권한 정책) 임시 자격증명 + 최소 권한 = 가장 안전. 【오답 체크】 • A: 자격증명 하드코딩 금지 • B: 영속 액세스 키는 회전/유출 위험. 임시 자격증명이 더 안전 • D: 환경변수에 평문 자격증명 저장 부적절

해설

【핵심 용어】 • CloudFormation 서비스 역할: 스택 배포 시 다른 서비스를 호출 • 다 계정 접근: 버킷 정책에 허용할 계정 ARN 명시(Principal) 【정답 포인트】 정답: A (CFN 서비스 역할에 ListBucket+GetObject + 버킷 정책에 허용 계정 명시) List/Get 권한을 서비스 역할에 부여하고, 버킷 측에서도 계정 단위로 제한된 Principal로 허용 → 최소 권한 + 명시적 신뢰 관계. 【오답 체크】 • B: Principal="*"는 공개와 같아 보안 위반 • C, D: "service-based link" 같은 모호한 용어, Lambda는 코드 위치를 직접 받지 않고 CFN이 처리

해설

【핵심 용어】 • EventBridge schedule + Lambda: 서버리스 cron의 표준 【정답 포인트】 정답: C (EventBridge 스케줄 → Lambda) 인프라 없이 서버리스로 매일 정해진 시간 1회 호출 가능. 가장 효율적. 【오답 체크】 • A: EKS는 클러스터 운영 부담 • B: EC2 운영 부담 • D: AWS Batch는 배치 작업 큐 시스템, 단일 API 호출에 과함

해설

【핵심 용어】 • Lambda 컨테이너 재사용: 동일 컨테이너에 같은 코드가 여러 번 호출됨 • 핸들러 외부 초기화 = SDK/DB 클라이언트 객체가 콜드 스타트에서만 1회 생성, 이후 재사용 → 지연/비용 절감 【정답 포인트】 정답: B (런타임 환경 재사용 활용) 핸들러 외부 코드는 한 번만 실행되고 컨테이너 동안 재사용되므로 성능상 큰 이점. 【오답 체크】 • A: 가독성 효과는 부수적 • C: 오류 처리 자체와 직접적 인과 없음 • D: 매 호출 새 인스턴스 생성은 정반대(비효율)

해설

【핵심 용어】 • ElastiCache for Redis (cluster mode): 데이터 암호화(전송/저장) + Multi-AZ 자동 페일오버 → 고가용성 • Redis는 암호화/인증 지원, Memcached는 지원 미흡 【정답 포인트】 정답: C (Redis cluster mode) 캐시 + 암호화 + 고가용성 = Redis (cluster mode). 【오답 체크】 • A: CloudFront는 캐시 위치가 엣지. RDS 앞 DB 캐시 용도가 아님 • B: Memcached는 암호화/HA 미흡 • D: DAX는 DynamoDB 전용 캐시, RDS 캐시 아님

해설

【핵심 용어】 • API Gateway → Lambda 비동기 호출: 통합 요청 헤더 X-Amz-Invocation-Type=Event 추가 • 즉시 202 응답 후 백엔드는 비동기 처리 【정답 포인트】 정답: A (X-Amz-Invocation-Type=Event 통합 요청 헤더) 비동기 호출이 되면 API는 즉시 응답하고 Lambda는 백그라운드에서 처리. 처리 완료 시 이메일 발송. 【오답 체크】 • B: 'maximum age of event'는 비동기 호출 큐 보존 시간이지 동기→비동기 전환 설정 아님 • C: 타임아웃을 늘려도 동기 호출이라 UI 즉시 응답 보장 못 함 • D: X-Amz-Target은 다른 의미(서비스 타깃 헤더)

해설

【핵심 용어】 • Lambda Layer: 공통 종속성 한 곳에서 관리, 버전 관리. 함수에서 layer ARN만 참조 【정답 포인트】 정답: C (공유 종속성을 Layer로 정의) 중복 작업 제거 + 일괄 업데이트 + 최소 복잡도. 【오답 체크】 • A: Maintenance window는 자동 업데이트 메커니즘 아님 • B: 런타임 업그레이드 자체는 종속성 업데이트와 다름 • D: CodeCommit 저장소만으로 자동 반영되지 않음

해설

【핵심 용어】 • DynamoDB TTL: 항목별 만료 시간(epoch seconds, Number)을 두면 백그라운드에서 자동 삭제 (무료) • Scan 기반 삭제는 비용 큼 【정답 포인트】 정답: D (TTL 속성 사용) Number 타입의 epoch 시간 속성을 만들고 TTL로 지정 → 만료된 항목 자동 삭제. 가장 비용 효율적. 【오답 체크】 • A, B: Scan 기반 삭제는 RCU/WCU 비용 발생, 게다가 EC2/ECS 운영비 추가 • C: GSI + Lambda 매분 실행 → WCU/Lambda 비용

해설

【핵심 용어】 • Secrets Manager: DB 자격증명 자동 회전 가능 • Parameter Store SecureString: 일반 설정값 보관에 적합 【정답 포인트】 정답: B (RDS 비밀은 Secrets Manager + 회전, 일반 매개변수는 Parameter Store SecureString) 보안 + 회전 + 코드 외부 + 재사용 + 코드 변경 없이 갱신을 모두 만족. 운영 부담 최소. 【오답 체크】 • A: Lambda 환경변수는 함수 단위 격리, 다른 앱 재사용 어려움 • C: 자체 회전 Lambda 작성은 운영 부담↑ • D: S3 사용은 부적절(접근 제어 복잡)

해설

【핵심 용어】 • 최소 권한 = 필요한 액션만 명시: codecommit:CreateBranch, codecommit:DeleteBranch 【정답 포인트】 정답: A (CreateBranch + DeleteBranch만) 필요한 두 액션만 추가 → 최소 권한. 【오답 체크】 • B: Put*는 너무 넓음 • C: Update*도 광범위 • D: *는 모든 권한

해설

【핵심 용어】 • ProvisionedThroughputExceededException: 한도 초과. SDK는 자동 재시도/지수 백오프 내장 • 직접 REST API 호출 시 재시도/백오프 직접 구현 필요 【정답 포인트】 정답: AB • A: 지수 백오프로 재시도 → 처리량 일시 초과 완화 • B: SDK 사용 시 자동 재시도/서명 처리 → 코드 단순화 + 비용 효율 【오답 체크】 • C: 처리량 증가는 비용↑(비용 효율 위반) • D: DAX는 읽기 캐시, 쓰기 한도 초과 해결과 무관 • E: 두 번째 테이블 분산은 데이터 모델 복잡도↑

해설

【핵심 용어】 • CodeBuild 환경변수 길이 제한 → Parameter Store 사용 시 build env가 외부 매개변수 참조로 우회 【정답 포인트】 정답: D (Systems Manager Parameter Store에 저장) 빌드 시 동적 참조로 가져오면 환경변수 자체 길이 제한 회피. 【오답 체크】 • A: 로케일 변경은 무관 • B: Cognito는 사용자 풀이지 키-값 저장소 아님 • C: S3는 가능하지만 표준은 Parameter Store

해설

【핵심 용어】 • Lambda@Edge: 사용자 요청 바로 처리 가능, 결과를 응답으로 반환 • 처리한 결과를 S3에 저장하여 캐시 → 다음 동일 요청 시 즉시 반환 (비용 효율) 【정답 포인트】 정답: D (Lambda@Edge로 즉시 처리 + S3에 저장) 수많은 디바이스 변형을 미리 모두 만들지 않고 요청 시점에 생성 → 사용된 변형만 저장(저장 비용↓). 두 번째 이후는 캐시. 【오답 체크】 • A, B: 수백 가지 변형을 미리 모두 생성하면 저장/시간 낭비 • C: TTL을 늘리면 캐시는 좋지만 새 요청마다 매번 처리 필요(저장 안 함)

해설

【핵심 용어】 • DAX: DynamoDB 인메모리 캐시. 마이크로초~밀리초 미만 조회. 코드 수정 거의 없이 적용 가능 • 서브-밀리초 지연이 핵심 요구 【정답 포인트】 정답: D (DAX 캐시) DAX 클러스터로 서브-밀리초 응답 + 거의 무코드 수정. 【오답 체크】 • A: LSI는 검색 패턴용, 지연 단축의 핵심 도구가 아님 • B: S3는 트레이딩 메인 데이터에 부적합 • C: 백오프는 한도 초과 대응이지 지연 단축이 아님

해설

【핵심 용어】 • EC2에서 X-Ray: ① X-Ray 데몬을 EC2에 설치(UDP 트레이스 수집기) ② 앱 코드에 X-Ray SDK 통합 【정답 포인트】 정답: BE • B: X-Ray daemon EC2에 설치 • E: Python용 X-Ray SDK 설치/구성 두 가지가 모두 있어야 트레이스 수집/전송 가능. 【오답 체크】 • A: CloudWatch agent는 지표/로그 용도 • C: 임의 경로의 JSON 로그가 X-Ray로 전송되지 않음 • D: /var/log/xray에 쓴다고 트레이스 되지 않음(데몬은 UDP 수신)

해설

【핵심 용어】 • Parameter Store SecureString: KMS로 암호화된 매개변수. 다 함수가 동일 값 안전 공유 가능 • 단일 연결 문자열 = 하나의 매개변수에 보관 【정답 포인트】 정답: C (SecureString 매개변수에 연결 문자열 보관) 공유 + 안전 보관 + 단일 출처. 회전 요구 없으니 Parameter Store로 충분. 【오답 체크】 • A: IAM 인증은 연결 문자열 단일 공유 모델과 다른 메커니즘 • B: RDS에 자격증명 저장은 모범사례 위배(서비스 계정 정보를 데이터 영역에 보관) • D: 함수마다 환경변수 → 단일 출처가 아님