AWS SAA C03 연습 문제 (351~375번)

정답은 D입니다. 복잡한 워크플로(여러 단계의 로직)를 조율하는 '지휘자' 역할에는 Step Functions가 최고입니다. 특히 '서버리스'와 '낮은 운영 오버헤드'를 원하신다면, Step Functions로 전체 흐름(상태 머신)을 짜고 각 단계의 실제 작업은 Lambda라는 일꾼에게 맡기는 조합이 가장 완벽합니다. 이렇게 하면 서버 관리 걱정 없이 논리적인 흐름을 안정적으로 유지할 수 있습니다. 다른 옵션인 A는 데이터 변환(ETL)에 특화되어 있고, B는 EC2 서버를 직접 관리해야 하기에 오버헤드가 큽니다. C는 단순한 일정 예약이나 이벤트 전달용이지 복잡한 단계별 상태 관리를 하기엔 역부족입니다.

정답은 B입니다. UDP를 사용하는 게임 서비스에서 전 세계적인 속도 향상을 원한다면 Global Accelerator가 정답입니다. 이 서비스는 사용자의 요청을 가장 가까운 AWS 전용망 입구로 안내하여, 정체된 공용 인터넷 구간을 최소화하고 광속의 AWS 내부망을 타고 리전까지 배달해줍니다. 특히 게임에 필수인 UDP 리스너를 완벽히 지원하여 패킷 손실과 지연 시간을 획기적으로 줄여줍니다. 다른 옵션인 A와 D는 망 연결 기술일 뿐 사용자 접속 속도를 직접 개선하는 도구는 아닙니다. C인 CloudFront는 주로 HTTP/HTTPS 기반의 정적 콘텐츠 전송에 최적화되어 있어 게임용 UDP 처리에는 Global Accelerator가 훨씬 강력합니다.

정답은 B입니다. 현재 1,000 IOPS 정도의 부하량이라면 비싼 io2 볼륨 대신 가성비 좋은 범용 SSD(gp2)만으로도 충분합니다. RDS gp2는 기본적으로 어느 정도의 IOPS를 보장해주기 때문입니다. 여기에 '다중 AZ' 배포를 선택하면 한쪽 데이터 센터가 망가져도 서비스가 유지되므로 가용성과 비용, 두 마리 토끼를 모두 잡는 가장 경제적인 선택이 됩니다. 다른 옵션인 A는 성능은 좋지만 비용이 너무 많이 들고, C는 데이터베이스용 저장소 방식이 아닙니다. D는 서버를 직접 관리해야 하는 노가다 방식이라 운영 오버헤드를 낮추려는 목표에 맞지 않습니다.

정답은 B입니다. 람다(Lambda)와 관계형 DB(RDS)를 같이 쓸 때 가장 고질적인 문제가 바로 '연결 고갈'입니다. 람다가 순식간에 수천 개씩 켜지면 DB가 감당할 수 있는 한계치까지 접속을 시도하기 때문이죠. 이때 RDS 프록시를 중간에 두면, 프록시가 DB 연결 통로를 미리 뚫어놓고 람다들에게 효율적으로 빌려주는 '풀링(Pooling)' 역할을 대신 해줍니다. 코드 수정 없이 클릭 몇 번으로 해결할 수 있는 최고의 방법입니다. 다른 옵션인 A는 서비스 처리 능력을 깎는 처사이고, C는 비용만 많이 들고 근본적인 연결 관리 문제를 해결하지 못합니다. D는 DB 체계를 완전히 바꿔야 해서 '최소한의 코드 수정' 조건에 어긋납니다.

정답은 B입니다. 자주 안 쓰지만 필요할 때 바로 꺼내봐야 한다면 Standard-IA가 정답입니다. Standard 요금보다 저렴하면서도 데이터에 접근하는 속도는 일반 S3와 똑같기 때문입니다. '즉시 액세스'와 '고가용성' 조건을 모두 만족하는 합리적인 중간 단계 저장소입니다. 다른 옵션인 A는 데이터를 보내는 데 몇 시간이 걸려 '즉시 액세스'가 안 되고, C와 D인 One Zone-IA는 데이터 센터 한 곳에만 저장하므로 가용성이 Standard-IA보다 떨어집니다.

