정답 · 해설

해설

【핵심 용어】 ▸ HTTP(포트 80) vs HTTPS(포트 443): curl은 기본으로 HTTP 사용(https: 미지정 시) ▸ 아웃바운드 보안 그룹: 인스턴스 발신 트래픽 제어 ▸ 네트워크 ACL 임시 포트: 응답 수신용 1024-65535 범위 【정답 포인트】 ▸ (C) curl http://www.example.com은 포트 80(HTTP) 아웃바운드 요청 ▸ 현재 포트 443만 열려있으므로 포트 80 아웃바운드 규칙 추가 필요 ▸ CIDR 0.0.0.0/0(모든 대상)으로 설정 ▸ 보안 그룹은 Stateful이므로 응답 자동 처리 【오답 체크】 ▸ (A) 인바운드 NACL 추가는 응답 수신용이지만, 이미 임시 포트 범위 허용 ▸ (B) 인바운드 보안 그룹은 curl 요청(아웃바운드) 문제 해결 불가 ▸ (D) 아웃바운드 포트 80은 필요하지만 대상을 사용자 IP로 제한하면 안 됨 【시험 포인트】 ▸ curl 기본값은 HTTP(포트 80), https 스킴 필요 시 포트 443 ▸ 아웃바운드 요청 문제: 아웃바운드 보안 그룹 규칙 확인 ▸ 보안 그룹 Stateful 특성: 아웃바운드 허용 시 인바운드 응답 자동

해설

【핵심 용어】 ▸ 비용 할당 태그(Cost Allocation Tags): 리소스 태그를 활성화하여 Cost Explorer와 Billing Console에서 비용 추적 가능 ▸ Cost Explorer: 태그 기반 비용 분석 및 시각화 도구 ▸ 프로젝트 태그: 사용자 정의 태그로 비용 센터 관리 【정답 포인트】 ▸ (A) 비용 할당 태그 활성화 후 리소스에 "project" 태그 추가 ▸ Cost Explorer에서 태그별 비용 분류 및 분석 가능 ▸ 청구 데이터와 자동 동기화 ▸ 최소한의 설정으로 프로젝트별 비용 추적 실현 【오답 체크】 ▸ (B) 통합 청구는 다중 계정 관리용, 프로젝트 단위 분류 아님 ▸ (C) AWS Budgets는 예산 설정 및 알람, 비용 분석 아님 ▸ (D) 비용 카테고리는 Cost Allocation 태그 활성화 후 고급 그룹화용 【시험 포인트】 ▸ Cost Explorer 기본 설정: 비용 할당 태그 활성화 필수 ▸ 태그 중심 비용 관리: AWS 권장 모범 사례 ▸ 프로젝트별 비용 추적: "project" 태그 + Cost Allocation 조합

해설

【핵심 용어】 ▸ HealthyHostCount: ALB 대상 그룹의 정상 상태 호스트 수 메트릭 ▸ UnhealthyHostCount: 비정상 상태 호스트 수(모든 호스트 비정상이어도 >= 1은 부정확) ▸ StatusCheckFailed: EC2 인스턴스 시스템 상태(ALB 대상 상태와 독립적) 【정답 포인트】 ▸ (A) HealthyHostCount <= 0은 모든 대상이 비정상임을 명확히 나타냄 ▸ ALB 관점에서 직접 정상 호스트 수 모니터링 ▸ "모든 대상이 비정상" 조건을 가장 정확히 표현 ▸ ALB 메트릭(AWS/ApplicationELB) 사용이 정확 【오답 체크】 ▸ (B) UnhealthyHostCount >= 1은 일부 비정상도 감지, "모든 비정상" 조건 미충족 ▸ (C) StatusCheckFailed <= 0은 EC2 인스턴스 상태로, ALB 대상 상태와 일치하지 않음 ▸ (D) StatusCheckFailed >= 1은 개별 인스턴스 장애 감지용, ALB 대상 상태 아님 【시험 포인트】 ▸ ALB 헬스 체크 모니터링: AWS/ApplicationELB 네임스페이스 사용 ▸ HealthyHostCount 메트릭: 정상 대상 수 추적 ▸ 모든 대상 장애 감지: HealthyHostCount <= 0 사용

