AWS SAA C03 연습 문제 (526~550번)

정답은 D입니다. 장애 조치 중에 다운타임이 발생하는 주된 이유는 애플리케이션이 새로운 기본(Writer) 인스턴스를 찾고 다시 연결하는 데 시간이 걸리기 때문입니다. RDS Proxy를 사용하면 프록시가 내부적으로 재연결을 처리하고 앱과의 연결을 유지해주므로, 장애 조치 시간이 획기적으로(최대 66% 이상) 단축됩니다. 다른 옵션인 A나 C는 읽기 성능에는 도움이 되지만, 쓰기 서버의 장애 조치 시간 자체를 줄여주지는 못합니다.

정답은 D입니다. 리전 전체의 장애에도 끄떡없는 구조를 만들려면 '리전 수준의 복제'가 핵심입니다. Aurora 글로벌 데이터베이스는 리전 간 데이터를 아주 빠르게 복제하며, 재난 시 보조 리전을 주 리전으로 즉시 승격시킬 수 있습니다. 여기에 Route 53의 상태 확인 기능을 더하면 사용자를 살아있는 리전으로 자동 안내할 수 있어 최고의 내결함성을 달성합니다. 다른 옵션인 A는 기술적으로 불가능하거나(ASG는 리전 내 가용 영역 간에만 확장 가능), B/C는 복구 시간이나 비용 면에서 글로벌 데이터베이스보다 효율이 떨어집니다.

정답은 D입니다. '운영 효율성'과 '실시간성'을 모두 잡으려면 서버리스 조합이 정답입니다. AWS Transfer Family는 FTP 서버를 따로 관리할 필요가 없게 해주고, S3와 람다를 연동하면 파일이 들어오자마자 개별적으로 즉시 처리(3~8분은 람다 실행 시간 내)할 수 있습니다. 처리 완료 후 삭제 로직도 람다 코드 한 줄로 해결되니 매우 깔끔합니다. 다른 옵션인 A나 B처럼 밤까지 기다렸다가 한꺼번에 처리하는 방식은 '가능한 한 빨리 처리'하라는 요구 사항에 어긋납니다.

정답은 B입니다. 관리 부담을 줄이려면 '완전 관리형 서비스'인 RDS를 쓰는 것이 정석입니다. RDS는 패치, 백업, 보안 업데이트를 AWS가 대신 해주며, 민감한 정보를 보호하기 위한 암호화 기능도 클릭 한 번으로 적용할 수 있어 보안과 운영 효율을 동시에 잡을 수 있습니다. 다른 옵션인 A는 서버를 직접 관리해야 하므로 오버헤드가 크고, C는 정형화된 DB 워크로드에는 어울리지 않는 방식입니다.

정답은 C입니다. 게임처럼 지연 시간(Latency)에 민감하고 TCP/UDP를 모두 쓰는 서비스에는 Global Accelerator가 만능 열쇠입니다. 사용자 트래픽을 가장 가까운 AWS Edge 서버로 끌어들여 AWS 전용망을 타고 전송하므로 일반 인터넷을 통할 때보다 훨씬 빠르고 안정적입니다. 다른 옵션인 A(CloudFront)는 주로 HTTP/HTTPS 스타일의 정적 콘텐츠에 최적화되어 있어 일반적인 UDP 게임 트래픽에는 적합하지 않습니다.

정답은 A입니다. 람다 함수 URL은 람다 인스턴스에 직접 URL 주소를 부여하는 가장 단순한 방법입니다. 로드 밸런서(ALB)나 API Gateway 같은 중간 단계 없이도 외부에서 HTTP 호출로 우리 람다를 바로 실행할 수 있어 운영 오버헤드가 거의 없습니다. 다른 옵션인 B는 비용과 관리 포인트가 늘어나며, C나 D는 외부 업체가 AWS의 특정 프로토콜을 따라야 하므로 호환성 면에서 번거롭습니다.

