AWS SAA C03 연습 문제 (326~350번)

정답은 A와 B입니다. 데이터의 접속 패턴이 불규칙하거나 예측하기 힘들 때는 S3 Intelligent-Tiering(A)이 가장 현명한 선택입니다. 사용량에 따라 자동으로 요금을 깎아주기 때문이죠. 또한, 큰 파일을 올리다 중간에 멈춘 '멀티파트 업로드(B)' 찌꺼기 파일들이 용량만 차지하지 않도록 수명 주기 정책으로 자동 청소해주면 새나가는 돈을 완벽히 막을 수 있습니다. 다른 옵션인 D와 E는 패턴이 불규칙할 때 대응력이 떨어지며, C는 삭제 마커 관리라 직접적인 용량 확보와요금 절감 효과는 B보다 적습니다.

정답은 A입니다. 나가는 길목(Egress)을 지키며 특정 URL만 허용하는 '화이트리스트' 방식에는 AWS Network Firewall이 제격입니다. 이 서비스의 '도메인 리스트 규칙 그룹'을 쓰면, 업데이트 서버 주소는 통과시키고 나머지 수상한 접속은 싹 차단할 수 있습니다. 보안 그룹은 도메인 이름(URL)을 인식하지 못하기 때문에 이 업무를 수행할 수 없습니다. 다른 옵션인 B(WAF)는 밖에서 안으로 들어오는 공격을 막는 용도이며, D(ALB)는 서버로 들어오는 손님을 안내하는 역할이라 밖으로 나가는 트래픽을 세밀하게 통제하기엔 적절하지 않습니다.

정답은 D입니다. 손님이 한꺼번에 몰릴 때 입구에서 바로 계산하려 하면 줄이 엉망이 되고 시스템이 터지기 마련입니다. 이럴 때는 SQS라는 가상의 대기표 발행기를 앞에 두는 게 상책입니다. 일단 모든 주문을 번호표 뽑듯 대기열에 다 받아두고, 서버들이 자기 체력에 맞춰 하나씩 가져가서 처리하면 아무리 손님이 많아도 시스템이 죽지 않고 모든 주문을 성공적으로 완수할 수 있습니다. 다른 옵션인 A, B, C는 서버 부하를 줄이거나 대수를 늘려주지만, 순각적인 폭증(Spike) 상황에서 서버가 깨어나는 속도보다 주문량이 더 많으면 주문 누락이 발생할 위험이 큽니다.

정답은 D입니다. 서버의 '정밀 진단'은 Amazon Inspector가, '자동 수술 및 처방'은 Patch Manager가 담당하는 환상의 콤비입니다. Inspector가 매일 서버를 훑어서 약점이 어딘지 찾아내면, Patch Manager가 미리 정해둔 시간에 맞춰 자동으로 업데이트를 설치하고 '오늘 몇 대 성공했습니다'라고 깔끔한 보고서까지 써주니 관리자는 걱정할 게 없습니다. 다른 옵션인 A(Macie)는 개인 정보 탐색용이며, B와 C는 침입 탐지나 분석 도구이지 실제 서버 패치를 대규모로 자동화해주는 전문 기능은 아닙니다.

정답은 A입니다. 하드디스크에 저장된 데이터 원본 자체를 잠그는 것이 '미사용 데이터 암호화'입니다. AWS의 열쇠 관리 서비스인 KMS에서 튼튼한 열쇠를 하나 만들고, RDS를 처음 생성할 때 '이 열쇠로 잠궈줘'라고 설정만 하면 저장되는 모든 데이터가 자동으로 암호문으로 변하여 안전하게 보호됩니다. 다른 옵션인 B는 비번 관리용이고, C와 D는 통신 구간 보안(In-transit)이지 저장 데이터 자체를 잠그는 방법은 아닙니다.

정답은 A입니다. 20TB를 15Mbps의 느린 인터넷으로 보내려면 끊기지 않고 풀로 가동해도 수개월이 걸릴 수 있는 무모한 도전입니다. 이럴 때는 트럭이나 택배로 장비를 보내는 게 훨씬 빠릅니다. Snowball이라는 거대한 저장 장치를 사무실로 배송받아 데이터를 담아 돌려보내면, 며칠 안에 20TB를 안전하게 클라우드로 이사할 수 있습니다. 다른 옵션인 B, C, D는 모두 인터넷 회선을 타기 때문에 15Mbps라는 좁은 길목에서는 30일 안에 완료하는 것이 불가능합니다.

