AWS SAA C03 연습 문제 (126~150번)

정답은 B입니다. 이 문제의 핵심은 최근 2년 데이터의 가용성과 즉시 검색 조건을 지키면서 장기 보관 비용을 줄이는 것입니다. 2년 동안은 S3 Standard의 높은 가용성을 유지하며 즉각적인 접근을 보장하고, 그 이후에 가장 저렴한 보관 등급인 S3 Glacier Deep Archive로 옮기는 것이 가장 경제적이고 효율적인 설계입니다. 다른 옵션인 A와 D는 처음부터 데이터 접근을 제한하거나 가용성이 낮은 등급으로 보내기 때문에 조건에 맞지 않으며, C의 경우에는 데이터 접근 패턴을 이미 명확하게 알고 있는 상태이므로 굳이 지능형 계층화를 사용할 필요가 없어 효율이 떨어집니다.

정답은 D입니다. 비디오 처리와 같은 고성능 작업에는 네트워크를 거치지 않고 서버 본체에 직접 연결된 EC2 인스턴스 스토어가 최적의 I/O 성능을 제공합니다. 또한 300TB 규모의 미디어 파일은 뛰어난 내구성을 가진 S3에 보관하고, 900TB에 달하는 대규모 아카이브는 비용 최적화를 위해 Glacier에 저장하는 것이 가장 합리적인 서비스 세트입니다. 다른 옵션인 A와 B는 인스턴스 스토어보다 성능이 낮은 EBS를 사용하고 있으며, C의 경우 300TB라는 대용량 데이터를 저장하기에는 EFS보다 S3를 사용하는 것이 비용과 관리 측면에서 훨씬 유리하기 때문에 제외됩니다.

정답은 B입니다. 운영 오버헤드를 최소화하기 위해 AWS가 노드 관리를 대신 해주는 EKS 관리형 노드 그룹을 선택하는 것이 최선이며, 상태 비저장이고 중단이 허용되는 애플리케이션 특성상 비용을 최대 90%까지 절감할 수 있는 스팟 인스턴스를 결합하는 것이 가장 효율적입니다. 다른 옵션인 A와 C는 직접 서버 인프라를 관리해야 하는 부담이 있어 운영 오버헤드가 발생하며, D의 경우에는 온디맨드 인스턴스를 사용하여 비용 절감 효과를 충분히 누릴 수 없기 때문에 최적의 답이 아닙니다.

정답은 A와 E입니다. 인프라 관리 부담을 줄이기 위해서는 서버를 직접 관리하지 않는 완전 관리형 또는 서버리스 서비스를 활용해야 합니다. 성능이 뛰어나고 자동 관리를 제공하는 Aurora DB로 마이그레이션하고, 웹 앱은 서버 인프라 고민 없이 컨테이너를 실행할 수 있는 Fargate 기반의 ECS를 사용하면 운영 오버헤드를 획기적으로 낮출 수 있습니다. 다른 옵션인 B는 여전히 서버 한 대씩을 직접 관리해야 하므로 운영 부담이 남으며, C와 D는 시스템 성능이나 전달 속도를 개선할 수 있는 서비스이지만 현재의 핵심 요구 사항인 인프라 관리 부담 감소와는 직접적인 관련이 적습니다.

정답은 B입니다. CPU 사용률 40%와 같이 특정 목표 수치를 일정하게 지키고 싶을 때는 대상 추적 정책이 가장 효과적입니다. 이 정책은 목표 수치를 기준으로 부하가 몰리면 서버를 늘리고, 한산해지면 서버를 줄여서 항상 사용자가 원하는 성능 수준을 정교하게 유지해줍니다. 다른 옵션인 A의 간단한 확장 정책은 기준이 정적이어서 세밀한 유지가 어렵고, C와 D의 경우 수동 코딩이나 시간 기반 예약 방식이어서 불규칙한 실시간 트래픽 패턴에 유연하게 대응하기에는 부족함이 있습니다.

