AWS SAA C03 연습 문제 (276~300번)

정답은 A와 D입니다. 예측 불가능한 성장에 대처하려면 두 가지 자동화가 필요합니다. 첫째, DB 용량 부족은 RDS의 '스토리지 오토 스케일링(A)' 기능이 해결해줍니다. 미리 정해둔 상한선까지 용량을 알아서 키워주죠. 둘째, 서버의 과부하는 CPU 사용률을 지표로 삼은 '오토 스케일링 정책(D)'이 해결합니다. 사람이 일일이 감시하지 않아도 부하에 맞춰 서버 대수를 넣고 빼주니 가장 효율적입니다. 다른 옵션인 B는 오라클 전용 기능을 쓰는 상황에서 DB 엔진을 바꾸는 대공사가 필요해 부적절하며, C는 알람만 줄 뿐 자동으로 해결해주지는 못합니다. E의 메모리 수치는 외부 지표라 추가 설정이 번거로운 편입니다.

정답은 D입니다. 비용 절감의 황금률은 '비싼 저장소(EFS)에는 머무는 시간을 최소화'하는 것입니다. 무제한으로 쌓아둬도 값싼 S3를 메인 창고로 쓰세요. 그러다 작업이 필요할 때만 개별 서버의 전용 하드(EBS)로 파일을 슥 당겨와서 분석하고, 결과물만 다시 S3에 던지면 됩니다. 이렇게 하면 비싼 EFS 월세를 낼 필요가 없어 비용을 수십 배 아낄 수 있습니다. 다른 옵션인 A와 B는 주로 온프레미스 연동용이라 이 상황에는 어울리지 않고, C는 EBS도 24시간 켜두면 비용이 계속 나가기 때문에 S3를 활용하는 D보다 비쌉니다.

정답은 B와 E입니다. 계층 구조의 빠른 조회에는 NoSQL인 DynamoDB(B)가 찰떡궁합입니다. 밀리초 단위의 빠른 응답을 보장하죠. 그리고 '민감한 개인 정보(PII)'를 전문적으로 찾아내는 탐정 서비스가 바로 Amazon Macie(E)입니다. Macie를 켜두면 데이터 속에서 재무 정보를 스스로 찾아내고, SNS 소식통을 통해 관리자에게 이메일로 즉시 일러바칩니다. 다른 옵션인 A와 D는 주로 통계 분석용이라 계층형 데이터의 실시간 조회에는 어울리지 않으며, C는 알림보다는 코드 실행에 더 집중된 방식입니다.

정답은 A입니다. 복잡한 백업 주기는 'AWS Backup'이라는 전담 관리자에게 맡기는 게 가장 세련된 방법입니다. 여기서 '백업 계획(Plan)' 하나만 만들면 끝납니다. "매달 1일에 백업하고, 6개월 지나면 싼 콜드 창고로 옮겨서 7년 동안만 보관해"라고 적어두기만 하면, AWS가 알아서 모든 일정을 체크하고 집행합니다. 다른 옵션인 B, C, D는 일일이 코드를 짜거나 설정을 수동으로 해야 해서 실수할 위험이 크고 운영 부담도 상당합니다. 서비스 하나로 끝내는 A가 정석입니다.

정답은 B입니다. S3에 쌓인 대용량 파일을 데이터베이스처럼 SQL로 자유자재로 뒤져보는 마법 같은 도구가 바로 Athena입니다. 서버 한 대 안 띄우고도 조회가 가능하죠. 이렇게 조회한 결과를 예쁜 차트나 대시보드로 그려주는 시각화 전문가는 QuickSight입니다. 이 둘을 묶으면 로그 분석부터 경영진 보고용 대시보드까지 완벽한 파이프라인이 완성됩니다. 다른 옵션인 A의 Glue는 시각화 도구가 아니라 데이터 가공 도구이고, C와 D의 DynamoDB는 정기적인 대량 로그 분석용으로 쓰기엔 비용과 효율 면에서 적절하지 않습니다.

정답은 A입니다. 1초 미만의 복구 지점(RPO)이라는 말은 '메인 DB가 죽어도 데이터가 옆 동네에 실시간으로 완벽하게 복제되어 있어야 함'을 뜻합니다. RDS의 다중 AZ 기능은 '동기(Synchronous) 복제' 방식을 씁니다. 즉, 메인에 데이터가 써질 때 옆 동네(대기 서버)에도 똑같이 써졌는지 확인될 때까지 기다립니다. 따라서 메인이 터져도 데이터 유실이 사실상 제로(0)에 가깝습니다. 다른 옵션인 C와 D는 '비동기' 방식이라 찰나의 순간에 데이터가 덜 넘어갔을 위험이 있고, B는 서버 복구에만 집중할 뿐 데이터 복제와는 상관이 없습니다.

