AWS SAA C03 연습 문제 (176~200번)

정답은 A입니다. VPC 내부에서 S3나 DynamoDB 같은 AWS 공용 서비스에 프라이빗하게 접근하고 싶을 때는 게이트웨이 엔드포인트가 정답입니다. 이 방식을 쓰면 데이터가 인터넷을 한 발짝도 밟지 않고 AWS 내부 전용망을 통해서만 이동하므로, 보안성이 가장 높으면서도 별도의 장비 비용(NAT 등)이 들지 않아 매우 경제적입니다. 다른 옵션인 B와 C는 결국 NAT라는 중계기를 통해 외부망(인터넷) 경로를 거쳐야 하므로 보안상 덜 안전하며, D의 인터넷 게이트웨이 방식은 프라이빗 서브넷이라는 전제 조건을 아예 무너뜨리는 위험한 설계입니다.

정답은 B입니다. DynamoDB의 성능 효율을 높이면서 '앱 코드 수정 최소화'와 '운영 부담 감소'라는 두 마리 토끼를 잡으려면 DAX가 유일한 해답입니다. DAX는 DynamoDB 전용 캐시 서버로, 기존 API와 완벽히 호환되기 때문에 코드 수정 없이 설정만으로 읽기 성능을 마이크로초 단위로 단축해주는 효자 서비스입니다. 다른 옵션인 A와 D의 ElastiCache는 범용 캐시라 성능은 좋지만, 이를 쓰기 위해 애플리케이션의 데이터 읽기/쓰기 로직을 대대적으로 수정해야 하므로 이번 요구 사항과는 맞지 않습니다. C의 전역 테이블은 전 세계 배포에는 유리하지만 단일 리전 내의 읽기 지연 해소와는 직접적인 관계가 적습니다.

정답은 A입니다. 여러 서비스의 백업을 한곳에서 통합 관리하고 타 리전 복사까지 알아서 해주는 'AWS Backup'이 정답입니다. 관리 콘솔에서 정책 하나만 세워두면 EC2와 RDS 모두를 약속된 시간에 백업하고 안전한 다른 나라 리전으로 옮겨주기 때문에, 운영자의 수고를 가장 많이 덜어주는 현대적인 방식입니다. 다른 옵션인 B의 DLM은 주로 EBS 볼륨 백업에 특화되어 있어 RDS까지 아우르기엔 부족하며, C와 D는 서비스마다 설정법이 다르고 수동 작업이나 복잡한 파이프라인이 들어가서 운영 오버헤드가 크게 발생합니다.

정답은 A입니다. EC2 인스턴스에게 특정 권한(파라미터 읽기 및 암호 풀기)을 안전하게 전달하는 표준 방법은 IAM 역할을 사용하는 것입니다. 아이디와 비번 같은 민감 정보는 파라미터 스토어에서 암호화되어 저장되므로, 이를 읽기 위한 'Get' 권한과 암호를 풀기 위한 'KMS Decrypt' 권한을 하나로 묶어 역할로 부여하는 것이 가장 보안상 우수하고 깔끔합니다. 다른 옵션인 B의 정책 직접 할당은 인스턴스 단위가 아닌 개별 사용자 단위라 관리 효율이 떨어지며, C와 D에서 언급한 신뢰 관계 설정 방식은 이 상황의 권한 부여 로직과는 전혀 다른 엉뚱한 기술적 접근입니다.

정답은 B와 C입니다. 웹 공격(L7)과 네트워크 공격(L3/L4)을 모두 잡으려면 WAF와 Shield Advanced의 협공이 필요합니다. 먼저 API Gateway에 WAF를 붙여 SQL 인젝션 같은 지저분한 웹 공격을 1차로 걸러내고, NLB에는 Shield Advanced를 적용해 폭풍처럼 쏟아지는 대규모 DDoS 공격으로부터 인프라를 지켜내는 것이 가장 완벽한 방패 구성입니다. 다른 옵션인 A의 WAF는 NLB에 직접 붙일 수 없고(ALB만 가능), D와 E의 Standard 서비스는 기본적인 방어는 해주지만 '대규모 지능형 공격'을 확실히 밀어내기에는 힘이 부칩니다.

