정답 · 해설

해설

【핵심 용어】 ▸ EKS 커넥터—온프레미스/멀티클라우드 K8s를 EKS 콘솔에 등록 ▸ 중앙 관리—AWS 콘솔 하나에서 모든 클러스터 제어 【정답 포인트】 ▸ "EKS+온프레미스 K8s"→EKS 커넥터 정확한 용도 ▸ "중앙 위치에서 보기"→AWS 콘솔 통합 관리 ▸ "최소 오버헤드"→커넥터는 관리형, 에이전트만 배포 【오답 체크】 (A) Container Insights는 모니터링만, 등록 기능 없음 (C) Systems Manager는 EC2/온프레미스 에이전트, 커넥터 미지원 (D) EKS Anywhere는 온프레미스 EKS, 기존 K8s 통합 안함 【시험 포인트】 ▸ "EKS+온프레미스+중앙관리"=EKS 커넥터 ▸ 하이브리드 K8s 관리의 표준 답변

해설

【핵심 용어】 ▸ AWS DMS—온프레미스→AWS 데이터베이스 마이그레이션 전문 도구 ▸ Aurora—MySQL 호환, Auto Scaling, 고성능 【정답 포인트】 ▸ "MySQL 호환성"→Aurora는 MySQL 호환 DB 엔진 ▸ "자동 확장"→Aurora Auto Scaling 완벽 지원 ▸ "마이그레이션"→DMS 자동화된 전환 【오답 체크】 (A) RDS MySQL도 호환이나 Auto Scaling이 제한적 (B) Redshift는 분석용 DW, 트랜잭션 부하 부적절 (D) DynamoDB는 NoSQL, MySQL 관계형 스키마 호환 불가 【시험 포인트】 ▸ "MySQL호환+AutoScaling+마이그레이션"=Aurora+DMS ▸ Aurora는 MySQL 호환성의 우월한 선택

해설

【핵심 용어】 ▸ EFS—멀티 AZ 공유 파일 시스템, POSIX 호환 ▸ 계층적 디렉터리—파일 시스템 구조 요구 【정답 포인트】 ▸ "2개 AZ+공유 스토리지"→EFS 멀티 AZ 지원 ▸ "동시 빠른 읽고 쓰기"→EFS 병렬 접근 최적화 ▸ "계층적 디렉터리"→EFS는 POSIX 파일 시스템 【오답 체크】 (A) S3는 객체 스토리지, 계층적 디렉터리/동시 접근 부적절 (C) EBS는 단일 인스턴스 블록, 멀티 AZ 공유 불가 (D) EBS 인스턴스별 동기화는 복잡하고 충돌 위험 【시험 포인트】 ▸ "멀티AZ+공유+계층적+동시접근"=EFS 확정 ▸ EFS="공유 파일 시스템" 용도의 표준 답변

해설

【핵심 용어】 ▸ API Gateway+Lambda—서버리스, 관리 최소 ▸ DynamoDB—시계열 데이터 최적화, 자동 확장 【정답 포인트】 ▸ "HTTP 요청 수신"→API Gateway 표준 선택 ▸ "관리 서비스"→Lambda(서버리스)+DynamoDB(관리형) ▸ "향후 기능 추가"→서버리스로 컴포넌트 추가 용이 【오답 체크】 (B) EC2 Auto Scaling은 관리 부담 (OS/보안 패치) (C) SQL Server Express는 관리형 아님, 운영 오버헤드 (D) EFS는 파일 스토리지, 시계열 데이터 부적절 【시험 포인트】 ▸ "관리서비스+최소오버헤드+확장성"=API Gateway+Lambda+DynamoDB ▸ 서버리스="미래 확장" 시뮬레이션에 강함

해설

【핵심 용어】 ▸ AWS/Events 네임스페이스—EventBridge 규칙 평가/호출 지표 ▸ CloudWatch 지표—Invocations, FailedInvocations 메트릭 【정답 포인트】 ▸ "규칙 조건 충족 확인"→CloudWatch 지표 (Rules matched) ▸ "대상 호출 확인"→CloudWatch 지표 (Invocations) ▸ "즉시 진단"→CloudWatch 네임스페이스에서 확인 【오답 체크】 (B) DLQ는 실패 메시지만, 호출 여부 확인 어려움 (C) CloudWatch Logs는 이벤트 로깅 자동 아님 (D) CloudTrail은 API 호출, EventBridge 규칙 추적 제한적 【시험 포인트】 ▸ EventBridge 트러블슈팅=AWS/Events CloudWatch 지표 ▸ "규칙조건+호출확인"=CloudWatch 지표 체크 패턴