정답은 B입니다. 보안 그룹의 가장 세련된 활용법은 'ID 참조'입니다. 서버 보안 그룹 설정에 "다른 거 다 필요 없고, 이 ALB 보안 그룹 표찰을 단 녀석들만 들어와!"라고 적어두는 거죠. 이렇게 하면 ALB를 정식으로 거친 요청만 서버에 닿을 수 있고, 같은 서브넷 내의 다른 서버가 옆길로 새서 접근하려 해도 철벽같이 차단됩니다. 다른 옵션인 A와 C는 서버를 위험한 곳에 노출시키는 행위이며, D는 대문만 열었을 뿐 정작 중요한 서버의 내실 보안은 포기하는 꼴입니다.

정답은 D입니다. 리눅스(NFS)와 윈도우(SMB)라는 서로 다른 언어를 쓰는 두 세상 사이에서 통역사 역할을 완벽하게 수행하는 저장소가 바로 'FSx for NetApp ONTAP'입니다. 이 저장소는 멀티 프로토콜을 지원해서 한쪽에서 NFS로 넣은 파일을 다른 쪽에서 SMB로 바로 꺼내 볼 수 있게 해줍니다. 코드를 한 줄도 안 고치고도 두 앱이 절친처럼 데이터를 공유하게 되죠. 다른 옵션인 A와 C는 앱의 구조를 완전히 뜯어고쳐야 하는 대공사가 필요하고, B는 구성이 너무 복잡해지고 운영 부담이 커집니다.

정답은 B입니다. 요금 분석의 기본은 'Cost Explorer'입니다. 여기서 태그(Tag) 필터를 '사용자 아이디'로 걸면 누가 어디에 돈을 썼는지 그래프와 표로 한눈에 보여줍니다. 이걸 CSV 파일로 내려받으면 훌륭한 예산 보고서가 되죠. 인프라를 건드리지 않고 가장 손쉽게 원하는 답을 얻을 수 있는 정석 답변입니다. 다른 옵션인 A는 훨씬 더 정교한 분석이 가능하지만 설정이 복잡하고, C는 사용자별 상세 지출 내역까지는 친절히 보여주지 않습니다. D는 알람만 줄 뿐 과거 내역을 분석해주지는 못합니다.

정답은 B입니다. 방문자가 거의 없는 사이트에는 '서버리스'가 진리입니다. API Gateway가 문의 요청을 받으면, 람다가 순식간에 깨어나서 내용을 정리하고 SES를 통해 메일을 보낸 뒤 다시 잠듭니다. 서버 월세 없이 딱 실행된 만큼(몇 원 단위)만 돈을 내면 되니 이보다 경제적인 선택은 없습니다. 다른 옵션인 A, C, D는 방문자가 단 한 명도 없어도 매달 서버 대여료가 꼬박꼬박 나가기 때문에 비용 효율 면에서 탈락입니다.

정답은 C입니다. CloudFront는 전 세계 에지 서버에 원본 파일을 복사해두고(캐싱) 오랫동안 유지합니다. S3 파일이 바뀌어도 에지 서버는 "난 아직 옛날 파일 가지고 있는데?"라며 예전 버전을 계속 보여주는 게 문제입니다. 배포가 끝난 뒤 "이제 옛날 건 버려!"라고 명령하는 것이 바로 '무효화'입니다. 이걸 수행하면 에지 서버들이 즉시 최신 파일을 S3에서 다시 가져오게 됩니다. 다른 옵션인 A, B, D는 캐시 갱신과는 전혀 상관없는 엉뚱한 처방입니다.

정답은 B입니다. 기존 윈도우 환경의 특징을 손상하지 않고 그대로 옮기는 '리프트 앤 시프트'의 정석입니다. 특히 윈도우 파일 공유(SMB)가 핵심이므로, 여기에 최적화된 FSx for Windows를 써야만 권한 설정이나 파일 잠금 문제가 생기지 않습니다. SQL Server도 직접 EC2에 설치하면 온프레미스에서 쓰던 복잡한 옵션들을 그대로 유지할 수 있어 마이그레이션 난이도가 낮아집니다. 다른 옵션인 C의 EFS는 리눅스 전용이라 윈도우와는 궁합이 안 맞고, D의 EBS는 여러 대가 동시에 쓰기엔 파일 시스템 충전 위험이 큽니다.