정답은 A입니다. 마이크로서비스들 사이에서 '서로 몰라도 일이 되게' 만드는(디커플링) 일등 공신은 SQS입니다. 데이터가 들어오는 대로 SQS라는 바구니에 담아두면, 받는 쪽 서버가 바쁘더라도 데이터가 날아가지 않고 안전하게 보관되었다가 여유가 생길 때 순차적으로 처리할 수 있어 시스템 전체의 안정성이 비약적으로 상승합니다. 다른 옵션인 B의 SNS는 알림을 뿌리는 용도라 데이터를 안전하게 '보관'했다가 처리하기엔 부족하며, C와 D는 불필요하게 구조가 복잡해지거나 추가적인 코딩 부담이 커서 운영 효율 면에서 SQS에게 밀립니다.

정답은 B입니다. 고가용성과 데이터 무결성을 위한 AWS의 표준 답안은 '다중 AZ(Multi-AZ) 배포'입니다. 이 기능을 켜면 AWS가 알아서 다른 가용 영역에 똑같은 복제본을 동기식으로 만들어 관리하며, 메인 DB가 죽더라도 0.1초의 망설임 없이 복제본을 메인으로 승격시켜 서비스를 유지해주기 때문에 데이터 손실 걱정을 싹 날려줍니다. 다른 옵션인 A는 비용이 너무 많이 들고 관리 포인트가 늘어나며, C의 읽기 복제본은 '비동기' 방식이라 메인 DB가 죽는 찰나의 데이터는 잃어버릴 위험이 있습니다. D는 사람이 수동으로 시스템을 구축하는 것이라 신뢰도가 낮고 운영 부담만 큽니다.

정답은 A입니다. '서버 관리 최소화'와 '무한 확장성'을 원한다면 무조건 서버리스(Serverless) 라인을 타야 합니다. 화면은 S3, 로직은 람다, 디비는 다이너모DB로 구성하면 우리가 직접 관리할 서버가 단 한 대도 없게 됩니다. 특히 DynamoDB 온디맨드 모드는 미리 용량을 정할 필요 없이 손님이 1만 명 오든 100만 명 오든 알아서 받아내기 때문에 이번 요구 사항에 완벽히 부합합니다. 다른 옵션인 B의 Aurora도 훌륭하지만 기본 설정이 서버리스라기보단 관리형에 가깝고, C와 D는 EC2라는 '관리해야 할 서버'가 포함되어 있어 운영 수고를 줄이고 싶다는 목표에 어긋납니다.

정답은 A입니다. 람다 함수가 우리 쪽 VPC 안의 사설망 자원(전용선 포함)을 쓰게 하려면, 먼저 람다를 VPC에 소속시켜야 합니다. 일단 VPC 일원이 되면 기존에 깔려 있는 Direct Connect나 VPN 통로를 마치 자기 집 안방 쓰듯 자연스럽게 이용해서 사내 데이터베이스까지 안전하게 도달할 수 있게 됩니다. 다른 옵션인 B는 이미 전용선이 있는데 또 길을 만드는 꼴이라 낭비이며, C는 람다를 먼저 VPC에 넣어야만 의미가 있는 조치입니다. D는 보안상 매우 위험할뿐더러 프라이빗 서브넷에 있는 DB에는 아예 접근조차 할 수 없는 방식입니다.

정답은 B입니다. ECS에서 권한 관리를 할 때 가장 중요한 원칙은 '작업(Task)' 단위로 권한을 주는 것입니다. '태스크 역할(Task Role)'을 하나 구워두고 이를 작업 정의서에 딱 적어두면, 컨테이너가 실행될 때 자동으로 필요한 권한을 부여받아 안전하게 S3에 파일을 올릴 수 있습니다. 이는 서버 전체에 권한을 주는 것보다 훨씬 안전하고 세밀한 보안 관리 방식입니다. 다른 옵션인 A는 보안 범위가 너무 넓어 위험하고, C의 보안 그룹은 '통로'만 여는 것이지 '열쇠'를 주는 것이 아닙니다. D는 아이디와 비번을 코드나 설정에 노출하게 되어 보안의 금기를 깨는 방식입니다.

