AWS SAA C03 연습 문제 (401~425번)

정답은 A입니다. 장애에 강한 시스템을 만들려면 핵심 서비스들을 여러 데이터 센터(가용 영역, AZ)에 나눠서 배포해야 합니다. 웹 서버는 Auto Scaling 그룹으로 묶어 여러 AZ에 흩뿌리고, 데이터베이스(RDS)는 '다중 AZ' 설정을 켜서 한쪽이 죽더라도 다른 쪽으로 즉시 갈아탈 수 있게(Failover) 준비하는 것이 정답입니다. 이 조합이 고가용성과 확장성을 동시에 잡는 가장 표준적인 설계입니다. 다른 옵션인 B와 C는 특정 가용 영역에 장애가 발생했을 때 서비스가 멈출 위험(SPOF)이 여전히 존재하며, D는 공유 스토리지 설정이 매우 복잡하고 관리 부담이 커서 권장되지 않습니다.

정답은 A입니다. Kinesis Data Streams의 기본 데이터 보관 기간은 고작 24시간입니다. 그런데 데이터를 '격일(48시간 간격)'로 가져가려고 하니, 뒤늦게 가보면 이미 데이터가 유통기한이 지나 삭제된 상태인 거죠. 보존 기간을 최소 48시간 이상(최대 365일까지 가능)으로 늘려주기만 하면 데이터 유실 없이 모든 내용을 안전하게 챙겨올 수 있습니다. 다른 옵션인 C(샤드 증설)는 데이터가 너무 많이 들어와서 막힐 때 쓰는 방법이지 기간 만료로 인한 유실과는 상관없고, D(버전 관리)는 덮어쓰기 방지용이지 데이터 수집 단계의 유실을 막아주진 못합니다.

정답은 D입니다. AWS 서비스(Lambda 등)가 다른 서비스(S3 등)를 대신 조종하게 할 때는 아이디/비밀번호를 주는 게 아니라 '역할(Role)'을 맡기는 게 정석입니다. 'S3 쓰기 권한이 든 역할'을 만들어서 Lambda에게 입혀주면, Lambda는 별도의 키 관리 없이도 안전하게 신분을 증명하고 파일을 올릴 수 있습니다. 이것이 보안 사고를 막는 가장 안전한 신원 관리 방식입니다. 다른 옵션인 B와 C는 보안 키가 노출될 위험이 크고 관리가 매우 번거로워 절대 금지해야 할 안티 패턴입니다.

정답은 D입니다. 일감이 갑자기 폭주해서 처리 루틴이 마비되는 걸 막으려면 '완충지대(Buffer)'가 필요합니다. S3에서 바로 Lambda를 때리는 대신, 중간에 SQS라는 대기열(Queue)을 두어 일감을 일단 차곡차곡 쌓아두세요. 그러면 Lambda는 자기가 감당할 수 있는 속도로 하나씩 안전하게 처리할 수 있고, 일감이 넘쳐도 유실 없이 나중에라도 다 끝낼 수 있습니다. 이를 '결합도 낮추기(Decoupling)'라고 합니다. 다른 옵션인 A(시간 연장)는 처리가 늦어지는 건 막아도 폭주하는 양 자체를 해결해주진 못하며, C처럼 중복 배포하는 건 관리가 훨씬 복잡해지기만 합니다.

정답은 D와 E입니다. 두 가지 접근이 필요합니다. 먼저 주말처럼 아예 안 쓰는 시간이 확실하다면 '시계'를 맞춰두고 서버를 끄는 '예약된 조정(E)'이 비용 절감의 핵심입니다. 그리고 평일 업무 시간 중에도 트래픽이 그때그때 다를 테니, CPU 온도가 올라가면 서버를 더 늘려주는 '대상 추적 조정(D)'을 함께 쓰면 됩니다. 이 루틴을 합치면 아주 스마트하고 경제적인 인프라가 완성됩니다. 다른 옵션인 B(IGW 조절)는 관리자가 만질 수 있는 영역이 아니며, A 기능은 AWS가 뒤에서 알아서 해주는 일이지 우리가 직접 제어하는 설정이 아닙니다.