정답은 C입니다. 리눅스 서버 여러 대가 공통 분모로 쓸 수 있는 최고의 공유 하드는 EFS입니다. 표준 NFS 방식으로 연결되므로, 서버 입장에서는 내 하드디스크랑 똑같은 경로(/data 등)로 파일을 읽고 쓸 수 있습니다. 앱 코드를 한 줄도 고칠 필요가 없죠. 용량도 쓰는 만큼 알아서 늘어나니 정말 편리합니다. 다른 옵션인 A와 B는 API 전용 스토리지라 코드를 고쳐야 하고, D의 EBS는 한 번에 한 서버에만 꽂히는 게 원칙이라(Multi-attach 제외) 다수 서버 공유용으로는 적절하지 않습니다.

정답은 B입니다. 클라우드 보안의 핵심은 '역할(Role)'입니다. 람다라는 직원에게 "너는 이 S3 창고에서 물건을 꺼내 올 권리가 있어"라고 적힌 사원증(IAM 역할)을 목에 걸어주는 방식입니다. 특히 사원증 뒷면에는 딱 필요한 S3 버킷만 적시(최소 권한)해야 사고를 막을 수 있습니다. 다른 옵션인 A는 대문을 너무 활짝 여는 꼴이고, C는 배신자 키가 유출될 위험이 큽니다. D는 할 일이 아닌 곳까지 기웃거리게 만드는 보안의 적입니다.

정답은 C입니다. 오토 스케일링 그룹의 비용 최적화 비결은 '혼합 운용'입니다. 서비스가 절대 끊기면 안 되는 기본 물량은 온디맨드로 안정적으로 가져가고, 갑자기 늘어나는 트래픽 대응용은 스팟 인스턴스를 활용하세요. 스팟은 AWS가 남는 서버를 빌려주는 거라 최대 90%까지 저렴합니다. 도중에 서버가 회수될 수 있지만, 어차피 추가 서버 대열이라 시스템에 큰 무리가 없죠. 다른 옵션인 A와 B는 너무 비싸고, D는 '장기 약정 없이'라는 문제의 조건에 어긋납니다.

정답은 A와 B입니다. CloudFront의 유료 콘텐츠 보호법은 딱 두 가지입니다. 첫째, 주소 자체를 일회용으로 만드는 '서명된 URL(B)'입니다. 쿠키를 못 쓰는 손님에게 최고죠. 둘째, 여러 파일에 한 번에 권한을 주는 '서명된 쿠키(A)'입니다. 주소를 못 바꾸는 손님들을 위해 배경 정보(Cookie)에 권한을 심어주는 방식입니다. 이 두 도구를 적절히 섞어 쓰면 어떤 손님이 와도 대처가 가능합니다. 다른 옵션인 C, D, E는 CloudFront의 기본 통제 기능이 아닐뿐더러 문제의 특수한 제약 사항(쿠키 불가, 주소 변경 불가)을 동시에 해결해주지 못합니다.

정답은 A와 B입니다. 스트리밍 데이터 처리의 왕도는 Kinesis(A)와 MSK(B)입니다. Kinesis 계열은 설정이 매우 간편하고(서버리스), Analytics를 붙이면 흐르는 데이터에 SQL을 날려 즉석에서 가공할 수 있습니다. MSK도 업계 표준인 Kafka를 쓰기에 호환성이 좋고 Glue와 찰떡궁합이죠. 마지막에 S3에 쌓인 데이터를 SQL로 조회할 때는 Athena가 최고의 가성비를 보여줍니다. 다른 옵션인 C는 실시간보다는 배치 작업용에 가깝고, D와 E에서 언급된 RDS 쿼리 편집기는 S3 파일 직접 조회용으로는 적절하지 않습니다.

정답은 D입니다. "모든 데이터에 대한 로컬 성능 유지"가 핵심 키워드입니다. '저장된 볼륨(Stored Volume)' 방식은 데이터를 사내 서버 하드에 100% 온전히 저장해서 평소엔 인터넷을 안 타기에 엄청나게 빠릅니다. 그러는 동안 뒤에서는 AWS로 쉼 없이 백업본을 복제하죠. 속도와 백업, 두 마리 토끼를 다 잡는 정석 하이브리드 설계입니다. 다른 옵션인 A와 B는 이사용 상자라 상시 백업용으로는 부적절하고, C의 '캐시된 볼륨'은 자주 쓰는 것만 로컬에 두는 방식이라 '모든 데이터 로컬 액세스'라는 조건에 미달입니다.

정답은 B입니다. S3와 DynamoDB는 VPC 밖에 있는 공공 서비스지만, '게이트웨이 엔드포인트'라는 비밀 통로를 쓰면 인터넷 게이트웨이 없이도 내부망으로 직접 대화할 수 있습니다. 설정도 쉽고 추가 비용도 없으며, 무엇보다 데이터가 인터넷을 한 번도 구경하지 않으니 보안상 가장 완벽합니다. 다른 옵션인 C는 결국 NAT라는 게이트를 넘어서 인터넷 세상으로 한 발짝 나가는 꼴이라 탈락이고, D의 VPN은 사내망 연결용이지 VPC 내부에서 S3 가는 길에는 쓰지 않습니다.

