AWS SAA C03 연습 문제 (151~175번)

정답은 A와 C입니다. 기업의 전사적인 정책을 강제하고 특정 리전만 사용하도록 '박제'하는 데는 AWS Control Tower와 Organizations의 서비스 제어 정책(SCP)이 가장 강력한 도구입니다. Control Tower의 가드레일은 데이터 상주 요건을 지키기에 최적화되어 있으며, SCP는 루트 수준에서 어떤 서비스나 리전도 쓰지 못하게 딱 막아버릴 수 있어 최고의 보안 컨트롤 타워 역할을 수행합니다. 다른 옵션인 B의 WAF는 웹 공격 방어용이지 인프라 정책 제어용이 아니며, D는 관리가 너무 복잡해져서 실수가 나올 확률이 높습니다. E의 Config는 문제가 터진 후 '알림'을 주는 용도라 선제적인 '차단'이 필요한 이번 요구 사항에는 2% 부족합니다.

정답은 D입니다. 서버 관리 없이 정해진 시간에만 딱 일을 시키고 싶을 때는 'Lambda + EventBridge' 조합이 진리입니다. EventBridge가 마치 자람종처럼 약속된 시간에 Lambda를 깨우면, Lambda가 RDS를 켜거나 끄는 명령만 날리고 바로 사라지기 때문에 운영 비용이 0원에 수렴할 정도로 매우 경제적입니다. 다른 옵션인 A와 C는 별도의 관리 부담이 생기거나 필요 이상의 권한 설정이 들어가서 비효율적이며, B의 캐시 도입은 DB 비용을 아끼는 근본적인 해결책이 아니라 오히려 추가 비용만 발생시키는 엉뚱한 방향입니다.

정답은 D입니다. 데이터의 나이에 따라 자동으로 저장 공간을 옮겨주는 'S3 수명 주기 정책(Lifecycle Policy)'이 최고의 해결사입니다. 90일까지는 원활한 판매를 위해 성능 좋은 Standard를 쓰고, 그 뒤에는 비용이 저렴하면서도 여전히 즉시 다운로드가 가능한 Standard-IA로 이사 보내는 것이 가장 똑똑한 돈 관리 비법입니다. 다른 옵션인 A는 초반 인기 있는 파일의 접근 비용이 비싸질 수 있고, B의 지능형 계층화는 패턴을 모를 때 쓰는 건데 우리는 이미 90일이라는 명확한 기준을 알고 있습니다. C는 수동으로 관리해야 해서 운영 부담이 너무 큽니다.

정답은 B입니다. 한번 기록하면 절대 지울 수 없는 'WORM(Write Once, Read Many)' 기능을 구현하는 표준은 S3 Object Lock입니다. 특히 규정 준수(Compliance) 모드를 선택하면 루트 사용자조차도 정해진 기간 동안은 절대 파일을 건드릴 수 없어 의료 데이터 같은 민감한 정보의 무결성을 지키는 데 가장 완벽한 방패가 됩니다. 다른 옵션인 A의 거버넌스 모드는 특정 권한이 있으면 삭제가 가능해서 보안성이 살짝 낮고, C와 D는 시스템 관리자나 코딩 실수 등으로 인해 구멍이 뚫릴 위험이 있는 하책입니다.

정답은 C입니다. 전 세계 어디서든 똑같은 사진이나 영상을 빠르게 보여주는 데는 'CloudFront(CDN)'가 제격입니다. 사용자와 가장 가까운 엣지 로케이션에 파일을 미리 복사해두고(캐싱) 바로바로 던져주기 때문에, 미국에 있는 S3 파일을 한국에서도 동네 피씨방 속도로 즐길 수 있게 해주는 마법 같은 서비스입니다. 다른 옵션인 A는 서버끼리 자료를 옮길 때 쓰는 장비고, B는 실시간 게임이나 복잡한 경로 최적화에 어울립니다. D는 비동기 처리를 위한 우체통일 뿐 파일 배달 속도와는 거리가 멉니다.