정답은 C와 D입니다. 제일 먼저 할 일은 대문을 여는 것입니다. 전 세계 고객이 접속해야 하니 웹 서버 보안 그룹은 누구나(0.0.0.0/0) 접속하게 443 포트를 엽니다(C). 그 다음이 핵심인데, DB는 웹 서버의 IP 주소를 적는 대신 웹 서버가 입고 있는 '옷(보안 그룹 ID)'을 보고 문을 열어줍니다(D). 이렇게 하면 나중에 웹 서버 대수가 늘어나거나 IP가 바뀌어도 보안 설정은 건드릴 필요 없이 항상 안전하게 유지됩니다. 다른 옵션인 B처럼 CIDR 대역을 통째로 여는 건 보안상 덜 정교하며, E인 보안 그룹은 기본적으로 '허용할 것만 적는' 방식이라 거부 규칙을 일일이 달 필요가 없습니다.

정답은 D입니다. 문제에 'Lustre'라는 키워드가 등장하면 짝꿍은 단번에 Amazon FSx for Lustre를 떠올려야 합니다. 이 서비스는 슈퍼컴퓨팅이나 고성능 데이터 처리(HPC)에 쓰이는 Lustre 파일 시스템을 클릭 몇 번으로 제공하는 완전 관리형 서비스입니다. 설치나 관리 고민 없이 즉시 고성능 공유 스토리지를 확보할 수 있습니다. 다른 옵션인 C인 EFS는 일반적인 리눅스용 NFS 방식이지 Lustre를 정식 지원하는 구조는 아닙니다.

정답은 B입니다. 키워드는 세 가지입니다. 'UDP 전송', '저지연', '빠른 리전 장애 조치'. 먼저 UDP를 완벽히 소화하는 로드 밸런서는 NLB입니다(ALB는 안 됩니다). 그리고 전 세계 사용자에게 가장 가까운 통로를 열어주고 리전 장애 시 수 초 안에 다른 리전으로 트래픽을 돌려주는 '네트워크의 지름길'이 바로 Global Accelerator입니다. 이 둘의 조합만이 게임의 승부를 가르는 지연 시간을 최소화할 수 있습니다. 다른 옵션인 D(Route 53)는 DNS 정보를 갱신하는 데 시간이 걸려 장애 조치 속도가 상대적으로 느리고, C(ALB)는 UDP를 지원하지 않아 탈락입니다.

정답은 C입니다. Windows 서버들이 함께 쓰는 파일 저장소가 필요하다면 고민할 것 없이 Amazon FSx for Windows File Server가 정답입니다. SMB 프로토콜, NTFS 권한 설정 등 기존 Windows NAS에서 쓰던 기능을 그대로 물려줄 수 있으며, 여러 가용 영역(AZ)에 걸쳐 복제되므로 내구성도 최강입니다. 윈도우 앱에게는 본가와 같은 편안함을 주는 스토리지입니다. 다른 옵션인 D(EFS)는 리눅스 전용이라 윈도우 환경과는 궁합이 맞지 않고, A(RDS)는 파일 저장용이 아닌 데이터 관리용입니다.

정답은 B입니다. 하드디스크(EBS)의 암호화는 볼륨 자체의 속성입니다. 볼륨을 생성할 때 암호화 체크박스를 클릭하기만 하면, 그 안에 저장되는 모든 데이터는 CPU가 알아서 암호화해서 담아줍니다. 사용자나 앱은 암호화가 되는지 신경 쓸 필요조차 없는 매우 편리하고 강력한 보안 방식입니다. 다른 옵션인 A(IAM)는 사람의 권한일 뿐 볼륨의 암호화 상태를 결정하지 못하며, C(태그)는 그냥 이름표일 뿐 실제 암호화 기능을 작동시키지는 않습니다.