정답은 A와 D입니다. 웹 서비스의 국룰 설계입니다. 일단 잘 안 바뀌는 이미지 같은 정적 파일은 S3라는 창고에 넣고 CloudFront(A)라는 배달망을 붙이면 전 세계 고객이 빠르게 볼 수 있습니다. 그리고 여러 대의 윈도우 서버가 동일한 코드 파일을 읽고 써야 한다면 윈도우 전용 공유 폴더인 FSx for Windows(D)를 쓰면 됩니다. 리눅스라면 EFS를 썼겠지만 윈도우 서버이기에 FSx가 짝꿍입니다. 다른 옵션인 B(캐시)는 단순 이미지 파일 전송에는 과하고, C(EFS)는 리눅스 전용입니다. E(EBS)는 한 번에 서버 한 대에만 붙을 수 있어서 여러 서버가 파일을 공유하기엔 부적절합니다.

정답은 C입니다. 사용자에게 가장 가까운 배달 거점(에지)에서 즉석 요리를 해주는 Lambda@Edge가 정답입니다. 요청이 들어왔을 때 '아, 이분은 아이폰이네? 그럼 작게 줄여서 줘야지'라고 에지 서버에서 바로 판단해 이미지를 깎아 보내줍니다. 서버를 직접 관리할 필요도 없고 전 세계 어디서든 똑같이 빠르게 작동하니 운영 부담이 거의 없습니다. 다른 옵션인 A는 서버 관리가 고역이고, B와 D는 단순한 정책 설정일 뿐 이미지 픽셀을 직접 깎는 복잡한 로직을 수행할 수는 없습니다.

정답은 C입니다. 전송 중 보안은 'aws:SecureTransport' 규칙을 넣어 HTTPS로만 접속하게 하면 해결됩니다. 그리고 보관 중(저장된) 보안은 KMS의 '고객 관리 키'를 쓰면 됩니다. S3 관리 키(SSE-S3)는 AWS가 열쇠를 쥐고 있지만, KMS 고객 관리 키를 쓰면 우리 회사 보안팀이 직접 열쇠의 사용 권한과 만료를 관리할 수 있어 훨씬 높은 수준의 규정을 만족하게 됩니다. 다른 옵션인 A(ACM)는 웹사이트용 인증서라 S3 파일 암호화와는 결이 다르고, D(Macie)는 데이터의 내용을 분석해서 개인 정보를 찾아내는 도구일 뿐 전송/저장 암호화 강제 설정은 아닙니다.

정답은 B입니다. 집 안(VPC)에서 옆방(다른 서비스)으로 가는데 굳이 대문을 통해 밖으로 나갔다 올 필요는 없죠? 인터페이스 엔드포인트를 하나 뚫어주면, 두 API는 인터넷으로 나가지 않고 AWS 내부망 안에서 비밀 통로(Private Link)를 통해 광속으로 대화를 나눕니다. 코드 수정 없이 주소 설정 하나면 되니 아주 깔끔한 해결책입니다. 다른 옵션인 C(게이트웨이 엔드포인트)는 주로 S3나 DynamoDB 전용이고, D(SQS)는 통신 방식 자체를 비동기로 뜯어고쳐야 해서 코드 수정이 너무 많아집니다.