해설

【핵심 용어】 ▸ Auto Scaling 예약 작업—정기적 시간대 자동 확장 설정 ▸ 금요일 저녁 반복—스케줄 기반 트리거 【정답 포인트】 ▸ "매주 금요일"→예측 가능한 반복 일정 ▸ "최소 오버헤드"→예약 작업 자동화 (수동 불필요) ▸ "2개→6개 인스턴스"→ASG 예약 스케일링 정확히 제어 【오답 체크】 (A) EventBridge는 수동 트리거용, 반복 스케줄은 ASG 전문 (C) 수동 조정=매주 직접 조작 필요 (오버헤드 높음) (D) 자동 조정=부하 기반, 반복 일정 전용 아님 【시험 포인트】 ▸ "정기적반복+예측가능시간"=Auto Scaling 예약 작업 ▸ 예약 작업="스케줄 기반 확장"의 정답 패턴

해설

【핵심 용어】 ▸ API Gateway HTTP API—TLSv1.3 자동 지원, 사용자 도메인으로 타사 CA 인증서 적용 ▸ ACM—타사 CA에서 서명받은 인증서 생성/관리 【정답 포인트】 ▸ 타사 CA 요구사항→ACM에서 직접 생성 (수동 임포트 불필요) ▸ HTTP API는 TLSv1.3 지원하고 사용자 도메인에 ACM 적용 ▸ REST API 아닌 HTTP API가 간단한 구성 【오답 체크】 (A) 수동으로 인증서 생성 후 임포트—ACM에서 직접 생성 가능하므로 비효율 (C) Lambda URL은 사용자 도메인/타사 CA 인증서 미지원 (D) Lambda URL은 고급 인증서 설정 미지원 【시험 포인트】 ▸ API Gateway vs Lambda URL—인증서 관리 차이 구분 ▸ ACM 타사 CA 기능—수동 임포트 vs 직접 생성

해설

【핵심 용어】 ▸ Aurora Serverless v2—트래픽에 따라 자동 확장/축소, MySQL 호환 ▸ ACU—Aurora Capacity Unit, 0.5부터 세밀 스케일링 【정답 포인트】 ▸ 일관되지 않은 사용량+자동 확장→Serverless v2 필수 ▸ Serverless v2는 0.5 ACU 단위로 최소 오버헤드 달성 ▸ MySQL 호환성 유지 필수 【오답 체크】 (A) DynamoDB는 NoSQL, MySQL 호환성 불일치 (B) Aurora 프로비저닝 버전—수동 용량 조정 필요 (D) RDS for MySQL—프로비저닝 기반, Auto Scaling 미지원 【시험 포인트】 ▸ Serverless v1 vs v2—v2는 ACU 세밀 조정 가능 ▸ 불규칙 트래픽="Serverless v2" 핵심 포인트

해설

【핵심 용어】 ▸ SnapStart—런타임 스냅샷 캐싱으로 콜드 스타트 90% 감소 (Java 지원) ▸ 프로비저닝된 동시성—항상 웜 상태 유지로 비용 높음 【정답 포인트】 ▸ 비용 효율성+콜드 스타트 감소→SnapStart 최적 ▸ Java 11은 SnapStart 지원 (런타임 사전 초기화 캐싱) ▸ 스케일 아웃 시 새 인스턴스도 스냅샷으로 빠름 【오답 체크】 (A) 프로비저닝된 동시성—항상 활성으로 비용 매우 높음 (B) 타임아웃 증가—콜드 스타트 해결 불가 (C) 메모리 증가—CPU 향상되나 근본 해결 아님 【시험 포인트】 ▸ SnapStart는 Java에만 지원, 비용 효율적 콜드 스타트 솔루션 ▸ 엄격한 지연 시간 없을 때 프로비저닝 대신 SnapStart

해설

【핵심 용어】 ▸ Aurora Serverless v2—사용하지 않을 때 0.5 ACU로 축소, 분 단위 과금 ▸ RDS 프로비저닝—항상 인스턴스 비용 발생 【정답 포인트】 ▸ 주간 2시간만 사용→나머지 시간 거의 무료 상태 ▸ Serverless v2는 비활성 기간 최소 비용으로 운영 ▸ 중단/재개 오버헤드 없이 자동 스케일링 【오답 체크】 (B) Aurora 프로비저닝—미사용 시간 전체 비용 소모 (C) EC2+예약 인스턴스—52주 분 비용 지불로 비효율 (D) ECS 클러스터—스케줄링 복잡하고 상시 관리 필요 【시험 포인트】 ▸ 극도로 비정규적 사용→Serverless v2 가성비 최적 ▸ RDS 프로비저닝 vs Serverless 비용 차이 이해 필수