정답은 B입니다. 윈도우 기반 사내 파일 서버를 가장 이질감 없이 옮기는 방법은 FSx for Windows입니다. 기존에 쓰던 사내 계정(Active Directory) 시스템을 그대로 연동할 수 있고, VPN이라는 암호화된 전용 통로까지 더하면 집에서 일하는 직원도 마치 사무실 옆 자리 하드디스크를 쓰듯 기밀 파일을 안전하고 편리하게 사용할 수 있습니다. 다른 옵션인 A나 D는 보안 위가 너무 높으며, C는 매번 주소를 받는 과정이 일반적인 파일 공유 시스템 활용법보다 번거롭습니다.

정답은 C입니다. 언제 부하가 몰릴지 이미 정확한 '일정'을 알고 있다면, 일이 터지기 전에 미리 대비하는 게 최고입니다. '매달 1일 23시 30분에 서버를 10대로 늘려줘'라고 예약(Scheduled Scaling)을 걸어두면, 시스템은 정산 작업이 시작되기도 전에 체력을 보강해두어 아무리 힘든 작업이 와도 끄떡없이 버텨낼 수 있습니다. 다른 옵션인 B는 부하가 터진 뒤에야 반응하므로 초기 렉(Lag)을 막기 힘들고, A와 D는 연산 중심의 정산 작업 부하를 근본적으로 해결해주지는 못합니다.

정답은 A입니다. 고객은 평소 쓰던 SFTP 프로그램 그대로 접속하고 싶어 하고, 관리자는 복잡한 서버 관리를 피하고 싶다면 Transfer Family가 정답입니다. S3를 마치 파일 서버처럼 보이게 해주면서도, 뒷단에서 사내 계정 시스템과 연결해 '철수님은 들어와도 돼요'라는 인증까지 완벽히 처리해주니 운영 부담이 거의 없습니다. 다른 옵션인 D는 서버 관리 독박을 써야 하며, B와 C는 데이터 전송 방식 자체가 SFTP 클라이언트 활용법과는 거리가 멉니다.

정답은 B입니다. 서버 수백 대가 한꺼번에 켜질 때 병목이 생기는 이유는 서버의 영혼과 같은 '스냅샷'에서 데이터를 읽어오는 속도 때문입니다. '빠른 스냅샷 복원(FSR)' 기능을 켜두면, AWS가 미리 데이터를 따뜻하게 데워두어(Pre-warming) 서버가 요청하는 즉시 최고 속도로 부딩을 완료할 수 있게 도와줍니다. 다른 옵션인 A는 효과가 미비하며, C와 D는 서버의 생성 속도 자체를 개선하는 직접적인 해결책은 아닙니다.

정답은 A입니다. 비밀번호 같은 민감한 정보의 관리와 자동 교체는 Secrets Manager가 전문입니다. '14일마다 비번을 바꿔줘'라고 설정만 해두면 자기가 알아서 DB에 접속해 비번을 바꾸고, 앱들에게도 새 비번을 알려줍니다. 관리자가 매번 비번을 바꾸느라 고생하거나 까먹을 일이 전혀 없는 아주 똑똑한 보안 도구입니다. 다른 옵션인 B는 '수동'이 섞여 있어 탈락이며, C나 D는 비밀번호를 사실상 평문으로 방치하는 격이라 보안 규정에 맞지 않습니다.

정답은 A입니다. 일반 MySQL의 복제 방식은 메인 DB가 바쁘면 복제본이 뒤처질 수밖에 없는 구조적 한계가 있습니다. 하지만 Aurora는 공유 저장소를 쓰기 때문에 메인 DB에 자료가 쓰이는 즉시 복제본에서도 거의 동시에 볼 수 있습니다. 코드 몇 줄 고치는 것보다 데이터베이스 엔진 자체를 클라우드에 최적화된 Aurora로 바꾸는 게 가장 빠르고 확실한 해결책입니다. 다른 옵션인 B는 캐싱 코드를 다 짜야 해서 '최소한의 수정'에 어긋나며, C와 D는 인프라 체계를 완전히 뒤흔드는 너무 큰 작업입니다.