정답은 A와 E입니다. 가장 편하게 데이터 레이크를 만드는 방법은 Lake Formation과 Glue의 조합으로 데이터를 S3에 예쁘게 쌓아두는 것입니다. 특히 Parquet 같은 똑똑한 형식으로 저장해두면, 서버를 한 대도 안 띄우고도 S3 파일에 바로 SQL을 날려주는 Athena와 시각화 도구인 QuickSight를 통해 가장 적은 돈과 수고로 고급 분석 환경을 구축할 수 있습니다. 다른 옵션인 B는 실시간 흐름 분석에만 특화되어 있고, C와 D는 서버(클러스터)를 직접 띄우고 관리해야 해서 '운영 오버헤드 최소화'라는 목표에서 멀어지게 됩니다.

정답은 D와 E입니다. '백업'과 '로그'는 따로 관리해야 합니다. 백업은 AWS Backup이라는 전용 비서를 통해 5년 뒤면 알아서 폐기되도록 자동 스케줄을 짜는 것이 가장 확실하며, 감사 로그는 CloudWatch Logs로 쏴준 뒤 거기서 보관 기간을 '무기한'으로 설정하면 평생 잃어버릴 걱정 없이 법규를 준수할 수 있습니다. 다른 옵션인 A는 사람이 하는 일이라 실수가 생기기 마련이고, C의 일반적인 자동 백업은 최대 보존 기간이 35일밖에 안 되어 5년이라는 장기 보존 요건을 채울 수 없습니다.

정답은 A입니다. 실시간 스트리밍(Live)과 다시 보기(VOD) 모두에서 가장 중요한 것은 관객 근처에 콘텐츠를 복사해두는 것인데, 이를 수행하는 핵심 서비스가 바로 CloudFront입니다. 전 세계 엣지 서버를 통해 영상 데이터를 배달하기 때문에 수백만 명의 관객이 동시에 접속해도 원본 서버에 무리를 주지 않고 쾌적하게 영상을 제공할 수 있습니다. 다른 옵션인 B는 네트워크 통로를 최적화하지만 콘텐츠를 직접 들고 대기하는 '캐싱' 기능이 없고, D는 파일을 올리는(Upload) 속도만 빠르게 해주는 것이라 시청(Download) 위주인 이번 사례엔 정답이 아닙니다.

정답은 A와 C입니다. 나쁜 트래픽을 막는 가장 정석적인 방법은 입구에 '보안 요원(WAF)'을 세우는 것입니다. WAF 규칙을 통해 봇들의 패턴을 읽어낸 뒤 입구에서 바로 컷 해버리고, 추가로 허락된 사람들만 쓸 수 있는 '초대장(API Key)' 시스템을 도입하면 무분별한 가짜 요청으로부터 소중한 자원을 완벽히 보호할 수 있습니다. 다른 옵션인 B는 이미 공격자가 람다를 실행시킨 뒤라 돈이 계속 나가고, D는 모든 일반 사용자의 접근까지 막아버리는 극단적인 조치라 서비스 운영 자체가 불가능해집니다.

정답은 C입니다. 데이터 양이 300MB로 적고 바로 즉시 꺼내 봐야 한다면 S3 Standard가 최고입니다. 일단 저장 비용도 저렴할뿐더러, 필요한 순간에 딜레이 없이 바로 파일에 접근할 수 있기 때문에 가성비와 성능이라는 두 마리 토끼를 모두 잡을 수 있는 합리적인 선택입니다. 다른 옵션인 A는 분석할 때 좋지만 보관만 하기엔 너무 비싸고, B의 Glacier는 비용은 더 싸지만 데이터를 꺼내는 데 최소 몇 분에서 몇 시간이 걸려 '밀리초 단위 접근'이라는 조건을 절대 만족할 수 없습니다.