해설

【핵심 용어】 ▸ AWS CloudFormation StackSets: 조직 내 여러 계정과 리전에 스택 자동 배포 ▸ 중앙 집중식 SNS 주제: 로깅 계정의 SNS 주제로 모든 계정에서 게시 가능 ▸ 교차 계정 권한: SNS 주제 정책으로 다른 계정의 게시 허용 【정답 포인트】 ▸ (A) StackSets로 조직 내 모든 계정에 일관된 알람 배포 ▸ 중앙 SNS 주제로 모든 알람 이벤트 수집 ▸ 로깅 계정에 SNS 주제 중앙화로 통합 관리 ▸ 교차 계정 게시 권한으로 다중 계정 구조 지원 【오답 체크】 ▸ (B) 각 계정에 SNS 주제 생성 → 분산형 관리, 중앙 집중식 아님 ▸ (C) cron 기반 Lambda는 폴링 방식, CloudWatch 알람의 실시간성 미흡 ▸ (D) 변경 세트는 템플릿 배포 방식, 다중 계정 적용 안 됨, SES는 이메일 전용 【시험 포인트】 ▸ AWS Organizations 다중 계정 모니터링: CloudFormation StackSets 활용 ▸ 중앙 집중식 로깅: 중앙 계정에 SNS/S3/CloudWatch Logs 통합 ▸ 교차 계정 권한: IAM 역할 및 리소스 정책으로 구현

해설

【핵심 용어】 ▸ NAT 게이트웨이: 프라이빗 서브넷의 아웃바운드 트래픽을 인터넷으로 라우팅하는 관리형 서비스 ▸ 프라이빗 서브넷: DB 인스턴스는 프라이빗 서브넷에 위치, Lambda도 동일 네트워크 액세스 필요 ▸ VPC 엔드포인트: Lambda 인터넷 액세스는 NAT 게이트웨이로만 가능 【정답 포인트】 ▸ (C) Lambda를 프라이빗 서브넷에 배치 → DB 접근 가능 ▸ NAT 게이트웨이로 인터넷 액세스 구성 ▸ 라우팅 테이블: 0.0.0.0/0 → NAT 게이트웨이 ▸ 두 요구사항(DB 접근 + 인터넷) 동시 충족 【오답 체크】 ▸ (A) 퍼블릭 서브넷의 Lambda는 DB 프라이빗 서브넷 접근 어려움, 탄력적 IP 불필요 ▸ (B) 퍼블릭 서브넷은 DB 접근 제약, 인바운드 규칙은 수신용(아웃바운드 필요) ▸ (D) 인터넷 게이트웨이는 프라이빗 서브넷에 직접 라우팅 불가, NAT 게이트웨이 필수 【시험 포인트】 ▸ VPC Lambda: 프라이빗 서브넷 배치 + NAT 게이트웨이 조합 ▸ DB 액세스(내부) + 인터넷 액세스(외부): 프라이빗 서브넷 + NAT 구조 ▸ 인터넷 게이트웨이는 퍼블릭 서브넷 용, 프라이빗은 NAT 게이트웨이

해설

【핵심 용어】 ▸ RDS Proxy: 연결 풀링으로 DB 연결 수 제한 극복하는 관리형 프록시 서비스 ▸ 연결 풀 재사용: 애플리케이션의 많은 연결을 소수 DB 연결로 집계 ▸ 최소 코드 변경: 연결 문자열만 Proxy 엔드포인트로 수정 【정답 포인트】 ▸ (C) RDS Proxy는 연결 수 제한 문제의 표준 솔루션 ▸ 애플리케이션 로직 변경 없이 연결 문자열만 수정 ▸ 기존 인스턴스 크기 유지로 비용 절감 ▸ 연결 풀링으로 효율적 연결 관리 【오답 체크】 ▸ (A) 더 큰 인스턴스로 수직 확장해도 최대 연결 수 제한 문제 근본 해결 불가 ▸ (B) DynamoDB는 완전 다른 데이터베이스 패러다임, 대규모 코드 변경 필요 ▸ (D) 메모리 최적화는 성능 향상이지 연결 수 제한 해결 아님 【시험 포인트】 ▸ RDS 연결 수 문제: RDS Proxy가 최우선 솔루션 ▸ 코드 변경 최소: 연결 문자열 수정만 필요 ▸ 비용 효율성: 인스턴스 업그레이드 대비 낮은 비용

