AWS SAA C03 연습 문제 (426~450번)

정답은 A입니다. 온프레미스 NAS나 서버의 데이터를 S3로 대량 복사할 때 가장 효율적인 도구는 AWS DataSync입니다. 전송 중 암호화와 무결성 검사까지 해주니 믿고 쓸 수 있죠. 그리고 '데이터의 모든 수준에서 감사 액세스'가 필요하다면, 단순히 누가 로그인했는지만 보는 게 아니라 실제 데이터에 누가 손을 댔는지 기록하는 CloudTrail의 '데이터 이벤트(Data Events)' 로깅 기능을 활성화해야 합니다. 다른 옵션인 B와 D는 '관리 이벤트'만 기록해서는 규정 준수가 어렵고, C는 이미 네트워크 속도가 느린 온프레미스 환경에서는 큰 효과를 보기 어렵습니다.

정답은 B입니다. Java와 Tomcat 처럼 정해진 환경(플랫폼)이 필요한 앱을 가장 편하게 배포하는 방법은 Elastic Beanstalk입니다. 코드만 업로드하면 서버(EC2), 로드 밸런서(ALB), 자동 확장(Auto Scaling) 설정을 AWS가 알아서 다 해줍니다. 특히 '롤링 업데이트'를 쓰면 서비스 중단 없이 새 버전을 배포할 수 있어 운영 편의성과 고가용성을 한 번에 잡을 수 있습니다. 다른 옵션인 A(Lambda)는 기존 Java 앱을 서버리스용으로 뜯어고치는 공사가 너무 크고, D는 모든 패치와 관리를 직접 해야 하므로 운영 오버헤드가 큽니다.

정답은 B입니다. AWS에서는 서비스 간의 권한 부여에 '열쇠(Key)'를 주고받지 않습니다. 대신 '역할(Role)'이라는 가상 신분증을 활용합니다. Lambda가 실행될 때 착용할 '실행 역할(Execution Role)'에 DynamoDB 권한을 넣어주면, AWS 내부망 안에서 별도의 비밀번호 없이도 안전하게 대화할 수 있습니다. 이것이 보안 사고를 원천 봉쇄하는 가장 강력한 보안 모범 사례입니다. 다른 옵션인 A와 C는 결국 '비밀번호(Key)'를 어디엔가 저장해야 한다는 약점이 있어 보안상 덜 안전합니다.

정답은 D입니다. AWS 정책에서 'Explicit Deny(명시적 거부)'는 모든 허용을 이깁니다. 이 정책은 서버를 끄거나 삭제하는(Stop/Terminate) 위험한 작업에 대해서만 'MFA가 없다면 무조건 거부'라는 자물쇠를 채워둔 것입니다. 따라서 일반적인 서버 목록 조회나 생성 같은 작업은 평소대로 할 수 있지만, 서버의 생사가 걸린 중요한 명령을 내릴 때만 MFA 인증을 요구하게 됩니다. 다른 옵션인 A는 거부 정책의 강력함을 무시한 것이고, B는 모든 권한이 아닌 특정 위험 작업만 거부한다는 점을 간과했습니다.

정답은 B와 C입니다. 먼저 '즉시 변환'에는 서버를 띄울 필요 없이 파일이 오자마자 실행되는 Lambda(B)가 최적입니다. 그 후 저장 비용을 아끼는 게 핵심인데, 자주 안 보는 원본 CSV는 하루만 Standard에 뒀다가 가장 저렴한 창고인 Glacier(C)로 보내버리세요. AI 훈련은 미리 계획되니까 Glacier의 인출 시간(수 분~수 시간)은 문제가 안 되거든요. 이미지는 유효 기간이 한 달이니 30일 자동 삭제를 걸면 아주 깔끔합니다. 다른 옵션인 A는 서버 유지비가 아깝고, D(One Zone-IA)는 데이터 유실 위험이 있어 중요한 원본 저장용으로는 부적합합니다.

정답은 B입니다. 실시간 게임의 순위판(리더보드) 하면 무조건 Redis입니다. Redis는 'Sorted Set'이라는 천재적인 기능을 가지고 있어 점수만 넣으면 실시간으로 순위를 매겨줍니다. 게다가 하드디스크가 아닌 메모리에서 동작하니 응답 속도가 1밀리초도 안 걸릴 만큼 빠르죠. 또한 스냅샷 기능을 통해 데이터를 안전하게 보관하고 복원할 수도 있어 게임 앱에 가장 완벽한 짝꿍입니다. 다른 옵션인 A(Memcached)는 데이터 정렬 기능이나 저장 기능이 부족하고, D는 DB 부하가 심해 실시간 리더보드용으로는 너무 무겁습니다.