정답은 D입니다. 여러 지역에 데이터를 서비스하고 재난에 대비하는 가장 강력한 기능은 'Aurora Global Database'입니다. 메인 지역에서 일어나는 모든 변화를 광속으로 해외 지역까지 보내주며, 평소에는 해당 지역 사용자를 위한 읽기 전용 서버로 쓰다가 큰 사고가 나면 그 지역을 메인으로 승격시켜 즉시 서비스를 재개할 수 있게 도와줍니다. 다른 옵션인 A나 C는 속도나 관리 면에서 Aurora 기본 기능인 D를 따라오지 못하며, B는 평소에 노는 서버 비용이 부담입니다.

정답은 C입니다. 코드 안에 비번을 적어두는 건 현관문 비밀번호를 대문에 적어둔 것과 같습니다. Secrets Manager라는 금고에 비번을 보관하고, 프로그램(앱)이 실행될 때만 금고에서 비번을 받아오게 바꾸면 코드가 유출되어도 안심입니다. 여기에 주기적으로 비번을 바꿔주는 자동 교체 설정까지 더하면 완벽한 보안 시스템이 완성됩니다. 다른 옵션인 A는 여전히 코드에 암호화된 값이 흔적으로 남고, B는 자동 교체 기능까지 활용하는 C보다는 보안 등급이 낮습니다. D는 사람이 직접 하는 방식이라 실수의 위험이 큽니다.

정답은 A입니다. 웹 서비스의 비정상적인 요청(SQL 공격 등)을 골라내는 필터는 WAF(웹 방화벽)입니다. 로드 밸런서 앞에 WAF라는 촘촘한 그물망을 쳐두면, 해커가 교묘하게 보낸 공격 신호를 미리 알아채고 서버에 닿기도 전에 컷트해주므로 홈페이지와 데이터를 안전하게 지킬 수 있습니다. 다른 옵션인 C는 디도스(대량 트래픽) 방어 전용이며, D인 Inspector는 서버 내부 설정 진단용이라 실시간 들어오는 독침(SQL 공격)을 막아내기엔 부적절합니다.

정답은 D입니다. 수많은 데이터의 접근 권한을 '이 사람은 주민번호는 보지 마', '이 사람은 이름만 봐' 식으로 세밀하게 관리하는 사령탑이 바로 Lake Formation입니다. 여기서 권한을 한 번만 정해두면, 분석 도구인 QuickSight가 데이터를 가져올 때 규정대로 마스킹 처리된 안전한 데이터만 보여주므로 보안 사고를 예방할 수 있습니다. 다른 옵션인 A나 B는 관리 포인트가 너무 많고 복잡하며, C만으로는 데이터 레이크 전체에 대한 체계적인 보안 관리를 달성하기 어렵습니다.

정답은 C입니다. '예측 조정(Predictive Scaling)'은 시스템이 스스로 공부하는 방식입니다. 지난 몇 주간의 데이터를 보고 '아, 매주 이 시간에는 일이 몰리는구나'라고 파악해서, 사람이 시키지 않아도 30분 전에 미리 충분한 서버 대수를 준비해 둡니다. 관리자의 손길 없이도 성능 저하를 완벽히 막아내는 가장 세련된 자동화입니다. 다른 옵션인 B(예약)도 가능은 하지만, 매주 상황이 조금씩 변할 때 능동적으로 대처하는 C가 훨씬 고수 수준의 해결책입니다. A는 일이 터진 뒤에야 서버를 늘리기 때문에 30분 전 충원 조건을 맞추지 못합니다.

정답은 C입니다. 운영 오버헤드를 줄이는 게 핵심이라면 Aurora Global Database가 압권입니다. 내가 일일이 설정을 고치거나 지켜보지 않아도, AWS가 전용 통로를 통해 다른 리전까지 데이터를 거의 즉시 복제해 줍니다. 나중에 주 지역이 마비되어도 클릭 한 번이면 해외 리전 서버가 즉시 대장(Primary) 역할을 이어받으니 재해 복구용으로 최상입니다. 다른 옵션인 B도 훌륭하지만, 재난 시 복구 속도와 복제 성능 면에서 Aurora 전용 기능인 C가 훨씬 강력합니다. A는 사람이 직접 할 일이 너무 많습니다.

정답은 A입니다. SQS는 가벼운 메시지 전용이라 큰 파일은 직접 못 담습니다. 하지만 'SQS Extended Client Library'라는 가방을 쓰면 해결됩니다. 이 가방은 큰 데이터가 들어오면 '알아서' S3라는 넓은 창고에 짐을 맡기고, SQS에게는 'S3 어디에 짐을 뒀다'는 작은 쪽지만 전달합니다. 받는 쪽도 가방을 열면 알아서 S3에서 짐을 꺼내 오니 코드 수정도 아주 적고 편리합니다. 다른 옵션인 C는 기술적으로 불가능하며, B는 시스템 설계 자체를 다 바꿔야 해서 일이 너무 커집니다.

