AWS SAA C03 연습 문제 (251~275번)

정답은 B입니다. 프라이빗 서브넷의 보안을 지키면서 '밖으로 나가는 통로'만 안정적으로 확보하는 표준은 NAT 게이트웨이입니다. 이를 퍼블릭 서브넷(인터넷이 닿는 곳)에 설치하고, 프라이빗 서브넷의 라우팅 테이블에 '인터넷(0.0.0.0/0)으로 갈 때는 이 NAT 게이트웨이를 타라'고 적어주면 됩니다. 이렇게 하면 외부에서 서버로 들어오는 건 막으면서 서버가 업데이트를 위해 밖으로 나가는 건 허용됩니다. 다른 옵션인 A는 서버를 인터넷에 직접 노출하는 꼴이라 위험하며, C와 D의 NAT 인스턴스는 예전 방식이라 관리가 번거롭고 확장성도 떨어져 지금은 권장되지 않습니다.

정답은 A입니다. 여러 서버가 '동시에' 같은 파일을 공유해서 써야 할 때 가장 먼저 떠올려야 할 서비스는 EFS입니다. EFS는 파일 시스템 계층(NFS)을 지원하여 수천 대의 서버가 하나의 거대한 가드닝 백처럼 파일을 공유할 수 있게 해줍니다. 또한 데이터를 여러 가용 영역(AZ)에 상시 복제해두므로 데이터 손실 걱정 없는 강력한 중복성을 자랑합니다. 다른 옵션인 B는 기본적으로 서버 한 대에만 붙이는 전용 하드 느낌이라 동시 공유가 어렵고, C는 너무 느린 백업용 창고입니다. D는 저장소가 아니라 백업을 관리해주는 서비스일 뿐입니다.

정답은 C입니다. IAM 정책은 '누가 어떤 행동(Action)을 할 수 있는지'를 정의한 명세서입니다. 이 문제에서 클라우드 엔지니어가 그룹에 소속되어 받은 권한 중 핵심은 EC2 서비스에 대한 제어권입니다. 따라서 서버(인스턴스)를 생성하거나 삭제하는 등의 실제 인프라 관리 업무를 수행할 수 있게 됩니다. 다른 옵션인 A, B, D는 각각 IAM 관리 권한, 디렉토리 서비스 권한, 로그 관리 권한이 따로 있어야 가능하며, 일반적인 엔지니어 그룹의 기본 정책에는 포함되지 않는 경우가 많습니다.

정답은 B입니다. 보안 그룹 설정의 백미는 '보안 그룹 간 참조'입니다. 예를 들어 앱 계층 보안 그룹 설정에서 '웹 계층 보안 그룹 ID를 가진 녀석들만 8080 포트로 들어오게 해'라고 적어두면 됩니다. 이렇게 하면 웹 서버가 1대든 100대든 상관없이 자동으로 적용되며, 실수로 다른 엉뚱한 서버가 접근하는 걸 완벽히 차단할 수 있습니다. 다른 옵션인 A는 서버가 바뀔 때마다 고쳐야 해서 너무 힘들고, C와 D는 같은 서브넷 내의 다른 무관한 서버들까지 문을 열어주게 되어 '최소 권한'이라는 취지에 맞지 않습니다.

정답은 D입니다. 주문 중복을 막는 가장 확실한 방법은 SQS FIFO(First-In-First-Out)입니다. 이 대기열은 들어온 순서대로 정확히 '한 번만(Exactly-once)' 전달하는 기능이 있습니다. 똑같은 주문 번호를 가진 메시지가 연달아 들어와도 대기열이 '어, 이건 아까 받은 거네?' 하고 중복을 제거해줍니다. 결제 서비스가 하나씩 정직하게 꺼내 처리하고 삭제하면 중복 주문 사고는 사라집니다. 다른 옵션인 A는 대량 수집용이라 중복 제거가 핵심이 아니고, B는 감사용 도구라 실시간 비즈니스 로직에 쓰기엔 부적절합니다. C는 한 번에 여러 곳에 뿌리는 용도라 순서와 누락 방지에는 약점이 있습니다.