정답은 B입니다. 현대적인 AI/BI 워크플로의 정석입니다. 기계 학습 모델을 만들고 훈련하는 일은 SageMaker가 가장 잘하고, 그렇게 분석된 결과를 멋진 그래프와 대시보드로 뽑아내는 건 QuickSight가 전문가입니다. 두 서비스는 서로 아주 친하게 연결되어 있어, 클릭 몇 번으로 ML 분석 결과를 경영진을 위한 리포트로 변신시킬 수 있습니다. 다른 옵션인 A와 C는 직접 서버를 관리하거나 복잡한 설정을 해야 하는 수고가 훨씬 많이 들어서 '운영 오버헤드 최소화' 조건에 안 보입니다.

정답은 C입니다. 여러 계정을 관리하는 Organizations 환경에서 '절대 넘지 말아야 할 선'을 정하는 마스터키는 SCP입니다. SCP를 통해 \\\\\\\"부여된 특정 관리자 외에는 누구도 태그를 수정할 수 없다\\\\\\\"라고 박아버리면, 개별 계정의 관리자라 할지라도 이 철벽 정책을 뚫을 수 없습니다. 사후 약방문식의 알람(A, B, D)보다 훨씬 확실한 예방책입니다. 다른 옵션들은 이미 규정이 어겨진 뒤에 수습하는 것이라 '수정 방지'라는 목적 달성에는 SCP보다 약합니다.

정답은 A입니다. '다운타임 최소화(가용성 극대화)'의 핵심은 이미 준비된 상태로 대기하는 'Active-Passive' 혹은 'Active-Active' 구조입니다. DynamoDB 전역 테이블을 쓰면 두 리전의 데이터가 실시간으로 똑같아지며, Route 53의 상태 확인(Health Check)과 장애 조치(Failover) 설정을 통해 메인 리전이 죽는 즉시 전 세계 트래픽을 보조 리전으로 자동으로 돌릴 수 있습니다. 이것이 가장 우아하고 빠른 재해 복구 방식입니다. 다른 옵션인 B와 C는 장애가 터진 후에야 서버를 올리는 식이라 로딩 속도가 느리고 서비스 중단 시간이 수 분에서 수 시간까지 발생할 수 있습니다.

정답은 A입니다. 20TB는 네트워크로 보내기엔 꽤 큰 양이고, 2주는 넉넉한 시간이 아닙니다. 이럴 땐 물리적으로 장비를 택배로 주고받는 Snowball Edge가 가장 확실하고 알뜰합니다. 기기에 전체 데이터를 한 번 담아 보내면(Full Load), 전송되는 며칠 동안 새로 생긴 데이터들만 DMS가 네트워크를 통해 쫄쫄쫄 실시간 복제(CDC)해주면 됩니다. 그러면 마지막에 스위치만 탁 끄고 AWS 쪽으로 넘어가면 끝이죠. 다른 옵션인 B(Snowmobile)는 보통 엑사바이트(EB)급 초대형 데이터용이고, D는 전용선 설치에만 수개월이 걸려 기간 내에 불가능합니다.

정답은 A입니다. 성능은 모자라고 돈은 아끼고 싶다면 우선 '결제 방식'부터 손보는 게 순서입니다. 1~3년 장기 사용을 약속하는 예약 인스턴스(RI)를 사면 요금이 최대 70%까지 할인됩니다. 이렇게 아낀 돈으로 DB 서버의 사양을 더 큰 것으로(Scale-up) 올려 사용하면, 인프라의 복잡한 구조 변경 없이도 강력한 힘을 발휘할 수 있습니다. 다른 옵션인 B(다중 AZ)는 장애 대비용이라 평소 성능과는 상관없고, D(온디맨드)는 가장 비싼 방식이라 비용 절감과는 거리가 멉니다.

정답은 B입니다. 범인이 IP 주소를 바꿔가며 공격해도 '너무 자주 들어온다'는 특징은 숨길 수 없습니다. WAF의 속도 기반(Rate-based) 규칙은 \\\\\\\"어떤 손님이든 5분 동안 2,000번 넘게 호출하면 차단해!\\\\\\\"라고 규칙을 정해두면 알아서 범인을 걸러줍니다. 쾌적한 쇼핑몰을 유지하면서 공격자만 쏙쏙 골라내는 가장 세련된 방패입니다. 다른 옵션인 C(ACL)는 범인이 IP를 바꿀 때마다 사람이 24시간 대기하며 새로 적어야 하므로 불가능에 가깝고, A(Inspector)는 서버 설정의 구멍을 찾는 것이지 실시간 공격을 막는 도구는 아닙니다.