정답은 D입니다. S3 버킷에 대한 직접적인 외부 접근을 막고 반드시 CloudFront라는 정해진 입구를 통해서만 파일을 받게 하려면 원본 액세스 제어(OAC)가 필수적입니다. 이를 통해 S3 버킷은 오직 CloudFront의 요청만 수락하도록 설정하여 데이터 보안을 강화할 수 있습니다. 다른 옵션인 A와 C는 CloudFront의 특정 식별자를 활용하기에 한계가 있으며, B의 경우에는 개별 사용자 권한 관리가 복잡해지고 효율적인 서비스 제공에 적합한 구조가 아니기 때문에 사용하지 않습니다.

정답은 A입니다. 전 세계 어디서든 가장 빠른 응답 속도를 보여주기 위해서는 콘텐츠를 최종 사용자와 가까운 곳에서 제공하는 CloudFront가 핵심입니다. 여기에 파일을 보관하는 S3를 연결하면 서버 관리에 대한 고민 없이 저렴한 비용으로 수많은 다운로드 요청을 안정적으로 처리할 수 있습니다. 다른 옵션인 B는 데이터 분석이나 연산 중심의 작업에 적합하고, C와 D는 서버를 직접 구축하고 관리해야 하는 부분이 있어 프로비저닝 제한과 비용 절감 측면에서 정답보다 효율이 떨어집니다.

정답은 C입니다. 운영 부담을 줄이는 관리형 서비스(RDS)의 이점을 누리면서도 OS에 직접 접속해야 하는 특별한 요구 사항이 있을 때는 RDS Custom 모델이 최상의 선택입니다. 이를 통해 타 리전에 읽기 복제본까지 갖추면 재해 복구 준비와 OS 관리 권한을 동시에 확보할 수 있습니다. 다른 옵션인 A는 서버를 처음부터 끝까지 직접 관리해야 하므로 운영 오버헤드가 너무 크며, B와 D의 일반적인 RDS 모델은 운영 체제 수준의 액세스를 허용하지 않기 때문에 요구 사항을 충족할 수 없습니다.

정답은 C입니다. 운영 부담을 가장 줄이는 열쇠는 관리형 암호화(SSE-S3)와 서버리스 쿼리 도구(Athena)를 사용하는 것입니다. 기존 버킷의 데이터를 그대로 유지하면서 리전 간 복제(CRR)를 활성화하면, 별도의 인프라 관리 없이도 데이터 보호와 가용성 확보, 그리고 데이터 분석까지 원스톱으로 해결됩니다. 다른 옵션인 A와 B는 키 관리 부담이 있는 KMS를 사용하여 운영 오버헤드가 더 높으며, B와 D에서 언급한 RDS는 데이터를 옮겨 담는 추가 과정이 필요하여 실시간 S3 데이터 쿼리에는 Athena보다 비효율적입니다.

정답은 D입니다. '특정 서비스'에만 안전하게 닿으려면 AWS PrivateLink를 이용하는 것이 정답입니다. 공급자 측에서 전용 엔드포인트를 열어주면 우리 쪽에서는 우리 네트워크 안의 주소를 사용하는 것처럼 인터넷 노출 없이 프라이빗하게 통신할 수 있으며, 연결의 주도권도 우리가 가질 수 있습니다. 다른 옵션인 A의 VPC 피어링은 두 네트워크를 통째로 잇는 것이라 보안 범위가 너무 넓고, C의 NAT 게이트웨이는 결국 인터넷을 타고 나가는 방식이라 비공개 연결이라는 원칙에 어긋납니다.