정답은 B와 D입니다. 파일의 과거 기록을 보관하려면 '버전 관리(B)'가 필수입니다. 이렇게 하면 파일을 덮어써도 옛날 파일이 층층이 쌓여 언제든 복구할 수 있습니다. 또한 '실수로 지우는 일'을 막으려면 MFA 삭제(D)가 최고입니다. 파일을 지우려 할 때마다 폰으로 OTP 인증을 해야만 삭제가 허락되므로, 클릭 실수 한 번으로 중요한 데이터를 날리는 비극을 막을 수 있습니다. 다른 옵션인 A와 C는 사용자들이 파일을 수정하거나 업로드하는 것까지 막아버려 업무 지장을 초래하고, E는 데이터 도난 방지용이지 삭제 방지용은 아닙니다.

정답은 A입니다. 서버 자체에 무언가를 깔거나(D), 주기적으로 조사를 나가는(C) 방식은 서버에 부담을 주거나 지연이 생깁니다. 하지만 CloudWatch Metric Streams를 쓰면 AWS 인프라 단에서 발생하는 지표를 시스템에 영향 없이 빛의 속도로 낚아챌 수 있습니다. 이를 Kinesis Firehose라는 자동 배달부와 연결하면, 단 몇 초 만에 모든 상황이 S3에 차곡차곡 쌓여 실시간 대시보드를 그릴 수 있게 됩니다. 다른 옵션인 B는 단순 로그 수집용으로는 비용과 운영 부담이 너무 큰 과잉 투자입니다. C는 '실시간'이 아닌 '간격'이 생기는 단점이 있습니다.

정답은 D입니다. 1GB나 되는 큰 파일을 람다(A)에서 직접 요리하는 건 시간과 메모리 제한 때문에 위험합니다. 대신 데이터 전용 처리 일꾼인 AWS Glue를 써야 합니다. Glue의 ETL 작업을 하나 만들어두고, S3에 파일이 들어올 때마다 람다가 '야, Glue! 일해!'라고 신호만 주면 됩니다. Glue는 거대한 데이터도 척척 변환해주는 서버리스 서비스라 운영자가 서버 사양을 고민할 필요가 전혀 없습니다. 다른 옵션인 C는 분석에는 좋지만, 매시간 쏟아지는 대량 파일의 '자동 변환' 파이프라인으로는 Glue ETL 조합보다 효율이 떨어집니다.

정답은 A입니다. AWS에는 여러 서비스의 백업을 한곳에서 중앙 관리해주는 'AWS Backup'이라는 훌륭한 비서가 있습니다. 여기서 '매일 한 번 백업하고 2년 뒤에 폐기해'라고 규칙(Plan)을 정의하고 RDS를 등록만 하면 끝입니다. 복원 테스트도 쉽고 규정 준수 보고서도 뽑을 수 있어 엔터프라이즈 환경에서 가장 권장되는 방식입니다. 다른 옵션인 B의 DLM은 주로 EBS 하드디스크 전용이라 RDS 스냅샷을 정교하게 관리하기엔 무리가 있고, C는 '백업'이 아닌 '로그'라 복원 용도로는 부적합합니다. D는 이사용 도구를 백업용으로 쓰는 셈이라 설정이 너무 복잡해집니다.

정답은 D입니다. FSx for Windows의 가장 큰 장점은 기존 윈도우 환경과의 완벽한 호환성입니다. 파일 시스템을 만들 때 회사의 AD 도메인에 가입(Join)시키기만 하면 됩니다. 그러면 따로 IAM 설정을 할 필요도 없이, 기존에 사내에서 쓰던 아이디와 그룹 권한이 그대로 적용됩니다. 직원들은 서버가 구름(AWS) 위로 올라갔는지도 모른 채 익숙한 방식으로 파일을 사용할 수 있습니다. 다른 옵션인 A, B, C는 윈도우 파일 시스템 고유의 ACL 권한 체계를 무시하고 AWS 전용 권한인 IAM으로 해결하려다 보니 설정만 복잡해지고 실제 권한 동기화도 제대로 되지 않습니다.