정답은 D입니다. 클라우드에서 데이터를 건네줄 때는 '물리적 전달'이 아니라 '권한 부여'를 이용합니다. DB를 통째로 복사한 스냅샷을 만든 뒤, 운영팀 계정에서 감사팀 계정 번호로 \\\\\\\"이 스냅샷 보게 해줄게\\\\\\\"라고 권한을 넘기는 것이죠. 단, 암호화된 스냅샷은 암호를 푸는 키(KMS) 권한도 함께 줘야 감사팀 리전에서 정상적으로 복원할 수 있습니다. 이것이 계정 간 데이터 이동의 정석입니다. 다른 옵션인 C는 우리 회사 마스터 키를 넘기는 위험천만할 짓이고, A는 라이브 DB에 직접 접속하게 하는 것이라 보안상 위험합니다.

정답은 A입니다. 인터넷 주소(IP)가 부족할 때 집을 새로 지을(VPC 이사) 필요는 없습니다. 그냥 거실을 하나 더 넓히듯이 기존 VPC에 추가적인 IP 대역(Secondary CIDR)을 붙여주기만 하면 됩니다. 그러면 기존 서버들은 그대로 가동하면서, 넓어진 새 공간에 새로운 서버들을 넉넉히 배치할 수 있습니다. 관리 효율 면에서도 이보다 더 편한 건 없습니다. 다른 옵션들은 리전을 넘나들거나 네트워크 설정을 완전히 뜯어고쳐야 하므로 운영 오버헤드가 매우 큽니다.

정답은 A와 C입니다. 가장 빠른 '쇼트컷'은 스냅샷 바로 복제(A)입니다. RDS MySQL 스냅샷은 클릭 몇 번으로 Aurora용 인스턴스로 변신할 수 있습니다. 만약 버전이 다르거나 세밀한 데이터 조정이 필요하다면, 덤프 파일을 S3라는 중간 창고에 올려두고 Aurora가 이를 쑥 빨아들이게(C) 할 수도 있습니다. 두 방법 모두 튼튼하게 검증된 표준 마이그레이션 기술입니다. 다른 옵션인 D나 E는 굳이 안 써도 될 DMS 도구까지 꺼내 드는 셈이라 절차가 훨씬 더 복잡해집니다.

정답은 C입니다. 서버가 바쁜 이유가 '이미지 배달' 때문이라면, 그 일감을 서버(EC2)에게서 뺏어와야 합니다. 정적 파일(이미지, CSS 등)을 S3에 던져두고 CloudFront라는 전담 배달부를 고용하세요. 그러면 사용자는 서버까지 올 필요 없이 가장 가까운 배달 거점에서 이미지를 받아갑니다. 서버 부하가 획기적으로 줄어드니 대수를 대폭 낮출 수 있고, 고객은 로딩 속도가 빨라져서 행복해집니다. 다른 옵션인 A와 B는 서버의 '대수' 자체를 줄여주지는 못하고, D는 오히려 연산 비용이 더 많이 나올 수 있는 과한 설계입니다.

정답은 D입니다. 데이터 양이 페타바이트(PB)급에 달한다면 '복사(A)'는 돈 낭비입니다. 'Lake Formation'은 데이터 레이크 전용 보안 사령부입니다. 여기서 데이터마다 '비밀', '공개' 같은 태그를 붙여두고 \\\\\\\"데이터 과학 팀에겐 '공개' 태그 데이터만 보여줘!\\\\\\\"라고 설정하면, 여러 계정을 넘나들며 권한 관리가 한 번에 끝납니다. 운영 수고가 가장 적고 세련된 방식입니다. 다른 옵션인 B는 규모가 커지면 관리가 불가능해지고, C는 주로 외부 업체와 유료 데이터를 거래할 때 쓰는 서비스입니다.

정답은 A입니다. 전 세계 사용자가 '업로드'와 '다운로드'를 동시에 빠르게 하려면 S3 Transfer Acceleration이 정답입니다. 이 기능을 켜면 사용자는 집 근처 AWS 전용 통로(Edge Location)까지만 파일을 던지면 됩니다. 그 후엔 AWS가 가진 초고속 전용 전용선을 타고 S3 버킷까지 데이터가 날라가죠. GB급 대용량 파일을 전송할 때 지연 시간을 줄여주는 가장 확실한 처방전입니다. 다른 옵션인 C는 비용이 감당 안 될 수준으로 불어날 것이고, D는 GB급 파일을 수억 개 담기엔 메모리 비용 비효율이 너무 큽니다.

정답은 B입니다. 재난 대응과 실수 방지라는 두 마리 토끼를 잡아야 합니다. 먼저 DB에는 '삭제 방지' 자물쇠를 채우고, 한쪽 데이터 센터가 불나도 끄떡없는 '다중 AZ' 설정을 켭니다. 서버 역시 수동으로 한두 대 띄우지 말고, 로드 밸런서(ALB)가 상태를 확인하다가 죽으면 Auto Scaling이 새 서버를 즉시 찍어내게 만드세요. 이렇게 '관리자가 없어도 알아서 돌아가는' 구조가 바로 Well-Architected 안정성의 표본입니다. 다른 옵션인 D처럼 스팟 인스턴스를 쓰면 서버가 갑자기 사라질 수 있어 '안정성' 목적에는 맞지 않습니다.

