AWS SAA C03 연습 문제 (201~225번)

정답은 B입니다. 고객과의 양방향 마케팅 소통(SMS 발신 및 수신)에 가장 특화된 서비스는 Amazon Pinpoint입니다. Pinpoint는 단순히 메시지를 보내는 것을 넘어 사용자의 반응을 추적하고 분석하는 '여정(Journey)' 기능을 제공하며, Kinesis와 연결하면 들어오는 모든 응답 데이터를 1년 이상 장기 보관하거나 실시간으로 분석하기에 최적인 구조를 갖출 수 있습니다. 다른 옵션인 A의 Connect는 주로 콜센터 상담원용 서비스이며, C와 D는 단순한 메시지 전달 대기열이나 알림 서비스일 뿐 마케팅 관점에서의 양방향 캠페인 관리와 데이터 분석 기능을 직접 제공하지는 않습니다.

정답은 B입니다. 사용자가 키 관리 권한을 가지면서도 '자동 순환'이라는 편의성을 챙기려면 KMS의 고객 관리형 키(CMK)가 정답입니다. 이 키를 생성할 때 '매년 자동 순환' 옵션만 클릭해두면, AWS가 알아서 1년마다 새로운 암호화 버전의 키를 만들어 보안성을 높여줍니다. 이를 S3 버킷의 '기본 암호화'로 지정하면 앞으로 들어오는 모든 파일에 이 규칙이 자동 적용됩니다. 다른 옵션인 A는 키 관리의 주도권이 부족할 수 있고, C는 매년 사람이 직접 챙겨야 하므로 실수할 위험이 큽니다. D는 키 자료를 직접 관리해야 하는 복잡한 'BYOK' 방식이라 운영 수고가 너무 많이 듭니다.

정답은 D입니다. 확인 메일이 늦어지는 이유는 '메일을 쏘는 서버(소비자)'의 일손이 부족하기 때문입니다. SQS 바구니에 처리해야 할 편지는 쌓여가는데 직원은 그대로라면 당연히 지연이 생깁니다. 이때 SQS 대기열에 쌓인 메시지 수(대기열 깊이)를 기준으로 EC2 서버 숫자를 탄력적으로 늘려주는 오토 스케일링을 도입하면, 바쁠 때만 일꾼이 확 늘어나서 순식간에 메일을 다 처리하게 됩니다. 다른 옵션인 A, B, C는 데이터 저장 속도나 화면 접속 속도를 높여줄 뿐, 정작 '밀려있는 메일 발송 작업' 자체를 빠르게 처리해주지는 못하는 핀트가 어긋난 대책입니다.

정답은 C입니다. 여러 곳에 흩어진 데이터를 한데 묶어 관리하는 '데이터 레이크' 환경에서 가장 세련된 관리법은 Lake Formation을 쓰는 것입니다. 이 서비스를 통하면 S3나 RDS에 있는 데이터를 일일이 건드리지 않고도 중앙 집중식 화면에서 'A팀은 이 테이블의 이 컬럼만 봐라' 같은 아주 세밀한(Granular) 권한 설정을 클릭 몇 번으로 끝낼 수 있어 운영 효율이 압도적입니다. 다른 옵션인 A는 확장이 어렵고, B는 사용자 수가 많아지면 S3 정책 관리가 지옥으로 변합니다. D는 Redshift라는 비싼 분석 서버를 직접 관리하고 데이터를 옮기는 등 운영 오버헤드가 너무 큽니다.

정답은 C입니다. 정적 웹사이트를 운영할 때 서버를(EC2나 Lightsail) 띄우는 것은 돈 낭비이자 관리 낭비입니다. S3에 파일을 던져놓고 CloudFront를 붙이는 것이 가장 저렴하고 튼튼한데, 이때 OAC(오리진 액세스 제어) 기능을 쓰면 S3를 외부에 노출하지 않고도 안전하게 CloudFront 배달부만 들여보낼 수 있습니다. 업로드는 무료 도구인 AWS CLI를 쓰면 SFTP보다 훨씬 빠르고 간편합니다. 다른 옵션인 A와 B는 관리할 서버가 생겨서 비용과 수고가 많이 들고, D는 SFTP 서비스 자체가 고가의 유료 서비스라 '비용 효율적'이라는 이번 요구 사항에 전혀 어울리지 않습니다.