정답은 C입니다. '1ms 미만의 속도'라는 단어가 나오면 무조건 DynamoDB와 그 짝꿍인 가속기(DAX)를 떠올려야 합니다. DAX를 쓰면 DB에서 정보를 읽어올 때 빛의 속도로 응답해줍니다. 그리고 분석용으로 가끔 훑어보는 과거 자료는 비싼 DB에 둘 필요 없이 저렴한 S3에 파일로 저장해두고, 필요할 때만 Athena라는 도구로 파일 내용을 SQL처럼 검색해보면 비용과 성능 모두 잡을 수 있습니다. 다른 옵션인 A는 RDS 성능이 1ms 미만을 지속적으로 유지하기 어렵고, B는 실시간 속도 면에서 탈락입니다. D는 데이터 보관 방식에만 치중되어 있어 실시간 가속 성능이 빠져 있습니다.

정답은 B와 E입니다. 데이터 전송 순서가 생명이라면 두 가지 전용 도구가 있습니다. 첫째, SQS FIFO(선입선출) 방식(E)을 쓰고 '결제 ID'별로 그룹을 묶어주면 그 ID 내에서는 절대 순서가 꼬이지 않습니다. 둘째, 실시간 스트림인 Kinesis(B)를 쓰면서 결제 ID를 파티션 키로 주면, 동일한 키를 가진 데이터는 같은 통로(Shards)를 타게 되어 보낸 순서대로 도착합니다. 다른 옵션인 A와 C는 단순 저장소라 전송 순서를 제어하기 힘들고, D인 SQS '표준' 모드는 가끔 앞뒤 순서가 바뀔 수 있어 결제처럼 민감한 작업에는 쓰면 안 됩니다.

정답은 B입니다. 한 명의 발표자(이벤트)가 여러 청중(각 서비스들)에게 한 번에 소식을 알리는 방식을 '팬아웃(Fan-out)'이라고 합니다. 이 역할을 수행하면서 순서(FIFO)까지 지켜주고 싶다면 SNS FIFO 주제가 안성맞춤입니다. 소리를 지르는 즉시 약속된 서비스들이 순서대로 소식을 듣고 각자 할 일을 시작합니다. 다른 옵션인 A(EventBridge)도 좋지만 순서 보장 기능이 표준 SNS FIFO만큼 강력하지 않으며, D(SQS)는 한 번 메시지를 가져가면 사라지기 때문에 한 소식을 여러 명에게 동시에 똑같이 전파하기엔 맞지 않습니다.

정답은 B와 D입니다. 데이터 보안 2종 세트입니다. 먼저 보관 중(At-rest) 상태 보안은 KMS라는 금고에서 만든 '고객 관리 키(CMK)'를 써서 잠궈야 합니다(B, D). 그리고 이동 중(In-transit) 보안은 대기열이나 주제 설정에 'HTTPS(TLS)를 통해서만 데이터를 보내라'는 조건을 적어두면 됩니다. 이렇게 하면 승인된 직원만 열쇠를 써서 내용을 볼 수 있고, 가로채기도 불가능한 철통 보안이 완성됩니다. 다른 옵션인 A는 S3 관리 키라 사용자 권한을 세밀하게 주기 힘들고, C는 KMS 사용 제한이 빠져 있어 보안이 반쪽짜리입니다.

정답은 C입니다. RDS의 '자동 백업' 기능을 켜두면 AWS가 매일 밤 전체 백업을 하고, 낮에는 변경된 일기(로그)를 계속 적어둡니다. 이걸 활용하면 '어제 오후 2시 13분 42초'처럼 내가 원하는 구체적인 시점(Point-in-time)으로 DB를 똑같이 되살릴 수 있습니다. 최대 35일까지 가능하니 실수로 정보를 편집해도 안심할 수 있는 타임머신 같은 기능입니다. 다른 옵션인 A나 D는 서버가 고장 났을 때를 위한 대비책이지, 누군가 내용을 마음대로 수정한 걸 되돌려주지는 않습니다. B인 수동 스냅샷은 내가 찍은 그 시각으로만 갈 수 있어 5분 전 정밀 복구는 불가능합니다.