정답은 A와 C입니다. 서비스 중단 없이 데이터를 옮기기 위해서는 전문 이사 장비인 DMS 복제 서버를 준비해야 합니다. 이 서버를 통해 초기 이사뿐만 아니라 실시간으로 발생하는 데이터의 변화를 즉시 추적하여 반영하는 '지속적인 복제' 작업을 실행해야만 두 데이터베이스가 한 몸처럼 동기화된 상태를 유지할 수 있습니다. 다른 옵션인 B는 정적인 스냅샷이라 실시간 동기화가 불가능하고, D의 스키마 변환(SCT)은 언어가 다른 DB끼리 이사할 때 쓰는 도구로, 지금 같은 PostgreSQL 간의 이동 후 실시간 동기화 작업과는 직접적인 거리가 있습니다.

정답은 B입니다. 루트 이메일을 개인 메일이 아닌 소수 정예 관리자 그룹의 공용 메일함(배포 목록)으로 설정하는 것이 가장 안전합니다. 여기에 Organizations 콘솔에서 '대체 연락처' 정보를 최신화해두면, 긴급 보안 소식이나 결제 정보가 담당자들에게 직접 발송되므로 개인의 부재와 상관없이 회사는 중요한 소식을 정확히 받아볼 수 있습니다. 다른 옵션인 A는 모든 사용자에게 민감한 정보가 노출되는 보안 문제가 있으며, C와 D는 여전히 한 사람에게 의존하거나 기존의 비효율적인 방식을 답습하여 다시 알림을 놓칠 위험을 해결하지 못합니다.

정답은 B입니다. 고가용성을 위해서는 단일 실패 지점을 없애야 합니다. RabbitMQ는 직접 서버를 관리할 필요 없는 Amazon MQ로 옮겨서 활성/대기 쌍을 구축하고, 데이터베이스는 RDS 다중 AZ 배포를 사용하여 한 곳이 무너져도 서비스가 계속되게 해야 합니다. 이렇게 관리형 서비스를 쓰면 운영 수고는 덜고 성능과 안전성은 월등히 높아집니다. 다른 옵션인 A, C, D는 여전히 데이터베이스나 대기열 시스템 서버를 직접 관리해야 하는 운영 부담이 크게 남아 있어 '운영 오버헤드 최소화'라는 회사의 목표를 완벽히 달성하기에 부족합니다.

정답은 D입니다. 파일 이사는 S3 자체의 복제(Replication) 기능을 켜는 것이 코딩 한 줄 없이 해결할 수 있는 가장 우아한 방법입니다. 이후 복사가 완료된 시점에 EventBridge라는 신호수를 통해 Lambda와 AI 엔진인 SageMaker를 동시에 호출하여 다음 단계를 밟게 하면, 사람이 일일이 감시하지 않아도 모든 데이터 처리가 물 흐르듯 자동으로 이루어집니다. 다른 옵션인 A와 B는 굳이 필요 없는 파일 복사용 Lambda를 따로 코딩해야 해서 관리 부담이 늘어나며, C의 경우 S3 기본 알림만으로는 여러 대상을 동시에 호출하거나 복잡한 워크플로를 관리하기에 한계가 있어 적절치 않습니다.

정답은 A와 C입니다. 언제든 중단되어도 괜찮은 불규칙한 작업에는 헐값에 빌려 쓰는 스팟 인스턴스가 비용 면에서 무조건 압승입니다. 반면 1년 내내 안정적으로 사용될 Fargate와 Lambda 같은 자원은 Compute Savings Plan으로 약정 할인을 받는 것이 영리합니다. 이 요금제는 서버 종류와 상관없이 컴퓨팅 사용량에 대해 범용적으로 할인을 해주기 때문입니다. 다른 옵션인 B는 정가를 다 내야 해서 비싸고, D와 E의 경우에는 서버 사양이 고정되거나 유연성이 떨어져서, 서버리스 자원들이 섞여 있는 현재의 아키텍처에서 전체적인 비용을 최적화하기에는 부족함이 있습니다.