해설

【핵심 용어】 ▸ CloudWatch 알람: 메트릭 기반 임계값으로 자동 작업 트리거 ▸ CPU 사용률: 인스턴스 사용 여부 판단의 일반적 메트릭 ▸ 통계 평가 기간: 30분 동안 저사용 상태 지속 확인 【정답 포인트】 ▸ (B) CPU 사용률은 실제 사용량의 직접 지표 ▸ 5% 미만 30분 = 거의 미사용 상태 명확 ▸ CloudWatch 알람이 EC2 중지 작업 직접 지원 ▸ 자동화된 비용 절감 솔루션 【오답 체크】 ▸ (A) CloudTrail은 API 활동 추적 맞지만, 애플리케이션 실행 여부와 독립적(API 호출 없어도 실행 중 가능) ▸ (C) VolumeReadBytes는 스토리지 IO 메트릭, CPU 사용률보다 덜 신뢰할 수 있음 ▸ (D) Config는 구성 변경 감지용, 실제 사용량 기반이 아님 【시험 포인트】 ▸ 미사용 리소스 자동 중지: CPU 사용률 기반 CloudWatch 알람 ▸ 개발 환경 비용 최적화: 저사용률 모니터링 표준 방법 ▸ 임계값 설정: 5% 미만 & 30분 = 신뢰성 있는 판단

해설

【핵심 용어】 ▸ Amazon RDS for MySQL 다중 AZ: 서로 다른 가용 영역에 동기식 복제본으로 자동 장애 조치 ▸ 자동 복구: 다중 AZ는 주 인스턴스 장애 시 자동으로 복제본으로 전환 ▸ 최소 데이터 손실: 동기식 복제로 RPO 0에 근접 【정답 포인트】 ▸ (B) RDS 다중 AZ는 높은 가용성과 자동 장애 조치 제공 ▸ 자동 복구로 운영 개입 최소화 ▸ 동기식 복제로 데이터 손실 방지 ▸ EC2 기반 수동 MySQL보다 관리형 RDS가 훨씬 효율적 【오답 체크】 ▸ (A) EC2 인스턴스 중지/시작은 데이터 손실 방지 불가(하드웨어 장애 대응 아님) ▸ (C) 단일 AZ + 읽기 복제본은 자동 장애 조치 미지원, 수동 개입 필요 ▸ (D) EBS 스냅샷은 시점 복구만 가능, 자동 장애 조치 없음, RTO 길음 【시험 포인트】 ▸ 데이터 손실 최소화 + 복구 시간 단축: RDS 다중 AZ ▸ EC2 기반 DB → RDS 관리형 DB로 전환이 모범 사례 ▸ 높은 가용성 요구: 자동 장애 조치(다중 AZ) 필수

해설