정답은 B입니다. 서버 관리 걱정(운영 오버헤드)을 아예 없애려면 '서버리스'가 답입니다. S3에 파일이 떨어지는 '사건'이 발생할 때만 람다라는 작은 일꾼을 잠시 고용해서 Aurora DB에 데이터를 넣게 만들면, 평소엔 돈을 한 푼도 안 내면서 요청이 몰릴 땐 수천 명의 일꾼이 동시에 나타나 일을 처리하는 환상적인 시스템이 됩니다. 다른 옵션인 A, C, D는 결국 서버(EC2나 컨테이너)를 관리해야 하는 귀찮음이 남아 있고, 특히 EC2는 사용하지 않을 때도 월세를 내야 해서 비용 효율 면에서도 람다에게 밀립니다.

정답은 A입니다. 슈퍼컴퓨팅(HPC) 같은 분야에서 엄청나게 빠른 속도로 데이터를 처리해야 할 땐 Lustre라는 전용 고속도로가 필요합니다. FSx for Lustre는 S3와 한 몸처럼 연결되어 데이터를 빠르게 가져와 처리하고 결과를 다시 S3에 슥 던져줄 수 있어, 복선 철도처럼 시원시원한 데이터 처리 속도를 보장합니다. 다른 옵션인 B는 윈도우 환경 전용이라 리눅스 기반 HPC에는 부적절하며, C와 D는 대규모 병렬 I/O 처리가 필요한 HPC 환경의 속도를 감당하기에는 기술적으로 역부족입니다.

정답은 A입니다. '운영 수고 제로'와 '무한 확장'을 동시에 잡으려면 Fargate가 최고의 선택입니다. 서버 사양이나 개수를 고민할 필요 없이 컨테이너만 던져주면 Fargate가 알아서 자리를 깔아주고, 사람이 몰리면 '대상 추적 정책'을 통해 알아서 서버 수를 늘려주니 개발자는 발 뻗고 잘 수 있는 구조가 됩니다. 다른 옵션인 B와 D는 결국 서버(EC2)가 몇 대인지, OS는 어떤지 하나하나 신경 써야 해서 운영 수고가 많이 들고, C는 일일이 손으로 관리해야 해서 수천 명이 몰리는 폭발적인 상황에는 절대 대응할 수 없습니다.

정답은 C입니다. 이렇게 일이 지연되거나 가끔 실패할 수 있는 환경에서는 'SQS(메시지 바구니)'가 가장 든든한 버팀목입니다. 특히 처리가 안 된 메시지들만 따로 모아두는 '배달 못한 편지 대기열(DLQ)' 기능을 쓰면, 나중에 왜 안 됐는지 원인 분석을 하기도 편하고 전체 시스템이 멈추는 일도 막을 수 있어 운영 효율이 매우 높습니다. 다른 옵션인 A는 서버 관리가 너무 힘들고, B는 실시간 흐름 처리에 좋지만 2일이나 기다려야 하는 작업에는 과한 면이 있습니다. D는 실패했을 때 메시지를 안전하게 보관해주는 기능이 약해 부적절합니다.

정답은 D입니다. S3 창고로 들어오는 우회로를 완전히 봉쇄하려면 '오리진 액세스 제어(OAC)'가 열쇠입니다. 이 설정을 하면 오직 지정된 CloudFront 배달부만 S3에 들어갈 수 있게 되는데, 이 배달부(CloudFront)의 목 줄에 'WAF(보안 요원)'를 달아두면 모든 방문자가 자연스럽게 보안 검사를 마친 뒤 안전한 통로로만 사이트를 이용하게 됩니다. 다른 옵션인 A와 C는 기술적으로 구현이 불가능한 방식이며, B는 복잡한 코딩이 들어가서 관리 오버헤드가 커질 뿐 보안의 근본 원칙인 '접근 제어'를 해결해주지는 못합니다.