정답은 D입니다. 가장 쉽고 표준적인 '유료 등급제' 구현 방식입니다. API Gateway에 'Usage Plan'이라는 등급(예: 프리미엄, 일반)을 만들고, 유료 회원에게만 전용 'API Key'를 하나씩 나눠주는 거죠. 이 열쇠가 없는 요청은 문 앞에서 자동으로 차단되므로 개발자가 일일이 코드를 짤 필요 없이 시스템적으로 유료 회원을 우대할 수 있습니다. 다른 옵션인 A는 전체 트래픽 조절용이고, B는 해킹 방어용입니다. C는 DB 수준의 복잡한 권한 설정이라 실제 서비스 로직에 적용하기엔 너무 번거롭고 유연하지 못합니다.

정답은 A입니다. 핵심 키워드는 'UDP'입니다. UDP 프로토콜을 다루는 로드 밸런서는 NLB(Network Load Balancer)가 유일하다시피 합니다. 따라서 리전마다 NLB를 둬서 온프레미스 서버로 신호를 보내게 하고, 그 앞단에 AWS Global Accelerator를 세우면 전 세계 어디서든 대기 시간 없이 UDP 게임이나 앱에 빠르게 접속할 수 있게 됩니다. 다른 옵션인 B와 D(ALB)는 HTTP/HTTPS 전용이라 UDP를 처리하지 못합니다. C인 CloudFront도 정적 파일 전송 위주라 실시간 UDP 최적화에는 Global Accelerator가 훨씬 유리합니다.

정답은 A입니다. IAM 설정 메뉴에 가면 'Account Settings'라는 곳이 있습니다. 여기서 '비밀번호는 최소 12자리 이상이어야 함', '90일마다 새로 바꿔야 함' 같은 규칙을 한 번만 정해두면 됩니다. 그럼 앞으로 만들어지는 모든 직원 계정은 이 규칙을 따르지 않으면 비밀번호를 만들 수 없게 됩니다. 아주 쉽고 강력한 통제 방법입니다. 다른 옵션인 B는 수천 명의 직원이 있다면 불가능한 '노가다'이고, D는 성공할 보장도 없는 복잡한 코딩 작업이라 오버헤드만 늘어납니다.

정답은 A입니다. '팀마다 언어가 다르고', '1시간이나 걸리는 긴 작업'이라면 AWS Batch가 정답입니다. Batch는 각 팀이 짠 코드를 컨테이너에 담아 순차적으로 굴려주며, 성능이 모자라면 알아서 서버를 빌려다 쓰고 작업이 끝나면 돌려보냅니다. 여기에 EventBridge 시계까지 달아두면 정해진 시간마다 로봇처럼 일을 수행하니 관리자가 신경 쓸 게 없습니다. 다른 옵션인 C(Lambda)는 실행 시간이 최대 15분이라 1시간짜리 작업에는 쓸 수 없습니다. D는 단순 서버 증설일 뿐 주기적인 '배치 작업' 관리 기능은 부족합니다.

정답은 C입니다. 외부에서는 절대 우리 서버를 못 건드리게 숨겨두면서(Private), 안에서 밖으로만 나가는 길을 뚫어주는 전용 장비가 NAT 게이트웨이입니다. 특히 관리형 솔루션을 원하신다면 정답은 무조건 '게이트웨이'여야 합니다. 이 장비는 바깥 세상과 연결되어야 하므로 반드시 '퍼블릭 서브넷(대문 앞)'에 설치해야 우리 서버들이 이 문을 타고 밖으로 나갈 수 있습니다. 다른 옵션인 A와 B(인스턴스)는 서버를 직접 패치하고 관리해야 해서 귀찮고, D는 위치가 틀렸습니다(외부와 통신하려면 반드시 퍼블릭 쪽에 발을 담그고 있어야 합니다).