【핵심 용어】 ▸ DeletionPolicy: CloudFormation 스택 삭제 시 리소스 처리 방법 결정 ▸ Retain: 스택 삭제 시에도 리소스 유지 ▸ Snapshot: EBS 볼륨은 스냅샷 생성 후 삭제(인스턴스 자체는 삭제) 【정답 포인트】 ▸ (D) DeletionPolicy를 Retain으로 설정하면 스택 삭제 시에도 EC2 인스턴스와 데이터 보존 ▸ 인스턴스 및 모든 데이터(EBS 볼륨) 완전히 유지 ▸ CloudFormation 템플릿 속성만 수정으로 간단히 구현 ▸ 명확한 의도(보관)를 직접 표현 【오답 체크】 ▸ (A) Snapshot은 EBS 스냅샷만 생성하고 인스턴스는 삭제됨 ▸ (B) Data Lifecycle Manager는 스택 삭제와 독립적, 백업 자동화일 뿐 ▸ (C) AWS Backup은 백업 계획일 뿐, 스택 삭제 시 인스턴스 보존 보장 안 함 【시험 포인트】 ▸ CloudFormation 스택 삭제 보호: DeletionPolicy = Retain ▸ DeletionPolicy 속성은 스택 삭제 시 리소스 운명 제어 ▸ "누군가가 스택을 삭제하더라도" 보호 → Retain 선택

해설

【핵심 용어】 ▸ Service Quotas: AWS 서비스 사용 제한을 모니터링하고 관리하는 서비스 ▸ CloudWatch 알람: 메트릭 기반 조건을 모니터링하여 자동 작업 수행 ▸ Lambda: 서버리스 컴퓨팅으로 할당량 증가 API 호출 【정답 포인트】 ▸ EC2 인스턴스 개수 모니터링: Service Quotas는 AWS 서비스 제한을 직접 추적합니다 ▸ 자동화된 할당량 증가: CloudWatch 알람이 임계값을 감지하면 Lambda 함수가 RequestServiceQuotaIncrease API를 호출합니다 ▸ 트리거 메커니즘: 알람→Lambda→API 호출의 자동화 워크플로우 【오답 체크】 (B) AWS Config는 구성 변경 추적용이며 Service Quotas 모니터링에 부적합(C) AWS Health Dashboard는 서비스 상태 정보이지 할당량 데이터를 제공하지 않음 (D) Trusted Advisor는 권장사항 제공용이며 실시간 할당량 증가 자동화에 미흡 【시험 포인트】 ▸ Service Quotas는 EC2, RDS 등 대부분의 AWS 서비스 제한 모니터링 가능 ▸ CloudWatch 알람은 메트릭 기반 자동화의 핵심 서비스 ▸ SysOps 시험에서는 CloudWatch + Lambda 조합이 자동 확장의 표준 패턴

해설

【핵심 용어】 ▸ Resource Groups: 태그 기반으로 EC2 인스턴스를 논리적으로 그룹화 ▸ Patch Manager: 자동 패치 관리 서비스 ▸ Maintenance Window: 정기적 작업 실행 일정 ▸ Automation Runbook: 패치 실행 절차 자동화 【정답 포인트】 ▸ A: Resource Groups로 OS별 인스턴스 그룹화가 기본 준비 단계 ▸ C: Automation 런북을 Maintenance Window의 작업으로 등록하여 자동 실행 ▸ E: 각 리소스 그룹당 별도 Maintenance Window로 유연한 스케줄 관리 ▸ 조합으로 월 1회 이상의 자동화된 패칭 실현 【오답 체크】 (B) Patch Manager의 스케줄 기능만으로는 런북 연동 부족 (D) 상태 모니터링 런북은 패치 실행이 아닌 확인 목적 (F) Fleet Manager는 에이전트 관리용이며 패치 자동화에 직접 연관 없음 【시험 포인트】 ▸ Patch Manager는 Systems Manager의 핵심 기능으로 자동 패칭 관리 ▸ Maintenance Window + Automation 조합이 반복적 작업 자동화의 표준 ▸ 대규모 인스턴스 관리 시 Resource Groups 필수

해설