정답은 D입니다. 수백만 명의 전 세계 사용자에게 똑같은 화면을 빠르게 보여주는 데는 'CloudFront(CDN)'만 한 게 없습니다. 사용자가 어디에 있든 가장 가까운 서버에서 HTML 파일을 번개처럼 꺼내줄 뿐만 아니라, S3 원본 서버에 직접 요청이 가지 않게 부하를 막아주기 때문에 가장 싸고 효율적으로 글로벌 서비스를 운영할 수 있습니다. 다른 옵션인 A는 서버가 수백만 번의 URL 요청을 감당하기 힘들고, B와 C는 관리가 너무 복잡해지고 비용만 어마어마하게 나가는 낭비에 가까운 설계입니다.

정답은 D입니다. '절대 중단 없어야 함'과 '비용 절감'이라는 두 마리 토끼를 잡으려면 정석적인 계층 전략이 필요합니다. 24시간 내내 열려 있어야 하는 가게 본체(기본 용량)는 미리 결제해서 할인을 듬뿍 받는 '예약 인스턴스'로 준비하고, 손님이 몰릴 때 임시로 투입하는 아르바이트생(추가 용량)은 가동이 보장되는 '온디맨드 인스턴스'로 채우는 것이 가장 안전하고 합리적입니다. 다른 옵션인 A와 C의 스팟 인스턴스는 AWS 사정에 따라 언제든 서버가 꺼질 위험이 있어 '중단 없는 서비스'라는 조건에 어긋나며, B는 놀고 있는 서버들까지 선불로 돈을 내는 꼴이라 비용 낭비가 심합니다.

정답은 D입니다. 수십, 수백 개의 계정을 한꺼번에 통제하는 데는 '서비스 제어 정책(SCP)'이 무조건 1순위입니다. 조직의 뿌리(루트)에 '이 서비스는 절대 금지!'라는 명령을 한 줄만 적어두면, 그 밑에 있는 모든 계정은 무슨 짓을 해도 그 서비스를 열 수 없게 되는 가장 강력하고 일관성 있는 중앙 집권형 관리 도구입니다. 다른 옵션인 A, B, C는 계정 하나하나마다 손수 설정해줘야 해서 계정 수가 늘어나면 관리가 불가능해지며, 실수로 하나라도 놓치면 보안 구멍이 뚫리는 비효율적인 방식입니다.

정답은 C입니다. AWS에서 디도스 공격을 전문적으로 막아내는 최강의 보디가드는 바로 'AWS Shield'입니다. 모든 계정에 기본으로 들어있는 Standard보다 한 차원 높은 'Advanced'를 사용하면, ALB나 CloudFront 같은 입구를 향해 쏟아지는 대규모 공격을 24시간 감지하고 자동 방어해주며 비상시 전문가의 도움까지 받을 수 있어 가장 확실한 해결책이 됩니다. 다른 옵션인 A는 보안 취약점을 찾는 검진표고, B는 개인정보 유출을 감시하는 서비스라 디도스 방어와는 상관없습니다. D는 수상한 로그를 분석하는 탐정 역할이지 공격을 몸으로 막아내는 방패는 아닙니다.

정답은 C입니다. 웹서비스의 입구 역할을 하는 ALB에 'WAF(웹 방화벽)'를 딱 붙여주는 것이 가장 영리한 방법입니다. WAF의 기능 중에는 접속자의 IP를 보고 어느 나라인지 자동으로 판단하는 규칙이 있어서, 허가된 국가가 아니면 문 앞(ALB)에서 바로 돌려보내는 지리적 차단 처리를 아주 손쉽게 구현할 수 있습니다. 다른 옵션인 A, B, D에서 쓰이는 보안 그룹이나 ACL은 단순한 숫자(IP 주소)만 따질 뿐 그 주소가 어느 나라인지는 모릅니다. 그래서 수만 개의 IP 주소를 사람이 손수 입력해야 하는 무모한 수고가 따르기 때문에 정답이 될 수 없습니다.