정답은 A입니다. CloudFront를 단순히 사진 배달용으로만 알면 안 됩니다. ALB 앞에 CloudFront를 세우면, 전 세계 사용자 근처에 있는 거점(Edge)을 통해 서버로 오는 통로를 최적화해줍니다. 동적 데이터도 AWS의 전용 고속도로를 타고 오기 때문에 전 세계 사용자에게 훨씬 쾌적한 반응 속도를 보장할 수 있는 가장 경제적이고 빠른 길입니다. 다른 옵션인 B와 D는 서버를 여러 나라에 직접 구축해야 해서 비용이 너무 많이 들고 관리도 복잡해지며, C의 경우에는 동적 데이터가 일반 공중망 인터넷을 타고 와야 해서 응답 속도 최적화 효과를 절반밖에 누리지 못합니다.

정답은 C입니다. 게임 서버처럼 UDP 통신이 필수고 전 세계에 고정된 IP 주소를 입구로 딱 걸어두고 싶다면 'Global Accelerator'가 유일한 해답입니다. 이 서비스는 전 세계 사용자를 가깝고 안전한 AWS 전용망 입구로 안내하여 패킷 손실을 최소화하고 핑(Ping)을 안정적으로 잡아주는 게임 서비스의 필수 아이템입니다. 다른 옵션인 A와 D가 사용하는 ALB나 API Gateway는 UDP를 지원하지 않아 애초에 탈락이며, B의 CloudFront 역시 주로 HTTP 기반 콘텐츠 전달용이라 게임 같은 UDP 기반 실시간 통신 환경에는 Global Accelerator보다 성능이나 기능 면에서 적합하지 않습니다.

정답은 D입니다. 기존 앱의 덩치를 줄이고 독립적인 서비스로 나누는 데는 '컨테이너(Docker)'가 가장 현실적이고 강력한 도구이며, 이를 관리하는 ECS는 확장성과 운영 효율성 면에서 탁월합니다. 팀별로 자신의 코드를 컨테이너에 담아 올리기만 하면 부하에 따라 대수가 자동 조절되므로, 낡은 앱을 현대적인 시스템으로 변신시키는 데 가장 적합합니다. 다른 옵션인 A와 B의 Lambda는 기존 코드를 완전히 새로 짜야 하는 부담이 너무 커서 부적절하며, C의 경우에는 여전히 서버 한 대 한 대를 관리해야 하는 낡은 방식을 유지하게 되어 관리 효율을 높이기는 어렵습니다.

정답은 B입니다. 메인 DB에서 보고서를 돌리는 건 영업시간에 창고 조사를 하는 것과 같아요. 이럴 때 '읽기 전용 복제본'을 하나 만들면 메인 DB에 전혀 방해를 주지 않고도 무거운 조회 작업을 공짜 같은 비용으로 쾌적하게 끝낼 수 있습니다. 메인 DB 사량을 높이는 것보다 훨씬 싸고 효과적이지요. 다른 옵션인 A의 Redshift는 너무 거창한 데이터 분석실이라 구축 비용이 많이 들고, C와 D는 DB 전체 사량을 높이는 거라 한 달에 한 번 있는 보고서 작업 때문에 평소에도 비싼 값을 지불해야 하는 낭비가 발생합니다.

정답은 D입니다. 가장 현대적이고 알뜰한 해결책은 '나누고 자동화하기'입니다. DB는 알아서 커지는 Aurora로 옮기고, 웹서버는 'Auto Scaling'이라는 자동 조절기에게 맡겨야 합니다. 특히 서버 대수를 늘릴 때 정가보다 훨씬 저렴한 '스팟 인스턴스'를 섞어 쓰면, 부하는 부하대로 잡으면서 지갑은 아주 두툼하게 지킬 수 있습니다. 다른 옵션인 A와 B는 서버 대수를 수동으로 늘릴 뿐이라 유연한 자동 확장이 안 되고, C의 경우는 서버 사량을 키웠다 단축하는 과정에서 서비스 중단이 발생할 수 있어 고가용성 원칙에 어긋납니다.