정답은 C입니다. AWS 리소스에 어떤 '사건(Event)'이 터졌을 때 즉각 반응하는 신호등은 EventBridge입니다. 별도의 복잡한 코딩이나 로그 분석 엔진을 돌릴 필요 없이, 관리 콘솔에서 'CreateImage API가 호출되면 SNS로 알려줘'라고 규칙 하나만 정해두면 끝납니다. 운영 오버헤드가 거의 0에 수렴하는 가장 세련된 자동화 방식입니다. 다른 옵션인 A, B, D는 로그를 직접 한 줄 한 줄 읽어서 비교하는 코드를 짜거나 분석기(Athena)를 돌려야 해서 개발 및 운영 부담이 크고 실시간성도 떨어집니다.

정답은 D입니다. 데이터베이스가 감당 못 할 만큼 요청이 쏟아져서 '유실'이 생기는 상황의 구원투수는 SQS입니다. 요청을 DB에 바로 꽂지 말고 SQS라는 안전한 바구니에 먼저 담아둔 뒤, 람다 일꾼이 DB 컨디션을 봐가며 바구니에서 하나씩 꺼내 넣게 만들면 됩니다. 이렇게 '완충(Buffering)' 지대를 두면 아무리 사람이 몰려도 요청이 버려지지 않고 안전하게 보관되었다가 결국 모두 처리됩니다. 다른 옵션인 A는 손님을 입구에서 쫓아내는 거라 서비스 만족도가 낮아지고, B의 DAX는 읽기 전용이지 쓰기 작업을 버퍼링해주지는 않습니다. C는 조회 속도 개선용이라 입력 폭주 상황과는 거리가 멉니다.

정답은 A입니다. 인터넷을 거치지 않고 S3와 통신하는 가장 확실한 방법은 VPC 엔드포인트를 쓰는 것입니다. 특히 인터페이스 엔드포인트(PrivateLink)나 게이트웨이 엔드포인트를 활용하면 트래픽이 AWS 내부망을 통해서만 흐르게 됩니다. 여기에 S3 버킷 정책에 '오직 이 IAM 롤을 가진 녀석만 허용한다'는 수문장 규칙을 추가하면, 전 세계 어디서든 보이지 않는 우리만의 안전한 데이터 수송로가 완성됩니다. 다른 옵션인 C와 D는 아이피 주소가 수시로 바뀌는 클라우드 환경에서 매우 위험하고 관리 불가능한 방식이며, 네트워크 보안의 기본 원칙에도 어긋납니다.

정답은 A입니다. 서버가 언제든 사라질 수 있는 클라우드 환경에서는 '무상태(Stateless)' 설계가 핵심입니다. 세션 정보를 서버 메모리에 저장하지 말고, 별도의 초고속 메모리 DB인 ElastiCache에 따로 보관하면 됩니다. 그러면 어떤 서버가 죽어도 사용자는 다른 서버를 통해 ElastiCache에서 자기 로그인 정보를 가져올 수 있어 접속이 끊기지 않는 매끄러운 경험을 하게 됩니다. 다른 옵션인 B는 서버가 삭제되면 세션도 같이 날아가 버려 이번 요구 사항에는 꽝이며, C의 세션 매니저는 서버 원격 관리용 도구일 뿐 앱의 로그인 세션과는 아무 관련이 없습니다.

정답은 D입니다. 단순히 '바쁘다(CPU 높다)'고 서버를 늘리는 것보다, '앞으로 해야 할 일이 이만큼 쌓였으니 직원이 몇 명 더 필요하겠다'고 계산하는 것이 훨씬 정확합니다. SQS 대기열에 쌓인 전체 주문 수를 현재 서버 한 대가 감당하는 양으로 나누면, 지금 당장 필요한 최적의 서버 대수가 나옵니다. 이를 전문 용어로 '대상 추적 오토 스케일링(백로그 기준)'이라 하며, 자원 낭비 없이 완벽하게 대응할 수 있는 고수의 설계입니다. 다른 옵션인 A와 B는 융통성이 없어 돈이 많이 들거나 대응이 늦고, C는 '얼마나 늘려야 할지'에 대한 정교한 계산이 빠져 있어 효율적인 운영이 어렵습니다.