정답은 A와 C입니다. 사용자 장치에 맞는 맞춤형 배달의 핵심은 '에지(Edge) 위치'에서의 처리입니다. 먼저 Lambda@Edge(C)가 손님의 브라우저 신호를 읽고 '아, 이분은 모바일이네!'라고 판단해서 알맞은 이미지를 골라냅니다. 그 결과를 전 세계에 퍼져 있는 CloudFront의 캐시 창고(A)에 보관해두면, 다음번에 똑같은 모바일 유저는 서버까지 올 필요 없이 집 근처 에지에서 즉시 모바일 화면을 받게 되어 속도가 비약적으로 빨라집니다. 다른 옵션인 B, D, E는 주로 트래픽의 통로를 뚫어주는 네트워킹 기술이지, '어떤 장치인지'를 분석해서 내용물을 바꿔주는 섬세한 작업에는 어울리지 않습니다.

정답은 A입니다. 같은 지역에 있는 두 네트워크를 연결하는 가장 가성비 좋고 빠른 방법은 'VPC 피어링'입니다. 별도의 장비나 중간 서버 없이 AWS 내부망으로 직접 대화하게 해주므로 비용도 저렴하고 속도도 최상입니다. 이때 상대방 보안 그룹 ID를 참조하여 '앱 서버 그룹만 우리 캐시에 들어올 수 있어'라고 설정하면 보안까지 깔끔하게 해결됩니다. 다른 옵션인 B와 D의 Transit VPC 방식은 관리할 서버가 늘어나고 통신 비용도 증가하는 비효율적인 선택입니다. C는 피어링 자체를 보안 그룹 소스로 쓴다는 표현이 약간 어색하며, 직접적인 보안 그룹 간 참조가 더 정확한 정답에 가깝습니다.

정답은 A와 D입니다. 인프라 관리 업무를 '제로'로 만들고 싶다면 서버리스 컨테이너 서비스인 Fargate가 정답입니다. ECS라는 관리 도구(A)를 베이스로 깔고, 실행 방식만 Fargate(D)로 선택하면 우리가 서버 배치를 고민할 필요가 없습니다. AWS가 알아서 남는 공간에 컨테이너를 던져서 실행해주죠. 서비스 중단을 막기 위해 최소 2개 이상의 컨테이너(Task)를 돌리게 설정하면 고가용성까지 완벽하게 확보됩니다. 다른 옵션인 B, C, E는 결국 우리가 OS 패치나 서버 사양 관리를 해야 하는 'EC2' 기반이라 '인프라 관리 최소화'라는 목표에 어긋납니다.

정답은 D입니다. 수십 명의 손님을 관리할 때는 한 명씩 주소록을 뒤지는 것보다 친절한 '안내 데스크(ALB)'를 두는 게 최고입니다. 로드 밸런서는 10대 서버의 맥박을 실시간으로 짚어보고(Health Check), 숨이 멎은 서버가 있으면 즉시 대열에서 빼버립니다. 손님은 오직 안내 데스크(ALB)의 주소만 알면 되고, 데스크가 알아서 살아있는 서버로 연결해주니 타임아웃 오류가 사라집니다. 다른 옵션인 A와 B는 서버가 늘어날수록 관리가 너무 힘들고, C는 속도 향상(캐싱)에는 좋지만 정교한 로컬 서버 상태 관리용으로는 ALB가 더 기본적이고 강력합니다.

정답은 C입니다. 이것이 보안과 속도의 황금 조합입니다. 웹 서버 본체는 '프라이빗 서브넷'이라는 안전한 안방에 숨깁니다. 그리고 '퍼블릭 서브넷'에는 대외 창구인 ALB를 둡니다. 이 ALB가 안방의 서버들과 대화하죠. 마지막으로 전 세계의 통신 거점(에지)인 CloudFront가 이 ALB로부터 데이터를 받아 사용자에게 배달하게 하면, 보안은 철통 같으면서도 사용자는 집 근처 에지에서 데이터를 받게 되어 엄청나게 빨라집니다. 다른 옵션인 A와 D는 서버가 인터넷에 노출되어 위험하고, B는 로드 밸런서라는 필수적인 중계기가 없어 고가용성을 확보하기 어렵습니다.