정답은 B입니다. 365일 24시간 일정하게 돌아가는 기본 체력은 무조건 선불 할인을 받는 '예약 인스턴스'로 준비하는 게 가장 저렴합니다. 그리고 낮 시간에만 잠깐 더 필요한 추가 서버들은 70~90% 할인되는 '스팟 인스턴스'를 동원하면 됩니다. 이렇게 하면 튼튼한 하체와 날렵한 몸집을 동시에 갖춘 아주 경제적인 시스템이 완성됩니다. 다른 옵션인 A는 서버가 갑자기 다 꺼질 위험이 있어 불안하고, C와 D는 기본 서버를 정가나 그보다 비싼 전용 요금제로 쓰게 되어 비용 절감이라는 핵심 목표 수준에 한참 못 미치게 됩니다.

정답은 B입니다. S3에 로그를 보관하면서 '한 달 지나면 제일 싼 Deep Archive 방으로 치워줘'라는 수명 주기(Lifecycle) 정책을 한 번만 걸어두면 됩니다. 이 기능은 AWS가 알아서 파일을 감시하다가 조건이 맞으면 가장 구석진 저장소로 옮겨주기 때문에, 관리 운영 리소스를 전혀 쓰지 않으면서 보관 비용을 수백 배 아낄 수 있습니다. 다른 옵션인 A의 AWS Backup은 보통 DB 전체를 살릴 때 쓰는 큰 도구라 지금 같은 파일 한 장 한 장 관리에는 과하고, C와 D의 CloudWatch Logs는 장기 보관용 장소가 아니라 수집 분석실이라 보관료가 비쌉니다.

정답은 D입니다. 일이 가끔 터지는 걸 막을 수 없다면 '재도전 바구니(SQS)'를 옆에 두면 됩니다. 사고가 나서 처리가 안 된 데이터들을 이 바구니에 담아두도록(장애 시 대상) 설정하면, Lambda가 여유가 생겼을 때나 네트워크가 다시 붙었을 때 다시 꺼내서 일할 수 있습니다. 이렇게 하면 어떤 정보도 중간에 유실되지 않는 끈기 있는 시스템이 됩니다. 다른 옵션인 A와 B는 서버 사양만 높이는 거라 네트워크 중단 앞에서 무력하며, C의 재시도 전략은 일정 횟수 이상 실패하면 결국 데이터를 포기하고 삭제해 버리기 때문에 수동 작업을 없앨 완벽한 해결책이 못 됩니다.

정답은 A입니다. 순서가 생명일 땐 'FIFO(First-In-First-Out)'라는 전용 번호표 기계를 들여놔야 합니다. SQS FIFO 대기열을 쓰면 도중에 섞이는 일 없이 1번으로 들어온 데이터가 무조건 1번으로 나가서 Lambda에 전달됩니다. AWS가 알아서 순서를 지켜주니 개발자가 따로 순서 제어 코드를 짤 필요가 없어 운영이 매우 편해집니다. 다른 옵션인 B와 C는 순서 보장이 안 되는 방송이나 일반 대기열 방식이라 위험하며, D의 경우에는 복잡한 구조만 만들었을 뿐이지 실제로 데이터가 순서대로 '처리'되게 만드는 핵심 장치는 빠져 있습니다.

정답은 A입니다. 여러 가지 조건이 동시에 맞을 때만 작동하는 '복합 경보'가 정답입니다. CPU 전담 감시원과 하드디스크 전담 감시원이 둘 다 '위험!' 깃발을 들 때만 진짜 사이렌을 울리도록 논리적으로 묶어두면, 사소한 일로 밤새 전화받는 피로도를 확 낮추면서도 진짜 위기는 절대 놓치지 않는 스마트한 방어막이 됩니다. 다른 옵션인 B는 사람이 눈으로 계속 보고 있어야 해서 피곤하고, C는 사용자의 접속 여부만 체크하는 데 적합하며, D의 기술은 지표 하나에만 집중하는 것이라 여러 지표의 상관관계를 따지는 현재 요구 사항에는 맞지 않습니다.