정답은 D입니다. (문제 요구사항에 명시된 2개 선택은 설정 상 '리전 기본값 설정'과 'KMS 권한 부여'를 의미하는 경우가 많으나, 여기서는 단일 핵심 설정을 묻는 것으로 해석됩니다. 정석은 D입니다.) 가장 똑똑한 방법은 리전 전체 설정에서 '앞으로 생기는 모든 하드는 암호화해!'라는 옵션을 켜두는 것입니다. 그리고 그 열쇠(KMS)를 우리 걸로 지정해두면, EKS가 서버를 몇 백 대를 만들든 아무런 관리 노력 없이 모든 하드가 우리 회사 열쇠로 찰칵 잠귄 채로 생성됩니다. 다른 옵션인 A나 E는 복잡한 코딩이나 관리가 필요하고, B는 하드가 수백 개가 될 때 수동으로 하는 건 불가능에 가깝습니다.

정답은 B입니다. 용량이 큰 '이미지' 파일은 무제한 창고인 S3에 넣는 것이 비용 면에서 압도적으로 유리합니다. 하지만 S3는 수만 개의 파일을 초단위로 검색하기엔 조금 느릴 수 있죠. 그래서 '경로 정보'만 아주 빠른 DynamoDB에 적어두는 겁니다. 그러면 시스템은 DynamoDB에서 주소를 광속으로 찾고, S3에서 이미지를 쏙 빼오는 가장 완벽한 협업 시스템을 구축하게 됩니다. 다른 옵션인 A는 DB 용량이 엄청나게 커지고 비용이 감당 안 되며, C는 큰 파일을 DynamoDB에 넣으면 전송료와 저장료 때문에 지갑이 거덜날 수 있습니다.

정답은 D입니다. (문제 맥락상 수명 주기 정책을 세세하게 짜는 D가 비용 최적화의 정석인 경우가 많습니다.) 데이터의 '나이'에 따라 방을 옮겨주는 게 비용 절감의 핵심입니다. 매일 쓰는 쌩쌩한 30일 치 데이터는 가장 빠른 Standard 방에 두고, 가끔 쓰는 1년 치 자료는 좀 더 저렴한 Standard-IA 방으로 옮깁니다. 그리고 1년이 지나서 안 쓰는 건 거의 공짜나 다름없는 Glacier Deep Archive 창고로 보내버리는 '수명 주기 정책(Lifecycle Policy)'을 세우면 수억 원의 비용을 아낄 수 있습니다. 다른 옵션인 A(Intelligent-Tiering)는 편리하지만 파일이 수조 개가 되면 관리 수수료가 발생해 오히려 D보다 비싸질 수 있습니다.

정답은 D입니다. 네트워크의 '중앙 허브' 역할을 하는 Transit Gateway(TGW)가 주인공입니다. VPC가 여러 개일 때 길을 하나하나 뚫으면 너무 복잡해지죠. 그래서 모든 VPC를 TGW라는 정거장에 연결하고, 거기서 대규모 데이터를 실어 나를 수 있는 고속 고속도로인 'Direct Connect(DX)' 선을 하나만 데이터 센터로 쫙 깔아주면 성능도 최고이고 관리도 혁신적으로 편해집니다. 다른 옵션인 A와 B(VPN)는 공용 인터넷 회선을 타기 때문에 수백 GB의 데이터를 매일 안정적으로 보내기엔 속도가 느리고 불안정할 수 있습니다.

정답은 A입니다. '워크플로 오케스트레이션'의 끝판왕은 Step Functions입니다. 이 도구는 '함수 A가 끝나면 함수 B를 실행해, 근데 만약 에러 나면 함수 C로 가' 같은 복잡한 흐름을 그림 그리듯 정의할 수 있습니다. 특히 이 문제의 핵심인 '사람의 수동 승인' 대기 기능(Wait for Task Token)이 있어, 담당자가 승인할 때까지 프로세스를 안전하게 멈춰둘 수 있는 아주 똑똑한 지휘자입니다. 다른 옵션인 C와 D는 흐름이 조금만 복잡해져도 어디서 에러가 났는지 찾기 힘든 스파게티 시스템이 되기 쉽고, B는 데이터 변환용이라 비즈니스 로직 조율에는 적합하지 않습니다.