정답은 B입니다. 윈도우 서버끼리 파일을 공유할 때 쓰는 표준 기술(SMB)을 AWS가 통째로 서비스화한 것이 바로 'FSx for Windows File Server'입니다. 윈도우 환경과 100% 호환되므로 기존 앱을 고칠 필요 없이 바로 연결해서 쓸 수 있고, 여러 가용 영역에 걸쳐 고가용성까지 보장하기 때문에 윈도우 마이그레이션의 필수 아이템입니다. 다른 옵션인 A는 사내망과 클라우드를 잇는 용도라 성격이 다르고, C의 EFS는 리눅스 전용이라 윈도우에서는 성능과 호환성이 크게 떨어집니다. D의 EBS Multi-Attach는 특정 타입의 초고속 디스크에서만 동작하며 윈도우 파일 시스템 수준의 공유 기능(파일 잠금 등)을 제공하지 않아 적절치 않습니다.

정답은 A와 D입니다. '수동 개입 최소화'와 '고가용성'을 달성하는 치트키는 완전 관리형 서비스를 쓰는 것입니다. DB는 알아서 백업하고 장애를 감지하는 Multi-AZ RDS에게 맡기고, 앱은 서버 사량 고민 없이 알아서 늘어나는 서버리스 엔진인 Fargate(ECS)에게 맡기면, 시스템이 폭주하거나 데이터 센터 한 곳이 무너져도 관리자가 밤잠 설칠 일 없이 안정적으로 서비스가 유지됩니다. 다른 옵션인 B는 수동으로 복제본을 관리해야 해서 힘들고, C와 E는 결국 '서버(EC2) 본체'를 우리가 관리하고 패치해야 하는 수고가 남아 있어 요구 사항을 100% 만족하지 못합니다.

정답은 A입니다. SFTP 같은 낡은 통신 규약을 최신 S3 저장소와 바로 잇고 싶을 땐 'AWS Transfer Family'가 최고의 솔루션입니다. 우리가 직접 서버를 설치하고 보안 패치를 할 필요 없이, 설정 몇 번으로 고가용성 SFTP 입구를 만들어주기 때문에 운영자의 오버헤드를 제로에 가깝게 줄여주면서도 파트너사의 요구를 완벽히 들어줄 수 있습니다. 다른 옵션인 B의 파일 게이트웨이는 사내망 컴퓨터가 S3를 하드디스크처럼 쓸 때 쓰는 용도이며, C와 D는 서버를 직접 관리하고 패치해야 하는 노가다가 뒤따르기 때문에 운영 효율성이 매우 낮습니다.

정답은 B와 D입니다. 절대로 지워지면 안 되는 강력한 금지령을 내리려면 S3 Object Lock의 '규정 준수(Compliance) 모드'가 필수입니다. 이 설정은 루트 계정조차도 잠금을 풀 수 없게 만들어버리거든요. 여기에 우리가 직접 관리하고 세밀하게 설정할 수 있는 'KMS 고객 관리형 키'를 쓰면서 '자동 순환' 옵션을 체크해두면, 보안 규정을 100% 충실히 이행하는 철통 보안 시스템이 완성됩니다. 다른 옵션인 A는 권한이 있으면 지울 수 있어서 위험하고, C의 SSE-S3는 키 관리가 너무 단순해서 매년 자동 교체되는지 제어하기 어렵습니다. E는 사람이 수동으로 키를 갈아줘야 해서 운영 부담이 크고 실수의 위험이 있습니다.

정답은 B입니다. 기존의 Java/PHP 코드를 거의 고치지 않으면서도 클라우드의 자동화 혜택을 다 누리고 싶을 땐 'Elastic Beanstalk'가 딱입니다. 이 서비스는 서버 구성부터 부하 분산, 자동 확장까지 다 알아서 해주며, 특히 새 기능을 테스트할 때 현재 서버와 새 서버의 주소만 슥 바구는 'URL 스와핑' 기능을 지원해서 위험 부담 없이 자주 배포하고 실험하기에 최적입니다. 다른 옵션인 A는 코드를 통째로 다시 짜야 하는 대공사가 필요하고, C와 D는 서버 한 대 한 대를 우리가 직접 관리하고 조율해야 해서 운영자의 다크서클이 깊어지는 비효율적인 방식입니다.