해설

【핵심 용어】 ▸ Multi-AZ DB 클러스터—최대 15개 읽기 복제본, 즉시 페일오버 ▸ 다중 AZ 배포—프라이머리+스탠바이 2개 인스턴스만 【정답 포인트】 ▸ 높은 가용성+읽기 확장성→Multi-AZ DB 클러스터 ▸ 단일 리전 내 3개 AZ에 걸쳐 분산 배포 ▸ 읽기 워크로드 증가→읽기 전용 복제본으로 처리 【오답 체크】 (A) DynamoDB는 PostgreSQL 요구 불일치, NoSQL (B) 다중 AZ 배포—읽기 확장성 부족 (2개 인스턴스만) (D) 리전 간 복제본—리전 간 레이턴시 증가, 복제 지연 【시험 포인트】 ▸ 단일 리전 내 고가용성+읽기 확장=Multi-AZ DB 클러스터 ▸ 리전 간 DR vs 리전 내 확장성 구분 필수

해설

【핵심 용어】 ▸ 엣지 최적화 엔드포인트—CloudFront 글로벌 네트워크로 지연 시간 최소화 ▸ 지역 엔드포인트—단일 리전 내 클라이언트만 최적화 【정답 포인트】 ▸ 지리적으로 분산된 사용자→글로벌 배포 필수 ▸ CloudFront 엣지 로케이션에서 캐싱 및 라우팅 ▸ 엣지 최적화 엔드포인트는 기본적으로 CloudFront 통합 【오답 체크】 (A) 프라이빗 엔드포인트—VPC 내부용, 글로벌 레이턴시 감소 불가 (B) 지역 엔드포인트—단일 리전 내에서만 최적화 (C) VPC 엔드포인트—AWS 서비스 프라이빗 접근용 【시험 포인트】 ▸ API Gateway 엔드포인트 3가지 구분 (프라이빗/지역/엣지) ▸ 글로벌 사용자 레이턴시=엣지 최적화만 정답

해설

【핵심 용어】 ▸ ACM—TLS 인증서 자동 갱신 (DNS 검증 시 완전 자동화) ▸ DNS 검증 vs 이메일 검증—자동화 수준 차이 【정답 포인트】 ▸ 자동 갱신 필수→ACM 사용 ▸ DNS 검증은 완전 자동화 (이메일 검증은 수동 승인 필요) ▸ CloudFront는 ACM 인증서 기본 지원 【오답 체크】 (A) CloudFront 보안 정책—인증서 생성 기능 없음 (B) OAC—원본 보안 기능으로 인증서 생성 불가 (D) 이메일 검증—매 갱신 시 수동 승인 필요 【시험 포인트】 ▸ ACM DNS 검증→완전 자동화된 갱신 가능 ▸ CloudFront 인증서 관리→ACM 선택이 표준

해설

【핵심 용어】 ▸ DAX—마이크로초 응답 시간, DynamoDB 네이티브 캐싱 ▸ ElastiCache—별도 관리 필요, 애플리케이션 수정 필수 【정답 포인트】 ▸ DynamoDB 사용 유지+마이크로초 대기→DAX ▸ DAX는 메모리 캐시로 네이티브 통합 ▸ 최소 운영 오버헤드 (관리형 서비스) 【오답 체크】 (B) Redshift—OLAP용, DynamoDB 트랜잭션 특성 손실 (C) RDS—완전히 다른 데이터베이스로 마이그레이션 필요 (D) ElastiCache—별도 인스턴스 관리, 애플리케이션 코드 변경 【시험 포인트】 ▸ DynamoDB 최적화→DAX는 반드시 알아야 할 솔루션 ▸ 밀리초 vs 마이크로초=DAX의 특정 강점

해설

【핵심 용어】 ▸ AWS 인스턴스 스케줄러—반복 패턴 기반 자동 시작/중지 ▸ 규정적 비용 절감 (업무 시간만 활성화) 【정답 포인트】 ▸ 평일 업무 시간 패턴→인스턴스 스케줄러로 자동화 ▸ 설정 후 무중단 운영, 운영 오버헤드 최소 ▸ Lambda 함수보다 관리형이므로 우수 【오답 체크】 (B) 백업 정책—비용 최적화와 무관, 재해 복구 측면 (C) Lambda 함수—커스텀 개발 필요, 운영 오버헤드 증가 (D) 예약 인스턴스—미사용 시간도 비용 발생, 역효과 【시험 포인트】 ▸ 정기적 패턴 사용→AWS 인스턴스 스케줄러 최고 선택 ▸ RDS 수동 중지 vs 자동화의 중요성 이해