정답은 A입니다. 속도가 생명이라면 데이터 센터까지 갈 필요도 없이 사용자 근처의 '에지(Edge)'에서 일을 끝내면 됩니다. Cognito라는 신분증 확인소를 쓰고, 전 세계 배달점(CloudFront)에서 바로 실행되는 Lambda@Edge가 '이 사람 로그인됐네!'라고 확인해 주면, 지구 반반편 사용자도 내 집 앞 서버처럼 빠른 속도로 서비스를 이용할 수 있습니다. 다른 옵션인 B와 D는 물리 서버가 개입되어 '서버리스'가 아니며, C는 로그인 처리 속도 자체를 획기적으로 줄여주지는 못합니다.

정답은 D입니다. 직원들의 습관은 바꾸지 않으면서 저장소만 클라우드로 바꾸는 마법사가 S3 파일 게이트웨이입니다. 사무실 장비에 이 게이트웨이를 설치하면, 직원들 컴퓨터에는 똑같은 공유 폴더로 보이지만 실제론 모든 파일이 S3라는 거대 창고에 안전하게 쌓입니다. 낡은 장비를 살 필요도 없고 관리도 말도 안 되게 편해집니다. 다른 옵션인 A나 B는 용도가 전혀 다르며, C는 고성능 전용 파일 시스템용이라 일반적인 사무용 NAS 대체용으로는 S3 기반인 D가 가장 경제적입니다.

정답은 A입니다. 가장 유연한 할인 패키지는 'Compute Savings Plan'입니다. 특정 서버 사양에 묶이지 않고 '3년 동안 이만큼의 서버 파워를 쓸게요'라고 약속만 하면, 나중에 서버 종류를 바꾸든 다른 나라(리전)로 이사를 가든 무조건 할인을 해줍니다. 비즈니스가 어떻게 변할지 모르는 상황에서는 이 방식이 가장 안전하고 효과적인 비용 절약법입니다. 다른 옵션인 B, C, D는 특정 지역이나 서버 제품군에 고정되어야 하는 경우가 많아 유연성 면에서 A보다 한참 떨어집니다.

정답은 B입니다. 사용량이 일정하다면 '정액제(Provisioned Mode)'가 답입니다. '나는 초당 100건 정도만 처리하면 돼'라고 미리 범위를 딱 정해두면, 쓴 만큼 내는 종량제(On-demand)보다 훨씬 저렴한 고정 가격에 서비스를 누릴 수 있습니다. 가계부 쓰듯 딱 정해진 예산 안에서 시스템을 알뜰하게 운영하기에 최적의 선택입니다. 다른 옵션인 C나 D(온디맨드)는 사용량이 튈 때 대비는 좋지만, 일정하게 계속 쓸 때는 정액제 방식인 B보다 훨씬 많은 비용이 청구됩니다.

정답은 B입니다. 암호화된 기밀 자료를 공유할 때는 자료 자체뿐만 아니라 '열쇠'도 같이 빌려줘야 합니다. 내가 쓰는 암호 키(KMS) 관리 화면에 들어가서 상대방의 AWS 계정 번호를 '신뢰할 수 있는 사용자'로 추가해 주면, 상대방도 자기네 동네에서 내 스냅샷을 열어볼 수 있는 합법적인 권한을 갖게 되어 안전하게 인수인계를 마칠 수 있습니다. 다른 옵션인 A나 C는 보안 체계를 파괴하거나 규정에 어긋나는 방식이며, D는 공유 과정이 너무 복잡하고 비효율적입니다.

정답은 A와 C입니다. 시스템이 멈추지 않으려면 두 개 이상의 구역(AZ)에 장비를 배치하는 게 필수(A)입니다. 또한, 무거운 보고서 작업이 메인 DB의 기력을 뺏지 않도록 옆 동네에 '읽기 전용 복제본(C)'이라는 보조 비서를 하나 두세요. 이제 보고서 직원은 보조 비서만 괴롭히고, 메인 DB는 고객들의 결제를 처리하는 데만 집중할 수 있어 성능과 안정성을 모두 잡을 수 있습니다. 다른 옵션인 B는 그때그때 수동이라 번거롭고, D나 E는 보고서로 인한 전체 부하 지연 문제를 근본적으로 해결해주지는 못합니다.