정답은 A입니다. 게임처럼 전 세계에 흩어진 사용자에게 '전용 고속도로'를 뚫어주는 기술이 바로 Global Accelerator입니다. 사용자가 이 서비스를 타면 공용 인터넷 대신 AWS의 고품질 전용 선로를 타게 되어 지연 시간이 비약적으로 줄어듭니다. 또한 전 세계 곳곳의 서버(ALB) 상태를 감시하다가, 한쪽 지역이 아프면 즉시 가장 가까운 '건강한' 지역으로 손님을 안내해주니 이번 문제의 정답으로 완벽합니다. 다른 옵션인 B와 C는 주로 정적인 파일 배달용이라 실시간 게임 명령 전송에는 부족하고, D는 DB 성능만 올릴 뿐 네트워크 지연(네트워크 타는 시간)은 해결하지 못합니다.

정답은 D입니다. 이 조합은 '서버 관리'라는 단어 자체를 잊게 해주는 서버리스의 끝판왕입니다. Firehose(파이어호스)는 데이터를 받자마자 지정된 포맷(Parquet)으로 알아서 변환하고 암호화까지 해서 S3에 툭 던져줍니다. 여기에 Kinesis Data Analytics를 붙이면 데이터가 지나가는 동안 실시간으로 SQL을 써서 분석할 수 있습니다. 운영자는 서버 한 대도 안 띄우고 거대한 데이터 공장을 돌리는 셈이죠. 다른 옵션인 A, B, C는 관리해야 할 서버(EMR)나 코드(Lambda)가 늘어나서 운영 부담이 커지는 비효율적인 방식입니다.

정답은 B입니다. 서버 수백 대가 DB 한 대에 줄을 서면 DB는 연결 관리만 하다가 지쳐 쓰러집니다. 이때 'RDS Proxy'를 중간에 세우면, 이 친구가 미리 연결들을 꽉 잡고 있다가 필요한 서버에게만 번환해주며 중재 역할을 합니다. 앱 코드를 거의 바꿀 필요 없이 DB 연결 주소만 Proxy로 바꾸면 되므로 적용이 아주 쉽고, DB가 훨씬 효율적으로 일하게 되어 속도가 빨라집니다. 다른 옵션인 A는 앱 코드를 대폭 고쳐야 하고, C와 D는 시스템 전체를 새로 만드는 수준의 대공사라 '최소한의 변경'이라는 목표에 탈락입니다.

정답은 C입니다. 메인 DB가 힘들어하는 이유는 '쓰기(주문)'와 '읽기(분석)'가 한 서버에서 싸우기 때문입니다. 이때 '읽기 전용 복제본'을 하나 더 만들어주면 끝납니다. 메인 DB는 주문만 받고, 분석가들은 이 복제본에서 맘껏 쿼리를 날리게 하면 됩니다. 기존 앱의 코드는 하나도 고칠 필요가 없으니 가장 효율적이고 비용 대비 효과도 확실한 정석 설계입니다. 다른 옵션인 A와 D는 데이터를 옮기는 파이프라인을 새로 만들어야 해서 일이 커지고, B의 캐시는 복잡한 분석 쿼리를 수행하기엔 적합하지 않은 도구입니다.

정답은 A입니다. '전송 중인 데이터'까지 완벽하게 보호하는 가장 확실한 방법은, 데이터가 서버를 떠나기 전(클라이언트 측)에서 미리 암호화의 갑옷을 입히는 것입니다. 이렇게 하면 인터넷 통로를 지나가는 동안에도 데이터는 이미 암호문 상태라 안전하며, S3에 도착해서 잠들 때도 그 갑옷을 입은 채라 보안이 철벽에 가까워집니다. 다른 옵션인 B와 C는 데이터가 AWS 서버에 도착한 '후'에 암호를 거는 방식이라, 아주 이론적으로는 전송되는 찰나의 순간이 노출될 위험이 있습니다. D는 암호화 도구만 설정할 뿐 전송 과정의 보안을 책임져주지는 못합니다.