【핵심 용어】 ▸ Service Control Policy(SCP): Organizations 레벨에서 조직 단위 전체에 적용되는 권한 제어 정책 ▸ OU(조직 단위): 계정들을 그룹화하여 정책 적용의 단위 ▸ 운영 효율성: 대규모 계정군에 일괄 적용 【정답 포인트】 ▸ SCP는 Organizations 서비스로 OU 레벨에서 모든 계정/사용자에 강제 적용 ▸ 개발자가 아닌 OU 전체의 권한 상한선(Permission Boundary)을 설정 ▸ 낮은 운영 오버헤드로 정책 관리: 단일 SCP로 수십 개 계정 제어 ▸ IAM 정책과 달리 각 사용자별 설정 불필요 【오답 체크】 (A) 개별 계정의 IAM 정책은 OU 전체에 일괄 적용 불가능 (B) 작업 함수 정책은 미리 정의된 역할로 세밀한 제어 부족 (D) API Gateway는 서비스 접근 제어용이며 서비스 이용 자체를 제한하지 않음 【시험 포인트】 ▸ SCP는 Organizations의 핵심 거버넌스 도구로 정책 위계 구조 제공 ▸ 프로덕션 환경 보호의 필수 솔루션: 최소 권한 원칙 적용 ▸ SysOps 시험에서 Organizations 문제는 거의 항상 SCP가 정답

해설

【핵심 용어】 ▸ Multi-AZ: 서로 다른 가용 영역의 동기식 복제본으로 자동 페일오버 지원 ▸ RDS Read Replica: 비동기식 복제로 수동 승격 필요 ▸ 자동 페일오버: 인스턴스 장애 시 자동으로 대기 인스턴스 활성화 【정답 포인트】 ▸ Multi-AZ는 동기식 복제로 트랜잭션 손실 없이(Zero RPO) 자동 페일오버 제공 ▸ 페일오버 시간: RTO 약 1-3분으로 빠른 복구 ▸ 자동 메커니즘: Lambda 함수 없이도 AWS가 자동으로 관리 ▸ 관리 간소화: 별도의 승격 로직이나 애플리케이션 수정 불필요 【오답 체크】 (A) 동일 리전 복제본은 리전 장애 시 보호 불가능 (B) 읽기 전용 복제본은 비동기식이라 일부 데이터 손실 가능성 있고 수동 승격 필요 (D) 메모리 재시작은 페일오버와 무관하며 가용성 보장 안 함 【시험 포인트】 ▸ DR 요구사항에서는 항상 Multi-AZ 먼저 검토 ▸ 자동 페일오버가 필수 시 Multi-AZ가 유일한 솔루션 ▸ RDS 고가용성: Multi-AZ로 99.95% SLA 달성

해설

【핵심 용어】 ▸ Simple Scaling: 단일 알람 기반으로 정확히 하나의 인스턴스 추가 ▸ Cooldown: 이전 스케일링 작업 후 다음 스케일링까지 대기 시간(기본값 300초) ▸ RequestCountPerTarget: ALB당 요청 수 메트릭 【정답 포인트】 ▸ Simple Scaling에서 두 번의 메트릭 초과: 첫 번째 초과 시 1개 인스턴스 추가 ▸ 쿨다운 기간(기본 300초): 두 번째 초과는 180초 내에 발생했으므로 쿨다운 중 무시됨 ▸ 최종 결과: 정확히 1개 인스턴스만 추가됨 ▸ Simple Scaling의 특성: 각 트리거마다 1개씩만 추가 【오답 체크】 (A) 두 번 초과했으므로 2개 추가될 수 있지만 쿨다운이 중간에 작동 (C) ALB 재조정은 스케일링 결정과 무관함 (D) 모든 인스턴스 간 재분배만으로 스케일링하지 않음 【시험 포인트】 ▸ Simple Scaling vs Step Scaling 구분 필수: Simple은 1개씩, Step은 조건별 ▸ 쿨다운 기간은 과도한 스케일링 방지의 핵심 메커니즘 ▸ 기본값 300초는 일반적 프로덕션 환경의 표준 설정

해설