정답은 C입니다. 사용자가 많을 땐 확 늘어나고, 새벽처럼 적을 땐 확 줄어들며(심지어 0으로), 요금도 쓴 만큼만 내는 '진정한 서버리스 DB'가 바로 Aurora Serverless입니다. MySQL과 똑같이 동작하므로 코드를 고칠 필요도 없습니다. 산발적인 사용 패턴을 가진 웹 앱에 이보다 더 경제적이고 편리한 선택지는 없습니다. 다른 옵션인 A(DynamoDB)는 SQL 쿼리를 NoSQL용으로 다 뜯어고쳐야 하는 대공사가 필요하며, B(RDS)는 늘려놓은 만큼 무조건 돈이 나가는 정액제 성격이 강합니다.

정답은 D입니다. 개별 버킷 설정을 하나하나 확인하는 건 숨바꼭질과 같습니다. 대신 AWS 계정 설정 페이지에서 '모든 S3 퍼블릭 액세스 차단' 스위치를 딱 켜면, 개별 버킷이 무슨 짓을 해도 인터넷에 노출되지 않습니다. 여기에 Organizations의 SCP(서비스 제어 정책)까지 더하면, 관리자라도 이 방화벽을 멋대로 끌 수 없게 완벽한 이중 잠금이 됩니다. 다른 옵션인 A와 B는 사고가 터진 후의 뒷수습이라 불안하지만, D는 사고 자체를 원천 봉쇄하는 가장 강력한 예방책입니다.

정답은 B입니다. 직접 메일 서버를 관리하는 건 스팸 처리나 발송 지연 등 지뢰밭을 걷는 것과 같습니다. Amazon SES(Simple Email Service)는 마케팅이나 확인 메일을 수백만 통씩 보낼 수 있게 설계된 전문 서비스입니다. 서버 자원을 소모하지 않고 API 호출 한 번으로 깔끔하게 메일을 보낼 수 있으며, 운영 오버헤드가 거의 제로에 가깝습니다. 다른 옵션인 A와 D는 메일 서버 운영이라는 엄청난 수고를 자처하는 일이며, C(SNS)는 공지사항 전파용이지 고도화된 이메일 마케팅이나 대용량 주문 확인용으로는 기능이 부족합니다.

정답은 B입니다. 가장 편한 방법은 기존 시스템이 '파일을 저장하는 위치'만 살짝 바꾸는 것입니다. S3 파일 게이트웨이를 설치하면 사내 서버에는 평범한 공유 폴더처럼 보이지만, 실제로는 파일이 쓰이는 즉시 S3 버킷으로 자동 복사됩니다. 스케줄링을 짤 필요도, 매일 전송 결과를 확인할 필요도 없는 '무심한' 자동화의 극치입니다. 다른 옵션인 A는 실시간성이 떨어지고, C와 D는 개발자가 매일 스크립트 장애를 관리해야 하는 운영 부담을 안겨줍니다.

정답은 A입니다. 수억 개의 파일 하나하나를 언제 마지막으로 봤는지 사람이 체크할 수는 없습니다. S3 Intelligent-Tiering은 인공지능 같은 똑똑한 눈으로 파일들을 지켜보다가, 한 달 동안 안 보는 파일은 저렴한 칸으로, 갑자기 보는 파일은 빠른 칸으로 알아서 옮겨줍니다. 성능 저하 없이 자동으로 돈을 아껴주는 '자율 주행' 저장소라고 보시면 됩니다. 다른 옵션인 C는 파일을 다시 꺼낼 때 수 시간이 걸려 서비스에 지장을 줄 수 있고, D는 데이터 센터가 하나뿐이라 소중한 PB급 데이터를 잃어버릴 위험이 커서 정답이 아닙니다.