정답은 B입니다. 'S3 Object Lambda'라는 신기술을 쓰면 됩니다. 데이터 원본은 하나만 두되, 앱이 파일을 달라고 할 때 중간에 람다가 슥 나타나서 내용을 검열하는 거죠. 1번 앱이 요청하면 원본 그대로, 2번 앱이 요청하면 민감 정보만 별표(*)로 바꿔서 주는 식입니다. 파일을 복사할 필요도 없고 서버를 관리할 필요도 없으니 운영 효율이 우주 최강입니다. 다른 옵션인 A는 서버 관리가 힘들고, C와 D는 데이터 양이 테라바이트급이라 저장 비용과 관리 노가다가 폭발하게 됩니다.

정답은 D입니다. VPC를 만들 때 지켜야 할 철칙은 두 가지입니다. 첫째, 남의 주소(192.168.0.x)와 겹치면 안 된다! 둘째, 주소 범위(Netmask)는 /16에서 /28 사이여야 한다! 보기 중에서 /32는 너무 좁아서 기지로 쓸 수 없고(한 점일 뿐), 192.168.0.x는 기존 주소와 겹칩니다. 따라서 전혀 다른 대역이면서 유효한 범위인 10.0.1.0/24가 가장 합리적인 선택입니다. 다른 옵션인 A와 C는 가질 수 있는 아이피가 단 하나뿐이라 VPC 최소 요건인 /28보다 좁아서 생성이 불가능합니다.

정답은 B입니다. 가장 세련된 확장은 '대상 추적(Target Tracking)'입니다. "서버 여러 대의 평균 CPU를 50% 언저리로 맞춰줘"라고 설정만 하면, 65%가 되면 서버를 더 늘려서 부하를 나누고 10%가 되면 서버를 줄여 돈을 아끼죠. 자동차 크루즈 컨트롤처럼 아주 편하고 정확합니다. 다른 옵션인 A는 너무 과격하게 서버를 죽여서 안정성이 떨어지고, C는 기준이 없으니 작동하지 않습니다. D는 '자동화'의 시대에 사람이 직접 하는 시대착오적인 방식입니다.

정답은 C입니다. 고가용성 설계의 기본 공식은 "계란을 한 바구니에 담지 않는 것"입니다. 먼저 각 가용 영역(AZ)마다 전용 서브넷을 하나씩 깔아줍니다(서브넷은 AZ를 넘을 수 없거든요). 그리고 오토 스케일링 그룹이 두 서브넷을 다 쓰게 하면 서버가 반반 배분되겠죠. 마지막으로 DB도 '다중 AZ' 옵션을 켜서 옆 동네에 복제본을 두면, 한 마을이 통째로 어둠에 잠겨도 서비스는 멀쩡합니다. 다른 옵션인 B와 D는 '서브넷은 한 AZ에만 속한다'는 AWS의 물리적 대전제를 무시한 상상 속의 설계입니다.

정답은 B입니다. 슈퍼컴퓨팅이나 대규모 연구 데이터 처리(HPC)의 1타 강사는 'FSx for Lustre'입니다. 특히 SSD 모델을 선택하면 물리적인 한계를 뛰어넘는 미친듯한 속도를 보여주죠. 원본은 싼 S3에 던져두고, 연산이 필요할 때만 Lustre가 슥 가져와서 수백 대 서버에게 빛의 속도로 뿌려주는 방식이 연구소의 정석입니다. 다른 옵션인 A와 D는 주로 기업용 파일 서버용이라 Lustre만큼의 압도적인 병렬 처리 성능은 안 나오고, C의 HDD는 속도가 너무 느려서 연구소의 까다로운 기준을 맞출 수 없습니다.

정답은 C입니다. 24시간 돌아가는 확정적인 서비스라면 '예약 인스턴스(RI)'가 최고의 할인 쿠폰입니다. 특히 데이터가 계속 늘어날 때는 저장 공간을 알아서 키워주는 'Aurora' DB가 유지보수 면에서 훨씬 유리합니다. 서버와 DB 모두 1년 혹은 3년 계약을 맺으면 일반 가격보다 70% 가까이 저렴하게 쓸 수 있으니, 회장님께 칭찬받을 가장 가성비 좋은 전략입니다. 다른 옵션인 A는 앱이 갑자기 꺼지면 안 되기에 부적절하고, B와 D는 한쪽만 할인받기에 전체적인 비용 최적화가 덜 된 상태입니다.