정답은 B입니다. '탄력성'과 '확장성'이라는 키워드에 가장 어울리는 짝꿍은 바로 API Gateway와 서버리스 람다입니다. 이 조합은 손님이 없을 땐 서버를 단 한 대도 안 띄워서 돈을 아끼고, 명절처럼 손님이 만 명, 십만 명씩 몰려오면 그 숫자에 맞춰 람다 일꾼들이 번개처럼 늘어나 일을 처리하기 때문에 가장 경제적이고 튼튼한 설계가 됩니다. 다른 옵션인 A, C, D는 결국 서버(EC2)를 직접 운용해야 해서 미리 대수를 정하거나 사량을 조절해야 하는 수고가 들고, 갑자기 몰려오는 손님들을 기민하게 받아내기에는 탄력성이 부족합니다.

정답은 C입니다. 단순히 통로만 암호화하는 HTTPS에서 한 걸음 더 나아가, 데이터 '내용물' 자체를 암호화해서 아무도 못 열어보게 만드는 것이 '필드 수준 암호화'입니다. 이렇게 하면 데이터가 AWS 내부 통로를 지나가는 동안에도 암호화가 유지되고, 오직 최종 목적지에 있는 허락된 애플리케이션만 암호를 풀 수 있어 최고 수준의 보안을 달성할 수 있습니다. 다른 옵션인 A와 B는 접근 권한을 확인하는 '열쇠' 역할일 뿐 내용물 암호화와는 상관이 없으며, D는 보안의 기본이긴 하지만 데이터 자체를 보호하는 이 문제의 핵심 필살기는 아닙니다.

정답은 B입니다. 용량이 큰 이미지나 비디오 파일을 전 세계 사용자에게 가장 싸고 빠르게 전달하는 표준 공식은 바로 'S3 + CloudFront' 조합입니다. CloudFront가 원본 대신 파일을 들고 사용자 근처 엣지 서버에서 바로바로 전달해주기 때문에(캐싱), 원본 서버는 할 일이 줄어들어 편안해지고 사용자는 기다리는 시간 없이 바로 콘텐츠를 즐길 수 있습니다. 다른 옵션인 A는 게임 패킷 같은 실시간 데이터 통로 최적화에 어울리고, C와 D는 데이터베이스의 조회 성능을 높일 때 쓰는 거라 수백만 명에게 파일을 직접 배달하는 CDN 역할과는 거리가 멉니다.

정답은 B입니다. '고가용성'의 첫걸음은 계란을 한 바구니에 담지 않는 것입니다. 지금처럼 한 AZ에 몰빵하는 대신, 오토 스케일링 그룹(ASG) 설정을 살짝 고쳐서 2~3개의 가용 영역에 분산 배치만 해도 특정 데이터 센터에 불이 나는 비상상황에서 서비스가 멈추지 않고 계속 돌아가는 강력한 생존력을 갖게 됩니다. 다른 옵션인 A와 C는 '리전'을 넘나드는 작업이라 비용과 복잡성이 너무 커지고, D는 단순히 부하를 나누는 방식이지 서버가 죽었을 때를 대비한 해결책은 아니기 때문에 고가용성 설계와는 무관합니다.

정답은 B입니다. 수천 명의 손님이 몰릴 때 DB가 힘들어하는 주범은 매번 문(연결)을 새로 열고 닫는 과정에서 발생하는 오버헤드입니다. 이때 'RDS Proxy'라는 유능한 매니저를 앞에 세우면, 이미 열려 있는 문들을 효율적으로 공유하고 관리해주어 DB의 부담을 확 줄여주고 갑작스러운 폭주에도 타임아웃 없이 매끄럽게 주문을 받아낼 수 있습니다. 다른 옵션인 A는 DB 근본 부하를 해결 못 하고, C는 쓰기 작업(주문)에는 큰 도움이 안 되며, D는 DB 자체를 뜯어고치는 큰 공사라 '최소한의 변경'이라는 요구 사항에 전혀 맞지 않는 무리수입니다.