정답은 B와 D입니다. 느린 웹 사이트를 수술하려면 양방향 처방이 필요합니다. 먼저 겉모양(이미지, HTML 등)은 사용자 근처의 복제 서버(CloudFront)에서 빛의 속도로 쏴줘야 합니다(B). 그리고 속을 썩이는 DB 조회는 메인 서버 혼자 고생하게 두지 말고, 조회 전용 복제본(Read Replica)을 여러 대 만들어서 일감을 나눠주면(D) 로딩 속도가 비약적으로 올라갑니다. 다른 옵션인 E는 고장 났을 때를 대비하는 '안전 장치'이지 평소 속도를 빠르게 해주는 '부스터'는 아닙니다. A인 Redshift는 쇼핑몰보다는 통계 보고서용 도구입니다.

정답은 C입니다. 먼저 돈부터 아껴봅시다. 1년 이상 EC2와 Lambda를 둘 다 쓸 거라면, 둘 모두에게 할인을 적용해주는 '컴퓨팅 세이빙 플랜'이 가장 알뜰합니다. 그 다음 속도가 중요한데, Lambda를 EC2가 있는 내부 망(프라이빗 서브넷)에 직접 연결해주면 인터넷을 거치지 않고 우리끼리 전용선으로 대화하는 꼴이 되어 지연 시간이 확 줄어들고 보안도 완벽해집니다. 다른 옵션인 A와 B(EC2 전용 플랜)는 Lambda에 할인이 안 되고, D는 네트워크를 빙 돌아가야 하므로 속도와 보안 면에서 손해입니다.

정답은 B입니다. 계정이 다른 두 서비스가 대화할 때는 '교차 계정 역할(Cross-account Role)'이 정답입니다. 운영 계정이 "어이, 개발 계정에서 온 애들 중에 이 '역할'을 맡겠다는 애들은 믿고 파일 보여줄게"라고 설정(신뢰 정책)하는 것이죠. 이렇게 하면 개별 아이디를 수만 개 만들 필요도 없고, 필요한 순간에만 잠시 권한을 빌려 쓰는 형태라 가장 보안이 튼튼합니다. 다른 옵션인 D는 관리할 아이디만 두 배로 늘어나 지옥을 맛보게 되며, A나 C는 보안 사고로 가는 지름길입니다.

정답은 A와 C입니다. 보안은 '기본 설정'과 '강력한 금지'가 만나야 완성됩니다. 먼저 EC2 설정에서 '새로 만드는 건 다 암호화해'라는 자동 스위치(A)를 켜두면 대부분의 실수를 막을 수 있습니다. 하지만 영리한(?) 누군가가 이를 우회할 수 있으니, Organizations 마스터키인 SCP(C)를 이용해 "암호화 안 된 건 아예 세상에 태어날 수 없어!"라고 시스템 레벨에서 거부 규칙을 박아버리면 완벽합니다. 다른 옵션인 B는 개별 관리가 너무 힘들고, E는 보안과는 상관없는 농담 같은 소리입니다.

정답은 D입니다. 기존 다중 AZ는 장애 조치에 1~2분이 걸렸지만, 최신 'RDS 다중 AZ DB 클러스터' 방식은 35~40초 이내로 훨씬 빠르게 복구됩니다. 게다가 이 방식은 '대기 서버'가 노는 게 아니라 읽기 쿼리를 대신 처리해주는 일꾼으로도 뛰기 때문에 비용 효율이 아주 좋습니다. '리더 엔드포인트'라는 단일 주소만 쓰면 여러 대의 읽기 서버가 알아서 일감을 나눠 갖는 우아한 구조입니다. 다른 옵션인 A는 비용이 더 많이 들고 복구 속도가 느리며, C인 대기 인스턴스는 평소에 일을 시킬 수 없어 비효율적입니다.