정답은 D입니다. 태그로 자원을 관리할 때 가장 강력하고 빠른 도구는 '태그 에디터(Resource Groups)'입니다. 이 도구는 AWS 모든 지역의 모든 서비스를 관통해서 '이 태그 붙은 거 다 보여줘'라고 한 번만 외치면 즉시 목록을 뽑아줍니다. 운영자가 노가다를 하지 않아도 되는 중앙 통제실 같은 기능입니다. 다른 옵션인 A와 C는 로그를 분석하는 거라 이미 태그가 붙어 있는 '정적인 자원 상태'를 한눈에 파악하기에는 너무 돌아가는 방식이며, B는 사람이 직접 발품을 파는 일종의 '노가다'라 효율성이 극도로 떨어집니다.

정답은 A입니다. '액세스 패턴을 알 수 없다'는 말이 나오면 사실상 답은 하나로 정해져 있습니다. 바로 S3 지능형 계층화입니다. 이 등급을 선택하면 AWS의 AI가 데이터를 지켜보다가, 많이 보면 Standard 등급 가격으로 적게 보면 저렴한 IA 등급 가격으로 알아서 결제 방식을 바꿔줍니다. 사용자는 성능 저하(검색 시간 지연) 걱정 없이 가만히 숨만 쉬어도 돈이 아껴지는 마법을 경험하게 됩니다. 다른 옵션인 B는 정말 가끔(분기별 1회 등) 볼 때 유리하고, C는 비싸며, D는 패턴을 확실히 알 때(월 1회 미만 접속 등) 선택해야 추가 비용 폭탄을 피할 수 있습니다.

정답은 A입니다. 웹 애플리케이션 수준의 공격(L7 공격)을 막는 표준 방어막은 WAF입니다. 관리형 서비스라 서버를 설치할 필요도 없고, AWS가 미리 만들어둔 '관리형 규칙' 세트를 클릭 몇 번으로 적용하면 SQL 인젝션 같은 위협으로부터 ALB를 즉시 보호할 수 있습니다. 운영 인력이 적은 팀에게는 가뭄의 단비 같은 서비스입니다. 다른 옵션인 B는 동적인 기능이 필요한 앱에는 불가능한 처방이고, C의 Shield Advanced는 주로 대규모 트래픽 폭탄(DDoS)을 막는 데 특화된 값비싼 유료 옵션입니다. D는 직접 서버를 관리해야 해서 '운영 인력 부족'이라는 상황에 최악의 선택입니다.

정답은 B입니다. 데이터를 긁어오고(Extract), 변환하고(Transform), 저장하는(Load) 'ETL' 작업의 지존은 AWS Glue입니다. 특히 CSV를 Parquet로 바꾸는 과정은 Glue의 기본 기능이라서 개발자가 고생스럽게 코딩할 필요 없이 메뉴에서 슥슥 고르기만 하면 끝납니다. 서버 관리도 필요 없는 완전 관리형 서비스라 운영 효율 또한 최강입니다. 다른 옵션인 A, C, D는 결국 누군가가 복잡한 코드를 짜서 유지보수해야 하므로 '개발 노력 최소화'라는 목표와는 거리가 멀어집니다.

정답은 A입니다. 700TB를 500Mbps 회선으로 보내려 하면 물리적으로 몇 달이 걸릴지 모르는 계산이 나옵니다. 이럴 땐 '데이터 전용 택배'인 Snowball이 정답입니다. 거대한 외장 하드 장비를 AWS에서 빌려와서 데이터를 가득 담아 트럭으로 보내면, 며칠 안에 AWS 센터에서 파일들을 S3에 슥 풀어놓습니다. 시간도 아끼고 네트워크 비용도 아끼는 가장 현실적인 물류 전략입니다. 다른 옵션인 B와 D는 느린 인터넷 속도 때문에 기한(한 달)을 맞추기 불가능하며, C는 전용선을 까는 기간만 해도 한 달이 훌쩍 넘어가서 배보다 배꼽이 더 커지는 상황이 됩니다.