정답은 A, D, F입니다. (원문 index 0, 3, 5) 수백 명의 고객 주소를 하나하나 관리하는 건 불가능합니다. 따라서 '와일드카드(*)'를 활용하는 게 핵심입니다. Route 53에서 와일드카드 레코드를 만들고(A), 서버 리전의 ACM에서 와일드카드 인증서를 준비한 뒤(D), API Gateway에서 사용자 지정 도메인으로 묶어주면(F) 어떤 고객 주소가 들어와도 우리 앱이 안전하게 맞이할 수 있습니다. 다른 옵션인 C나 E처럼 고객별로 자원을 하나하나 만드는 방식은 고객이 늘어날 때 관리 지옥에 빠지게 됩니다.

정답은 A입니다. S3에서 '개인정보'를 전문적으로 찾아내는 탐정은 Amazon Macie입니다. Macie가 민감한 데이터(이름, 주소 등)를 발견하면 EventBridge가 이 신호를 가로채서 보안 팀의 이메일이나 휴대폰으로 SNS 알림을 전송하는 것이 가장 빠르고 표준적인 대응 시나리오입니다. 다른 옵션인 GuardDuty는 외부 해킹이나 이상 공격을 감시하는 도구이지, 파일 속 내용물(PII)을 검사하는 용도는 아닙니다.

정답은 C입니다. 로그처럼 양은 많지만 분석이 끝나면 거의 열어보지 않는 데이터는 S3 수명 주기 정책(Lifecycle Policy)이 효자입니다. 30일간의 분석이 끝난 뒤 검색 비용은 좀 들지만 저장 비용이 매우 저렴한 Glacier로 확 낮춰버리고, 총 보관 기간인 90일이 차면 자동으로 사라지게(Expiration) 설정하는 것이 가장 돈을 아끼는 비법입니다. 다른 옵션인 A는 저장 비용이 계속 비싸게 나가고, B는 거쳐가는 단계가 너무 많아 관리만 복잡해집니다.

정답은 B입니다. 쿠버네티스의 비밀 정보(Secret)는 기본적으로 평문 혹은 단순 인코딩 상태로 DB(etcd)에 들어갑니다. EKS의 'KMS 비밀 암호화' 옵션을 켜면, 이 정보들이 DB에 쓰여지기 직전에 우리가 만든 KMS 키로 단단히 암호화되어 저장됩니다. 데이터가 들어있는 창고(저장소) 수준에서 보안을 강화하는 필수 조치입니다. 다른 옵션인 A는 앱 레벨의 관리고, C/D는 물리 하드디스크 차원의 암호화라 etcd 소프트웨어 보안과는 결이 다릅니다.

정답은 D입니다. 최근 RDS에 도입된 '다중 AZ 클러스터' 배포 방식은 1개의 주 서버와 2개의 읽기 가능한 대기 서버를 제공합니다. 일반 다중 AZ는 대기 서버를 평소에 못 쓰지만, 클러스터 방식은 대기 서버들로 읽기 트래픽을 보낼 수 있습니다. 복잡한 복제본 추가 없이도 고가용성과 강력한 분석용 읽기 성능을 동시에 챙길 수 있는 최신 정석입니다. 다른 옵션인 B는 일반적인 대기 서버라 읽기가 불가능하며, C는 비용이 클러스터 방식보다 더 많이 나갈 수 있습니다.

정답은 A입니다. 3개 가용 영역(AZ)을 모두 활용하는 것이 가용성의 정석입니다. DB는 다중 AZ 클러스터(A)로 무장하고, 특히 웹 서버에서 중요한 '세션 정보'를 서버 안이 아닌 ElastiCache Redis(A)라는 공용 창고에 빼두어야 서버가 늘어나도(Auto Scaling) 사용자가 로그아웃되지 않고 안정적으로 서비스를 쓸 수 있습니다. 다른 옵션인 C는 DB 엔진 자체를 바꾸는 대공사라 현실성이 떨어지고, D는 한 리전이 죽으면 그대로 서비스가 멈추는 위험한 설계입니다.

정답은 A입니다. 국가별 차단(Geo-Blocking)은 CloudFront의 기본 내장 기능을 쓰는 게 가장 쉽고 정확합니다. 사용자의 IP를 보고 접속 국가를 판단하여, 허용되지 않은 국가에서 들어오면 자동으로 입구 컷을 해줍니다. 별도의 코딩이나 서버 로직 없이 클릭 몇 번으로 판권 문제를 깔끔하게 해결할 수 있습니다. 다른 옵션들은 특정인에 대한 권한 제어에는 좋지만, '국가 단위'의 광범위한 차단 용도로는 관리가 너무 힘듭니다.