【핵심 용어】 ▸ SSL/TLS 협상: 클라이언트와 서버 간 보안 프로토콜 및 암호화 알고리즘 선택 ▸ Security Policy: ALB에서 지원하는 TLS 버전과 암호화 종류 정의 ▸ Legacy Browser 호환성: 낮은 TLS 버전(TLS 1.0 등) 지원 필요 【정답 포인트】 ▸ ALB Security Policy 변경으로 레거시 암호화 알고리즘 활성화 ▸ ACM 인증서는 유지되고 정책만 변경하면 호환성 확보 ▸ 가장 간단하고 빠른 해결: 인프라 변경(새 ALB, 서버 설치) 불필요 ▸ 비용 효율적: 추가 리소스 생성 없음 【오답 체크】 (A) 새 인증서 생성은 도움 안 됨, 문제는 암호화 알고리즘 미지원 (B) 두 번째 ALB 추가는 운영 복잡도 증가 및 비용 낭비 (C) ALB 제거 후 직접 SSL 설치는 로드 밸런싱 이점 상실 및 관리 어려움 【시험 포인트】 ▸ ALB Security Policy는 AWS 관리형 정책과 커스텀 정책 선택 가능 ▸ 레거시 지원 정책: AWS 권장 사항(Legacy) 정책에 포함 ▸ 보안과 호환성의 균형: 필요한 경우만 하위 TLS 버전 활성화

해설