정답은 B입니다. '이미 있는 대량의 파일'들을 처리할 때는 'S3 배치 작업(Batch Operations)'이 유일한 희망입니다. 일단 버킷의 기본 암호화 설정을 켜서 앞으로 올 파일들을 대비하고, 기존 파일들은 S3 Inventory 기능으로 명단을 쫙 뽑아서 배치 작업에게 '이 리스트에 있는 애들 전부 제자리 복사(Self-Copy)해!'라고 시키면 됩니다. 복사되는 과정에서 자동으로 암호화가 적용되어 수백만 개 파일이 순식간에 안전하게 변신합니다. 다른 옵션인 A는 시간과 비용이 어마어마하게 들고, C는 이미 있는 파일엔 영향을 주지 않으며, D는 사람의 손가락이 남아나지 않을 무모한 방식입니다.

정답은 A입니다. 고가용성이 아닌 '재해 복구' 관점에서 가성비를 챙기려면 Active-Passive 방식이 딱입니다. Aurora의 '교차 리전 복제본'을 쓰면 평소엔 메인 DB의 내용을 조용히 복사만 해두다가, 진짜 비상상황이 터졌을 때 Route 53 신호탄을 쏘아 이 복제본을 메인으로 승격시키면 됩니다. 30분 이내 복구라는 조건도 충분히 만족하면서 상시 운영 비용도 최소화할 수 있습니다. 다른 옵션인 B는 평소에도 두 배의 돈이 나가서 낭비고, C와 D는 사고가 난 뒤에야 DB를 굽고 인프라를 만드느라 30분이라는 골든타임을 놓치기 십상입니다.

정답은 A와 E입니다. AWS 보안의 핵심은 '보안 그룹은 상태 유지(Stateful), ACL은 상태 비저장(Stateless)'이라는 점입니다. 우선 보안 그룹에서는 들어오는 길(443)만 열어주면 나가는 길은 알아서 열립니다. 하지만 깐깐한 네트워크 ACL은 나가는 길도 직접 열어줘야 하는데, 요청에 답을 하고 나가는 문인 '임시 포트(32768-65535)' 범위를 아웃바운드 규칙에 꼭 추가해야만 실제로 손님들이 웹사이트 화면을 볼 수 있게 됩니다. 다른 옵션인 B는 나가는 길만 열어서 소용없고, C와 D는 네트워크 ACL의 특성(돌아가는 길도 일일이 열어야 함)을 간과했기 때문에 실제로는 접속이 되지 않습니다.

정답은 D입니다. 메모리가 딸릴 때 가장 확실한 처방법은 '메모리 특화 서버(R5)'로 이사를 가는 것입니다. 하지만 서버만 바꾼다고 끝이 아닙니다. 왜 느린지 정확히 파악하고 나중에 또 그럴 걸 대비하려면 감시 체계를 갖춰야 하는데, 기본 지표만으론 메모리 내부 상황을 다 알 수 없습니다. 서버 안에 'CloudWatch 에이전트'라는 스파이를 심어서 메모리와 지표를 세밀하게 보고하게 만드는 것이 가장 전문적이고 운영 효율적인 대처입니다. 다른 옵션인 A의 T3는 범용이라 메모리 작업엔 부족하고, B는 근본적인 사양 문제를 해결하지 못해 돈만 더 나갑니다. C는 정밀한 감시가 안 되어 나중에 또 뒷통수를 맞을 수 있습니다.

정답은 B입니다. '들쑥날쑥한 요청량'과 '비용 최소화'의 정석 조합은 무조건 람다(Lambda)입니다. 람다는 손님이 없을 땐 돈을 한 푼도 내지 않고 죽어 있다가, 요청이 딱 들어오는 그 순간에만 0.몇 초 반짝 일을 하고 다시 사라집니다. 일을 한 시간만큼만 돈을 내니, 몇 시간씩 손님이 안 오는 이런 상황에선 이보다 더 싼 서비스가 있을 수 없습니다. 다른 옵션인 C와 D는 손님이 오든 안 오든 서버 월세를 계속 내야 해서 돈이 줄줄 새고, A의 Glue는 데이터 가공(ETL) 전문이지 가벼운 API 요청을 실시간으로 처리하기엔 너무 무거운 도구입니다.