정답은 A입니다. 가장 확실하고 간단한 해결책은 '일하는 곳과 보고서 뽑는 곳'을 물리적으로 떼어놓는 것입니다. 원본 DB의 내용을 실시간으로 복사해가는 '읽기 전용 복제본'을 하나 만들어주고 무거운 쿼리는 그쪽에서만 돌리게 하면, 메인 DB의 CPU는 고객 주문 처리에만 집중할 수 있게 되어 타임아웃 문제가 눈 녹듯 사라집니다. 다른 옵션인 B는 복제본에 부하가 걸리면 여전히 주문 처리에 지장을 줄 수 있고, C는 시스템을 뜯어고치는 수준의 대공사라 위험합니다. D는 직원들의 업무 효율을 깎아먹는 임시방편일 뿐 근본적인 기술 해결책이 아닙니다.

정답은 B와 E입니다. 병원 노가다를 줄이려면 AI와 서버리스를 제대로 써야 합니다. 먼저 Textract라는 AI가 스캔 이미지에서 글자를 긁어모으고, Comprehend Medical이라는 전문가 AI가 그 안에서 처방전이나 병명 같은 핵심 의료 데이터를 콕 집어 추출하게 만듭니다. 이렇게 뽑은 데이터를 S3에 쌓아두면, 서버 한 대 없이도 SQL로 즉시 검색 가능한 Athena가 환상적인 데이터 분석 환경을 완성해줍니다. 다른 옵션인 A와 C는 직접 서버를 관리하고 앱을 짜야 해서 운영 부담이 크고, D의 Rekognition은 일반 사진 분석용이지 문서 글자 추출이나 의료 전문 용어를 이해하는 데는 적합하지 않습니다.

정답은 A입니다. 데이터베이스 자체의 읽기 부하를 정공법으로 해결하는 방법은 '읽기 전용 복제본'을 늘리는 것입니다. 조화 전용 비서(복제본)를 여러 명 두면 원본 DB는 중요한 기록 작업에만 집중할 수 있고, 혹시 하나가 고장 나더라도 다른 비서가 즉시 업무를 대신할 수 있어 읽기 성능 향상과 고가용성이라는 두 마리 토끼를 가장 깔끔하게 잡을 수 있습니다. 다른 옵션인 B와 D의 캐싱도 훌륭하지만, 이를 적용하려면 앱 코드를 상당 부분 뜯어고쳐야 하므로 즉각적인 대응으로는 복제본 추가가 훨씬 빠르고 확실합니다. C의 DNS 캐싱은 도메인 주소 찾는 속도만 높일 뿐 DB 안의 데이터 읽기 부하와는 무관합니다.

정답은 A입니다. EC2에서 돌아가는 DB를 고가용성으로 만드는 정석은 '다중 AZ 클러스터' 구성입니다. 물리적으로 떨어진 두 데이터 센터(AZ)에 서버를 각각 두고, 데이터가 들어올 때마다 양쪽에 똑같이 기록되게(복제) 설정한 뒤 한쪽이 죽으면 나머지 한쪽이 즉시 주인공이 되도록 묶어주는 것이 가장 확실한 생존 전략입니다. 다른 옵션인 B와 D는 서버가 새로 켜질 때까지 한동안 서비스가 멈추는 '다운타임'을 피할 수 없어 고가용성이라 부르기 부족하며, C는 리전 간 통신 속도가 느려 실시간 복제가 힘들뿐더러 '자동 장애 조치'가 안 되어 관리자가 직접 뛰어야 하는 불편함이 있습니다.

정답은 C입니다. 시스템 장애에도 굴하지 않는 맷집을 키우는 최고의 무기는 'SQS(메시지 대기열)'입니다. 주문이 들어오는 즉시 SQS라는 튼튼한 바구니에 담아두면, 서버가 잠시 고장 나서 고치고 오는 동안에도 주문은 그 안에서 얌전히 기다립니다. 서버가 다시 살아나서 바구니를 확인하면 밀려있던 일을 하나씩 처리할 수 있어, 주문 유실 없이 탄력적인 운영이 가능해집니다. 다른 옵션인 A와 B는 서버의 건강 상태만 챙길 뿐 이미 날아간 '데이터'를 살려주지는 못하며, D는 소식만 전할 뿐이지 실제 데이터를 안전하게 보관해주는 역할과는 거리가 멉니다.