해설

【핵심 용어】 ▸ 고가용성—여러 AZ에 걸친 분산 배포 ▸ 내결함성—AZ 장애 시에도 최소 2개 인스턴스 유지 【정답 포인트】 ▸ 최소 2개 인스턴스 필수+고가용성→다중 AZ 전개 ▸ 각 AZ에 2개씩 배포하면 AZ 장애 시에도 2개 유지 ▸ 최소 용량 4개 설정으로 오토스케일링 정상 작동 【오답 체크】 (A) 단일 인스턴스×2AZ—AZ 장애 시 1개만 남음 (C) 단일 AZ 스팟—AZ 장애 시 모두 손실 (D) 스팟 인스턴스 혼재—스팟 중단 시 수준 미달 【시험 포인트】 ▸ 다중 AZ 설계 시 각 AZ별 독립적 용량 배치 ▸ 상태 저장 앱→스팟 인스턴스 부적합

해설

【핵심 용어】 ▸ 지리적 위치 라우팅—사용자 위치 기반 최적 엔드포인트로 라우팅 ▸ 레이턴시 라우팅—실시간 응답 시간 측정 기반 【정답 포인트】 ▸ 지역별 최적 리소스→지리적 위치 라우팅 필수 ▸ us-west-1 근처→온프레미스 데이터 센터 (가장 빠름) ▸ eu-central-1 근처→eu-central-1 (가장 빠름) 【오답 체크】 (B) 단순 라우팅—지리적 최적화 불가, 라운드 로빈만 (C) 레이턴시 라우팅—온프레미스 엔드포인트 헬스 체크 복잡 (D) 가중치 기반—성능 기반 아니라 고정 가중치만 【시험 포인트】 ▸ Route 53 라우팅 정책 구분—지리적 vs 레이턴시 ▸ 온프레미스+클라우드 하이브리드=지리적 위치 최적

해설

【핵심 용어】 ▸ Snowball 테이프 게이트웨이—5PB 대용량 오프라인 전송 ▸ Glacier Deep Archive—장기 보관 최저 비용 【정답 포인트】 ▸ 5PB 규모+1Gbps 제한→인터넷 전송 불가능 (700+ 일 소요) ▸ Snowball 물리 배송→6개월 내 완료 가능 ▸ 10년 보관→Deep Archive 최저 비용 【오답 체크】 (A) DataSync 인터넷 전송—5PB를 1Gbps로는 현실 불가 (B) 직접 쓰기—백업 애플리케이션으로는 대용량 처리 어려움 (D) 온프레미스 테이프 게이트웨이—여전히 네트워크 의존 【시험 포인트】 ▸ 대용량+네트워크 제약→Snowball 선택 필수 ▸ 아카이브 보관→Deep Archive 가성비 최고

해설

【핵심 용어】 ▸ 분산 배치 그룹—노드가 별도 하드웨어 랙에 배치 ▸ 병렬 처리—독립적 하드웨어 보장으로 성능 예측 가능 【정답 포인트】 ▸ 동일 하드웨어 공유 금지→분산 배치 그룹만 충족 ▸ 여러 AZ/Rack 분산으로 장애 격리 ▸ 병렬 성능 최적화 【오답 체크】 (B) 별도 계정—물리 하드웨어 배치와 무관 (C) 전용 테넌시—호스트 전체 전용이나 호스트 내 공유 가능 (D) 공유 테넌시—다른 고객과 하드웨어 공유 【시험 포인트】 ▸ EC2 배치 그룹 3가지 (클러스터/분산/파티션) 구분 ▸ 분산 배치 그룹=독립적 하드웨어 보장

해설

【핵심 용어】 ▸ 용량 예약 — 온디맨드 요금으로 용량 미리 확보 ▸ 예약 인스턴스 — 1~3년 약정으로 할인 【정답 포인트】 ▸ 재해 조치 → 평상시는 미사용 ▸ 용량 예약만 온디맨드 유연성 + 용량 보장 ▸ 필요 시에만 인스턴스 시작 【오답 체크】 (A) 온디맨드 구매 — 용량 보장 안 함 (B) Savings Plan — 1년 이상 약정, DR은 단기성 (C) 지역 예약 — 1~3년 약정 필수, DR 유연성 제약 【시험 포인트】 ▸ DR 용량 확보 → 용량 예약이 유일한 정답 ▸ 예약 인스턴스 vs 용량 예약의 비용/유연성 차이