정답은 D입니다. 7년이라는 장기 보존과 방대한 양, 그리고 동시 분석까지 고려하면 S3가 정답입니다. S3는 사실상 용량 제한이 없고 저장 비용이 매우 저렴하며, Athena 같은 도구를 쓰면 S3에 있는 수백만 개의 로그 파일을 그 자리에서 동시에 SQL로 분석할 수도 있습니다. 로그 보관소로 이보다 완벽한 곳은 없습니다. 다른 옵션인 A와 B는 저장 공간 관리도 힘들고 무엇보다 가격이 S3에 비해 너무 비싸서 7년이나 보관하기엔 지갑이 거덜 납니다. C는 서버가 꺼지면 로그도 사라지는 '일회성' 저장소라 규정 준수라는 목표와는 아예 상극입니다.

정답은 A입니다. 계정끼리 권한을 빌려줄 때 쓰는 필살기가 바로 'IAM 역할 위임(Role Assumption)'입니다. 우리 쪽 계정에 '이 역할을 가진 놈은 우리 집 창고를 열 수 있어. 단, 옆 동네(외부 업체) 계정의 누구누구만 이 역할을 맡을 수 있어'라고 신뢰 관계를 맺어두면 됩니다. 아이디나 비번을 건네줄 필요가 없으니 보안상 가장 안전하고 뒤끝도 깔끔합니다. 다른 옵션인 B는 비번이 유출되거나 업체가 바뀌면 골치가 아파지는 전형적인 보안 하책이며, C 방식은 기술적으로 불가능합니다. D의 자격 증명 제공자는 주로 구글이나 페이스북 로그인(SAML) 같은 외부 인증 시스템을 연동할 때 쓰는 도구입니다.

정답은 A와 D입니다. 망을 타지 않고 서비스와 직접 연결하려면 'VPC 엔드포인트'가 필수입니다. 이 통로를 통해 트래픽이 AWS 내부의 보이지 않는 선을 타고 DynamoDB로 바로 꽂힙니다. 여기에 한 걸음 더 나아가, 포드(컨테이너)마다 개별적으로 'IAM 역할'이라는 출입증을 달아주면(IRSA), 복잡한 비번 관리 없이도 가장 안전하고 빠르게 데이터를 저장할 수 있는 철통 보안 시스템이 완성됩니다. 다른 옵션인 B와 E는 보안의 기초도 안 지킨 위험천만한 방식이며, C는 '인터넷을 타지 말라'는 고객의 특명을 정기적으로 어기는 엉터리 설계입니다.

정답은 C와 E입니다. 고가용성의 황금률은 '나누는 것'입니다. 먼저 서버를 물리적으로 떨어진 두 곳의 데이터 센터(AZ)에 골고루 배치하면, 한 동네에 전기가 끊겨도 다른 동네 서버가 멀쩡히 일을 합니다. 여기에 Route 53의 '다중값 응답' 정책을 쓰면, 여러 서버의 주소를 손님에게 무작위로 하나씩 툭툭 던져주어 부하를 공평하게 나누고 장애가 난 서버는 알아서 거를 수 있게 되어 아주 단단한 시스템이 완성됩니다. 다른 옵션인 A는 평소엔 한 대만 써서 아깝고, B는 무작위라기보단 의도적인 비중 조절용이며, D는 한 AZ가 통째로 무너지면(지진 등) 답이 없는 위험한 도박입니다.

정답은 B입니다. 엄청난 데이터를 분석하는 정석 코스는 'Firehose(수집)'와 'Redshift(창고)'의 만남입니다. Firehose는 들어오는 데이터를 알아서 차곡차곡 모았다가 창고로 던져주는 관리형 배달부이고, Redshift는 페타바이트급 데이터도 눈 깜빡할 사이에 SQL로 뒤져볼 수 있게 해주는 슈퍼컴퓨터 급 창고입니다. 이 조합은 우리가 서버 스펙을 일일이 조절하지 않아도 알아서 확장되므로 운영 효율이 환상적입니다. 다른 옵션인 A와 C는 분석 환경을 만드는 데 너무 많은 손이 가고 속도도 느리며, D는 서버 관리라는 지옥에서 벗어나지 못한 채 데이터 무게(페타바이트)를 감당하지 못하고 쓰러질 가능성이 큽니다.