정답은 B입니다. 30초라는 매우 짧은 RPO를 지키려면 데이터가 실시간으로 AWS로 넘어가고 있어야 합니다. DMS의 CDC 기능을 쓰면 온프레미스 DB의 변화를 즉시 가로채서 AWS에 복제해주며, 미리 RDS 서버를 작게나마 띄워두는 '웜 스탠바이' 방식을 결합하면 1시간 안에 서비스를 다시 살리는 RTO 목표도 충분히 달성할 수 있습니다. 다른 옵션인 A는 비용이 너무 많이 들고, D는 데이터 유실 시간이 하루치나 되어 30초 규정을 지킬 수 없습니다.

정답은 D입니다. 읽기 작업(보고서 등)을 분산하는 데 가장 최적화된 엔진은 Amazon Aurora입니다. Aurora는 읽기 전용 주소(Reader Endpoint)를 따로 제공하여, 주 서버에 무리를 주지 않고 최대 15개까지 복제본을 늘려 보고서 작업을 처리할 수 있습니다. 성능과 가용성 모두에서 오라클보다 클라우드에 최적화된 선택입니다. 다른 옵션인 B는 확장성이 낮고, C는 오라클 엔진 특성상 아로라만큼 유연하게 구성하기 힘듭니다.

정답은 A, C, E입니다. (원문 index 0, 2, 4) '들쭉날쭉한 트래픽 + 유휴 시간'에는 쓴 만큼만 돈을 내는 서버리스가 정답입니다. 백엔드는 서버 없이 돌아가는 조합(A)으로, 로그인은 관리 효율이 좋은 Cognito(C)로, 프런트엔드는 S3/Amplify와 CloudFront(E) 조합으로 구성하면 평소 손님이 없을 땐 0원에 가까운 비용으로 유지할 수 있습니다. 다른 옵션인 B는 손님이 없어도 서버 월세가 꼬박꼬박 나가므로 가성비 면에서 탈락입니다.

정답은 B입니다. 특정인에게만 '개별 파일'에 대한 접근권을 줄 때는 서명 URL(Signed URL)이 정석입니다. 주소 뒤에 일종의 암호 통행증을 붙여주는 방식인데, 평소엔 닫혀 있는 파일을 이 주소를 가진 사람만 잠시 열어볼 수 있게 해줍니다. 영화 대여나 개별 다운로드 서비스에 딱 맞는 기술입니다. 다른 옵션인 C는 S3 입구를 막아주는 기초 조치일 뿐, '개별 유료 회원'을 구별해주지는 못합니다.

정답은 A와 E입니다. (원문 index 0, 4) 할인 혜택을 나누려면 먼저 '가족'이 되어야 합니다. AWS Organizations를 통해 계정들을 하나의 '조직'으로 묶고(E), 마스터 계정에서 \\\\\\\"우리 가족끼리는 할인 혜택을 같이 써도 좋아!\\\\\\\"라고 할인 공유 버튼을 켜면(A) 끝납니다. 그러면 플랜을 산 계정뿐만 아니라 다른 팀 계정의 서버 요금도 자동으로 할인이 적용됩니다. 다른 옵션인 C(RAM)는 서브넷이나 DB 공유엔 쓰이지만, 지출 할인 혜택(Saving Plan) 공유용은 아닙니다.

정답은 A입니다. 광산의 유해 가스를 미리 감지했던 카나리아처럼, '카나리아 배포'는 위험을 최소화하는 전략입니다. 신규 버전을 살짝 띄워놓고 극소수의 트래픽만 보내서 반응을 살핀 뒤, 문제가 없음을 확인하고서야 비중을 늘려 프로덕션으로 승격(Promote)하는 것이 가장 안전한 정석 배포법입니다. 다른 옵션들처럼 한꺼번에 다 바꾸거나 설정을 덮어쓰는 행위는 버그가 터졌을 때 전면 장애로 이어질 수 있어 위험합니다.