정답은 C입니다. 언제 손님이 몰릴지 뻔히 알고 있다면, 시스템이 스스로 깨달을 때까지 기다릴 필요가 없습니다. '예약된 확장' 정책을 써서 "매일 새벽 0시 55분에 서버 10대를 미리 띄워놔!"라고 예약해두면 됩니다. 배치 작업이 시작되자마자 풀 파워로 일을 끝낼 수 있고, 아침이 되면 다시 서버를 줄여 돈을 아끼는 아주 영리한 전략입니다. 다른 옵션인 A는 배치 작업이 없는 23시간 동안의 비용이 낭비되고, B와 D는 여전히 부하가 발생한 '후'에 반응하기 때문에 초기 1시간의 지연 문제를 근본적으로 해결하지 못합니다.

정답은 B입니다. 시스템 구조를 하나도 안 바꾸고 속도만 올리는 마법이 바로 CloudFront입니다. 기존 ALB 주소 앞에 CloudFront라는 전 세계 규모의 배달망을 씌우기만 하면 됩니다. 그러면 한국 유저는 서울에 있는 에지 서버에서 즉시 데이터를 받게 되어 미국까지 통신할 필요가 없어지죠. 특히나 다국어 지원까지 고려한다면, 언어 요청 헤더를 보고 그에 맞는 화면을 기억(캐싱)하게 설정하면 완벽합니다. 다른 옵션인 A는 서버가 하는 동적인 기능을 포기해야 해서 위험하고, C와 D는 시스템을 거의 새로 짓는 수준의 엄청난 노가다와 비용이 발생합니다.

정답은 B입니다. 재난 상황에서 가장 중요한 건 '얼마나 빨리 복구되느냐(RTO)'입니다. '웜 스탠바이'는 비상 지역에 최소한의 서버가 이미 '살아있는' 상태라, 사고 터지면 오토 스케일링으로 서버 대수만 늘리면 끝납니다. 특히나 Aurora 글로벌 DB를 쓰면 평소에 데이터가 1초 미만으로 자동 복제되므로, 데이터 유실도 거의 없고 복구 속도도 빛의 속도로 빠릅니다. 다른 옵션인 A의 파이럿 라이트는 비상시 서버를 새로 '켜야' 하므로 시간이 더 걸리고, C와 D의 일반 RDS는 리전을 넘나드는 자동 복제 성능이 Aurora 글로벌 DB보다 현저히 떨어집니다.

정답은 B입니다. 평소 비용 0원과 빠른 복구(4시간)를 동시에 잡는 고수의 권법은 '클라우드 형성(CloudFormation)'을 통한 자동 배포입니다. 서버는 이미지(AMI) 파일 형태로 창고에만 보관하고(저장비만 발생), 실제 비싼 서버 장비는 하나도 안 띄웁니다. 그러다 사고가 나면 설계도(Code) 한 번 실행해서 일제히 서버를 새로 구워내는 거죠. 손으로 직접 구성하는 것(A)보다 훨씬 빠르고 정확합니다. 다른 옵션인 C와 D는 평소에도 비싼 서버 월세가 꼬박꼬박 나가기 때문에 '최소 리소스 사용'이라는 목표에 탈락입니다.

정답은 C입니다. 서버가 '필요할 때' 더 빨리 튀어나오게 가속 페달을 밟는 것이 핵심입니다. 대상 추적 정책(C)은 우리가 일일이 숫자를 정하지 않아도 "평균 CPU 40%만 유지해!"라고 명령하면 알아서 조절합니다. 여기서 임계값을 더 낮게 잡고 '휴지 기간(Cool-down)'을 줄여버리면, 아침 트래픽이 몰릴 때 서버가 망설이지 않고 연속해서 팍팍 늘어나게 되어 지연 현상을 깔끔하게 해결할 수 있습니다. 다른 옵션인 A와 D는 트래픽이 없는 오전 중반이나 점심시간에도 비싼 서버를 20대나 띄우고 있어야 해서 돈이 아주 많이 아까운 방식입니다.