【핵심 용어】 ▸ Application Load Balancer(ALB): 계층 7(애플리케이션 계층) 라우팅으로 URL 경로 기반 분배 ▸ 경로 기반 라우팅: URL 경로(/api/*, /images/* 등)로 대상 선택 ▸ Network Load Balancer(NLB): 계층 4(전송 계층)로 경로 라우팅 미지원 【정답 포인트】 ▸ ALB만이 URL 경로 기반 라우팅 규칙(Path-based routing) 제공 ▸ /legacy/* 경로 → EC2 인스턴스, /new/* 경로 → Lambda 함수 매핑 가능 ▸ 호스트 기반, 경로 기반, 호스트 헤더 등 계층 7 라우팅 규칙 지원 ▸ Lambda를 ALB 대상 그룹의 타겟으로 직접 설정 가능 【오답 체크】 (A) Gateway Load Balancer는 제3자 가상 어플라이언스(방화벽 등) 라우팅용 (B) NLB는 계층 4로 URL 경로 분석 불가능 (C) NLB는 경로 기반 라우팅 지원 안 함 【시험 포인트】 ▸ ALB의 핵심 기능: 경로, 호스트, HTTP 헤더 기반 라우팅 ▸ 마이크로서비스 및 카나리 배포 패턴의 표준 도구 ▸ Lambda를 웹 애플리케이션 백엔드로 사용할 때 ALB + Lambda 조합 권장

해설

【핵심 용어】 ▸ Security Group: 인스턴스 레벨의 상태 유지형(Stateful) 방화벽으로 인바운드/아웃바운드 트래픽 제어 ▸ SSH(Port 22): Linux 원격 접속 프로토콜 ▸ 공개 IP: 인터넷에서 접근 가능한 주소 【정답 포인트】 ▸ 시간 초과 오류: 인스턴스가 SSH 요청을 수신하지 못함(인바운드 차단) ▸ Security Group 기본값: 인바운드 모두 거부, 아웃바운드 모두 허용 ▸ 해결책: 보안 그룹에 SSH 인바운드 규칙 추가 (/0 또는 관리자 IP) ▸ Security Group은 Stateful이므로 아웃바운드 규칙 수정 불필요 【오답 체크】 (A) 경로 테이블은 트래픽 라우팅이지 접근 제어 아님 (B) Network ACL이 아닌 Security Group에 SSH 허용 규칙 추가 필요 (D) SSH는 클라이언트가 포트 22로 요청(인바운드)하므로 아웃바운드 규칙은 무관 【시험 포인트】 ▸ 연결 문제 진단: 경로 테이블 → 네트워크 ACL → 보안 그룹 순서로 확인 ▸ Security Group 우선: 가장 일반적인 원인 ▸ 관리자 편의상 0.0.0.0/0으로 허용하거나 특정 IP 제한 가능

해설

【핵심 용어】 ▸ Cluster Placement Group: 동일 가용 영역 내 인스턴스들을 물리적으로 가깝게 배치하여 네트워크 성능 최적화 ▸ 저지연시간: 네트워크 인터럽트 시간 <200마이크로초 ▸ 높은 대역폭: 인스턴스 간 집계 네트워크 처리량 최대화 【정답 포인트】 ▸ Cluster Placement Group은 HPC 애플리케이션 필수 구성 ▸ 10 Gbps 이상 네트워크 성능 제공 ▸ 클러스터 내 모든 인스턴스가 단일 가용 영역에 배치 ▸ 저지연 cluster placement network 사용 ▸ 인스턴스 그룹 내 무제한 네트워크 성능 【오답 체크】 (B) Auto Scaling은 다중 가용 영역 분산으로 지연시간 증가 (C) NLB는 로드 밸런싱이지 저지연 통신 최적화 아님 (D) 단순 같은 AZ 배치는 인스턴스 간 네트워크 최적화 없음 【시험 포인트】 ▸ HPC, 빅 데이터 애플리케이션은 Cluster Placement Group 필수 ▸ 배치 그룹 전략: Cluster(HPC), Partition(Hadoop), Spread(고가용성) ▸ SysOps 시험의 배치 그룹 문제는 거의 항상 Cluster 관련

해설

【핵심 용어】 ▸ Reserved Concurrency: Lambda 함수의 동시 실행 수 상한선 설정 ▸ 0으로 설정: 함수 실행 차단, 기존 실행 완료 후 새 호출 거부 ▸ 무한 루프: S3 Put → Lambda 호출 → S3 Put → 반복 【정답 포인트】 ▸ Reserved Concurrency를 0으로 설정하면 새 호출 즉시 중지 ▸ 기존 실행 중인 Lambda는 완료될 때까지 대기하므로 오류 최소화 ▸ 빠른 응답: S3 이벤트 소스에 오류 반환하여 재시도 중단 ▸ 영구적 해결: 객체 삭제 불필요, 코드 수정 후 동시성 복구 【오답 체크】 (A) 객체 삭제는 데이터 손실 야기 ▸ 루프만 중지할 뿐 원본 문제 해결 아님 (C) S3 버킷 정책 변경은 느림 ▸ 런타임에 정책 적용 지연 가능 (D) 새 버전 발행은 기존 매핑된 버전 유지 ▸ 루프 중단 효과 없음 【시험 포인트】 ▸ Lambda 동시성 관리: Provisioned vs Reserved ▸ 응급 상황 처리: Reserved Concurrency 0 설정이 가장 빠른 방법 ▸ S3 이벤트 + Lambda 루프는 흔한 실수이며 SysOps 시험 단골

해설

【핵심 용어】 ▸ Latency Routing: Route 53이 클라이언트에서 각 엔드포인트까지의 실제 네트워크 지연시간 측정하여 가장 빠른 엔드포인트로 라우팅 ▸ 지연시간 기반: 지리적 위치 아닌 실제 네트워크 성능 기준 ▸ Geolocation Routing: 사용자의 물리적 위치 기반(부정확) 【정답 포인트】 ▸ Latency Routing은 사용자의 실제 네트워크 지연 측정 ▸ us-west-2의 사용자는 us-west-2 ALB로, ap-southeast-2의 사용자는 ap-southeast-2 ALB로 자동 라우팅 ▸ URL 변경 불필요: 동일 app.anycompany.com 유지 ▸ 성능 최적화: 각 지역 사용자의 최소 지연시간 엔드포인트 선택 【오답 체크】 (A) 단순히 새 값 추가는 round-robin 분산이므로 지연시간 최적화 안 함 (B) 지리적 위치 라우팅은 IP 지오로케이션 기반으로 부정확 (D) 다중 값은 랜덤 선택이며 지연시간 고려 없음 【시험 포인트】 ▸ Route 53 라우팅 정책: Simple, Weighted, Latency, Failover, Geolocation, Multivalue ▸ 성능 최적화 → Latency Routing 우선 고려 ▸ Geolocation과 Latency 혼동 주의: 정확성은 Latency가 우수