정답은 A입니다. 700TB를 90일 안에 옮기려면 매일 대량의 데이터를 안정적으로 쏴야 합니다. AWS DataSync는 이 일에 가장 최적화된 일꾼입니다. 처음 한 번 전체를 복사한 뒤(Full Sync), 그 사이 수정된 '바뀐 부분'만 쏙쏙 골라 실시간으로 덧칠해주듯 옮겨주니(Incremental Sync) 이사 중에도 직원이 파일을 쓰는 데 아무 문제가 없습니다. 10Gbps 광대역 전용선까지 있다면 더할 나위 없이 빠른 이사가 가능합니다. 다른 옵션인 B(Snowball)는 장비를 주문하고 받는 시간 때문에 '실시간 수정 사항 반영'을 챙기기가 매우 까다롭습니다.

정답은 D입니다. 'Compliance(규정 준수)' 모드는 관리자 할아버지가 와도 7년 전에는 절대 못 지우는 강력한 금고 모드입니다. 새로 생기는 파일은 설정을 켜면 그만이지만, 이미 수억 개가 쌓인 '기존 파일'들에게도 이 잠금장치를 채우는 게 일이죠. 이때 'S3 배치 작업'을 쓰면 수억 개의 파일에 일일이 자물쇠를 채우는 단순 반복 노가다를 클릭 한 번으로 끝내줍니다. 운영 효율 면에서 완벽한 정답입니다. 다른 옵션인 A(버전 관리)는 관리자가 삭제 마커를 지우면 결국 파일이 날아갈 수 있어 '법적 박제'로는 부족합니다.

정답은 A입니다. 글로벌 서비스의 관문은 Route 53입니다. 여기에는 '지연 시간 라우팅'이나 '태평양 건너오기 전 주소 안내' 같은 똑똑한 기능들이 많습니다. 특히 리전별 상태를 감시하다가(Health Check) 한 리전이 폭격(?)을 맞아 죽으면, 즉시 살아있는 다른 리전의 IP 주소를 손님들에게 알려주는 '장애 조치(Failover)' 설정이 재해 복구의 핵심입니다. 다른 옵션인 D처럼 메인 리전에 ALB를 세우면, 그 리전 자체가 죽었을 때 서비스 전체가 마비되는 싱글 포인트 장애를 초래하게 됩니다.

정답은 C입니다. 운영팀은 전용선(DX)을 두 줄이나 끌어와서 튼튼하게 준비했는데, 관리팀은 사내 데이터 센터에 장비를 한 대(Customer Gateway)만 두고 VPN 한 줄에 의존하고 있습니다. 만약 이 회사 장비가 고장 나거나 인터넷 선이 끊기면 관리 작업 자체가 불가능해지죠. 진정한 고가용성을 위해서는 사내에도 두 대 이상의 장비를 두고 다중 VPN 터널을 뚫어야 비로소 '격벽'이 완성됩니다. 다른 옵션인 A(피어링)는 AWS 내부의 소프트웨어적 연결이라 물리적 전선처럼 쉽게 끊어지는 성질의 것이 아닙니다.

정답은 B입니다. '관리형 서비스의 편안함'과 '관리자 권한의 자유'를 동시에 누릴 수 있는 중간 지점이 바로 RDS Custom입니다. 일반 RDS는 보안상 DB 속 깊숙한 설정을 막아두지만, RDS Custom은 운영 체제(OS) 접근은 물론 특정 타사 소프트웨어가 요구하는 막강한 권한 설정까지 허용해 줍니다. 마이그레이션 중 '이건 꼭 관리자 권한이 있어야 돌아가는데!' 싶을 때 꺼내 드는 필살기입니다. 다른 옵션인 C는 관리 수고가 너무 많이 들고, D는 '신속한 이동'이라는 목표에 전혀 맞지 않는 험난한 길입니다.

정답은 C, E, F입니다. AWS 1타 강사의 필승 전략입니다. 첫째, 하나의 서버에 있던 기능을 웹/앱/DB로 쪼개고(리팩터링) 각각 전용 서브넷에 담아 부하에 맞춰 늘어나게(Auto Scaling) 만드세요(C). 둘째, 입구에는 로드 밸런서(ELB)를 세워 교통 정리를 하고 보안 그룹 ID끼리 서로를 알아보게 '체인' 보안을 겁니다(E). 마지막으로 DB는 다중 AZ로 장애를 방어하고 프라이빗 공간에 꽁꽁 숨기면(F) 완벽한 3계층 아키텍처가 탄생합니다. 다른 옵션인 A나 D는 '단일 장애 지점'을 해결하지 못해 정답이 될 수 없습니다.