정답은 B입니다. 서버리스이면서 높은 입출력 성능(IOPS)을 내려면 파일 저장소로 EFS가 제격입니다. 여기에 SFTP 문지기인 AWS Transfer Family를 'VPC 엔드포인트' 방식으로 띄우면, 우리가 평소 쓰던 '보안 그룹'을 그대로 붙여서 특정 IP만 허용하는 세밀한 방어막을 칠 수 있습니다. 성능과 보안, 관리 편의성을 한 번에 잡는 정석 아키텍처입니다. 다른 옵션인 A(EBS)는 서버리스인 Transfer Family와 직접 연결하기 까다롭고, C는 특정 IP 차단이 힘들며, D는 외부 소스의 접근을 아예 막아버려 외부 서비스용으로는 부적합합니다.

정답은 D입니다. 모델이 무거워서 람다(Lambda)로 켰다 껐다 하면 초기 예열(로딩) 시간 때문에 사용자가 지칩니다. 이럴 땐 컨테이너(ECS)가 미리 준비하고 있다가 일감을 처리하는 게 나은데, 서버를 24시간 켜둘 순 없으니 SQS 대기열을 지켜보다가 "일감이 많아지면 컨테이너 수를 늘리고, 없으면 0으로 줄여!"라고 자동 확장(Auto Scaling)을 거는 방식이 최고입니다. 가성비와 성능을 모두 챙긴 똑똑한 설계입니다. 다른 옵션인 A(람다)는 콜드 스타트 문제로 고생할 확률이 높고, B와 C는 구현 난이도가 말도 안 되게 높거나 비효율적입니다.

정답은 A와 B입니다. IAM 정책은 '누구(Principal)'에게 권한을 줄지 결정하는 문서입니다. 따라서 실제 사람(User), 사람들이 모인 팀(Group), 혹은 잠시 신분을 빌려 쓰는 대상(Role)에 직접 붙일 수 있습니다. '누구'에게 붙여야 그 주체가 비로소 일을 할 수 있게 됩니다. 다른 옵션인 D와 E인 '리소스'는 권한의 '대상'이지 권한을 '소유'하는 주체가 아닙니다. 리소스에 붙이는 건 '리소스 기반 정책'이라 부르며 일반적인 자격 증명 정책과는 문법과 붙이는 위치가 다릅니다.

정답은 B입니다. 안정성과 가격의 줄타기가 핵심입니다. 24시간 죽지 않고 버텨야 하는 프런트엔드는 1~3년 사용을 약속하고 대폭 할인받는 '예약 인스턴스(RI)'가 국룰입니다. 반면, 백엔드는 업무 일감이 있을 때만 잠깐 돌면 되고 작업이 도중에 끊겨도 다시 돌리면 그만이기에, AWS가 남는 서버를 헐값에 파는 '스팟 인스턴스(Spot)'를 쓰는 것이 가장 현명한 비용 절약법입니다. 다른 옵션인 C와 D는 고객이 직접 접속하는 프런트엔드에 '스팟'을 썼다가 서버가 갑자기 회수되면 사이트가 마비되므로 절대 해서는 안 될 위험한 선택입니다.

정답은 C입니다. gp3는 혁신적인 가성비 볼륨입니다. 예전 gp2는 100GB를 사야 300 IOPS가 나오는 식으로 '용량'에 성능이 묶여 있었지만, gp3는 용량은 10GB만 사더라도 속도는 3,000 IOPS(기본)부터 16,000 IOPS까지 돈을 내고 마음대로 높일 수 있습니다. 15,000 IOPS 정도의 부하라면 비싼 io2까지 갈 필요 없이 gp3가 가장 저렴하고 똑똑한 선택입니다. 다른 옵션인 B(io2)는 성능은 최고지만 가격이 수 배 더 비싸며, A(gp2)는 원하는 성능을 얻기 위해 불필요하게 큰 용량을 사야 하므로 비효율적입니다.