정답은 D입니다. 데이터에 '수명'을 부여하는 자동 기능인 'TTL(Time to Live)'이 이번 문제의 정답입니다. 항목을 만들 때 30일 뒤의 날짜를 딱 적어주면, DynamoDB가 알아서 시계를 보다가 시간이 지난 데이터들을 별도의 비용이나 개발 노력 없이 공짜로 슥 지워주기 때문에 지갑도 지키고 개발자의 주말도 지켜주는 아주 고마운 기능입니다. 다른 옵션인 A는 서비스 중단 위험이 있고, B와 C는 지우는 데 드는 비용(쓰기 용량)과 개발 수고가 발생하여 '비용과 노력 최소화'라는 요구 사항에 정면으로 어긋나는 구식 방식입니다.

정답은 B와 E입니다. 기존 환경을 최대한 유지하면서(최소한의 개발 변경) 클라우드의 혜택만 쏙쏙 빼먹는 최고의 조합입니다. 앱은 코드 변경 없이 바로 받아주는 Elastic Beanstalk에게 맡기고, 데이터베이스는 쓰던 엔진 그대로인 RDS for Oracle로 옮기면 됩니다. 둘 다 클릭 몇 번으로 '다중 AZ' 고가용성 설정을 할 수 있어, 운영 부담은 줄이고 안정성은 최고로 높이는 깔끔한 이사 전략이 완성됩니다. 다른 옵션인 A와 C, D는 코드를 처음부터 다시 짜거나 데이터 구조를 통째로 뒤흔드는 큰 공사가 필요해서 '개발 변경 최소화'라는 약속을 지킬 수 없게 됩니다.

정답은 D입니다. 기존의 쿠버네티스(K8s)와 몽고DB 환경을 '코드 수정 없이' 옮기는 가장 영리한 방법입니다. 컴퓨팅 엔진은 K8s의 AWS 버전인 EKS를 쓰되 서버 관리가 필요 없는 Fargate를 선택하고, 데이터베이스는 몽고DB와 대화 방식이 똑같은 DocumentDB를 고르면 됩니다. 이렇게 하면 겉모양은 그대로 유지하면서 운영의 고통에서만 해방되는 최고의 결과를 얻을 수 있습니다. 다른 옵션인 B와 C는 몽고DB와 데이터 담는 방식이 아예 다른 DynamoDB를 쓰라고 해서 대규모 코드 수정이 필수적이며, A는 서버 관리라는 지옥에서 벗어날 수 없는 구식 방식입니다.

정답은 B입니다. 음성을 텍스트로 바꾸는 일에는 'Transcribe'가 세계 최고의 전문가입니다. 심지어 화자 분리(SpeakerID) 기능까지 있어서 누가 무슨 말을 했는지도 정확히 가려냅니다. 이렇게 뽑아낸 대본들을 S3 저장소에 잘 쌓아두면, 원할 때마다 Athena라는 돋보기를 통해 SQL 문법으로 대본 구석구석을 순식간에 검색해 비즈니스 인사이트를 얻을 수 있습니다. 다른 옵션인 A와 D의 Rekognition은 이미지/영상 전문이라 소리를 못 들으며, C의 Translate는 번역 서비스라 말소리를 글자로 적는 이번 업무와는 핀트가 어긋납니다.

정답은 D입니다. 이미 Cognito 회원 정보를 가지고 있다면, API Gateway와 한 몸처럼 연결되는 'Cognito 권한 부여기(Authorizer)' 기능을 켜기만 하면 됩니다. 복잡한 코딩 한 줄 없이 설정 몇 번으로 로그인한 사람의 신분증(토큰)을 검사해서 문(API)을 열어주기 때문에, 보안은 완벽하게 챙기면서 운영 오버헤드는 획기적으로 줄일 수 있습니다. 다른 옵션인 A, B, C는 개발자가 직접 보안 로직을 코딩해야 해서 버그가 생길 위험도 크고, 관리해야 할 코드가 늘어나는 비효율적인 방식이기에 정답에서 멀어집니다.