정답은 B입니다. 이것이 바로 'Route 53 장애 조치(Failover)'의 교과서적인 활용 사례입니다. 메인 서버(Active)가 건강한지 계속 체크하다가, 서버가 아프기 시작하면 즉시 예비군인 S3(Passive)에게 공을 넘깁니다. S3는 관리할 서버도 없고 매우 저렴하므로, 비상 대기용 안내 페이지를 띄워놓기엔 최고의 장소입니다. 다른 옵션인 C는 쓸데없이 서버(EC2)를 하나 더 켜둬야 하므로 돈 낭비이며 관리 포인트만 늘어납니다.

정답은 D입니다. 백업 프로그램 입장에서는 \\\\\\\"어? 여전히 테이프 장비가 있네!\\\\\\\"라고 속게 만드는 '가상 테이프 라이브러리(VTL)' 기술이 핵심입니다. Storage Gateway의 테이프 게이트웨이 모드를 쓰면, 물리적인 테이프 대신 AWS 클라우드라는 무제한 가상 테이프를 쓰는 셈이 되어 기존 워크플로우를 하나도 안 바꾸고도 현대화를 달성할 수 있습니다. 다른 옵션인 A나 B는 일반 '파일' 저장소용이지, 테이프 장비를 흉내 내지는 못합니다.

정답은 A입니다. 실시간 스트리밍 데이터를 S3로 보내는 가장 편한 방법은 Kinesis Data Firehose입니다. 프로비저닝(서버 준비)이 전혀 필요 없고, 데이터가 몰리면 알아서 늘어납니다. 관리자는 그저 \\\\\\\"이 데이터를 저 S3 버킷에 넣어줘\\\\\\\"라고 선만 연결해주면 끝나는 아주 효자 서비스입니다. 다른 옵션인 B는 '실시간'이 아닌 일괄 처리에 가깝고, C는 데이터 양이 많아지면 람다 비용이 눈덩이처럼 불어날 수 있습니다.

정답은 B입니다. 여러 계정의 권한을 중앙에서 '철권 통치'할 수 있는 가드레일이 바로 서비스 제어 정책(SCP)입니다. Organizations를 통해 계정들을 정리하고 SCP를 하나 딱 붙여두면, 해당 계정의 관리자(Root)라 할지라도 우리가 금지한 비싼 서비스는 절대로 사용할 수 없게 됩니다. 운영 오버헤드가 가장 적은 강력한 정책 수단입니다. 다른 옵션인 D(Service Catalog)는 '메뉴판'을 만드는 좋은 방법이지만, 사용자가 직접 메뉴판 밖의 서비스를 쓰는 것까지 완벽하게 원천 차단하기엔 SCP가 더 강력하고 효율적입니다.

정답은 B입니다. 프라이빗 서브넷의 정석적인 인터넷 외출법은 NAT 게이트웨이를 이용하는 것입니다. 밖에서 안으로는 못 들어오지만, 안에서 밖으로(인터넷) 나가는 트래픽은 허용해주거든요. 관리자가 따로 서버를 관리할 필요가 없는 관리형 서비스라 운영 오버헤드도 낮고 보안상으로도 매우 안전합니다. 다른 옵션인 A(NAT 인스턴스)는 사람이 직접 패치하고 관리해야 해서 귀찮고, C는 프라이빗 서브넷의 정의 자체를 깨뜨리는 행동이라 보안 빵점입니다.

정답은 B와 D입니다. (원문 index 1, 3) 암호화된 상자를 열려면 두 가지가 맞아야 합니다. 첫째, 람다라는 일꾼(실행 역할)이 암호를 풀 수 있는 능력을 갖춰야 하고(B), 둘째, 상자(KMS 키)의 주인도 이 일꾼이 내 상자를 건드려도 된다고 승인해줘야 합니다(D). 이 양방향 허가가 있어야 비로소 람다가 환경 변수를 해독해 읽을 수 있습니다. 다른 옵션들은 람다 고유의 기능과는 관련이 없거나, KMS의 보안 방식에 어긋나는 방식들입니다.