AWS SAA C03 연습 문제 (701~725번)

정답은 C입니다. 여러 가용 영역에 있는 여러 EC2 인스턴스가 동시에 같은 파일을 열어보고 수정해야 할 때는 'Amazon EFS'가 정답입니다. EFS는 파일 시스템 수준의 공유 저장소라 별도의 복사 과정 없이 모든 서버가 하나의 대형 하드디스크를 공유하는 것처럼 쓸 수 있습니다. 다른 옵션인 B(EBS 스냅샷)는 각 인스턴스가 독립적인 복사본을 가지게 되므로, 한 서버에서 수정한 내용이 다른 서버에 실시간으로 반영되지 않습니다.

정답은 C입니다. 보안 그룹(Security Group)은 기본적으로 '모든 문이 닫혀 있음' 상태입니다. 따라서 우리가 원하는 특정 대상(프라이빗 EC2의 보안 그룹)에게만 '열쇠(허용 규칙)'를 주면 됩니다. 이렇게 하면 허용되지 않은 퍼블릭 서브넷 등은 자동으로 입구 컷을 당하게 됩니다. 다른 옵션인 B는 틀린 설명입니다. 보안 그룹은 '거부(Deny)' 규칙을 지원하지 않고 오직 '허용(Allow)' 규칙만 만들 수 있습니다. 거부 규칙이 필요할 때는 네트워크 ACL을 써야 합니다.

정답은 A, C, F입니다. Outposts는 우리 회사 건물 안에 AWS 장비를 가져다 놓는 것입니다. 따라서 하드웨어가 돌아갈 '전기'와 '인터넷 선(A)', 건물에 아무나 못 들어오게 막는 '물리 보안(C)'은 고객의 몫입니다. 또한 장비 장애 시 서버가 자동으로 옆으로 옮겨가도록 '여유 자원(Capacity, F)'을 미리 확보해두는 것도 운영팀이 할 일입니다. 다른 옵션인 B(하이퍼바이저), D(부품 수리), E(물리 유지보수)는 하드웨어 전문가인 AWS가 책임지고 관리해주는 영역입니다.

정답은 B, D입니다. 전송 계층(L4) 통신이 핵심이므로 초고속 처리가 가능한 'Network Load Balancer(NLB)'를 써야 합니다. 여기에 서버 한 대가 죽어도 다른 영역에서 즉시 새 서버를 띄워주는 'Auto Scaling 그룹'을 연동하면, 중단 없는 고가용성 시스템을 가성비 있게 완성할 수 있습니다. 다른 옵션인 A(Route 53)는 로드 밸런서만큼 정교하고 빠른 트래픽 분산과 상태 확인(Health Check) 복구를 수행하기엔 부족합니다.

정답은 B입니다. '비용 이상 탐지'는 AWS가 똑똑한 AI(머신러닝)를 써서 "어? 평소보다 돈이 갑자기 많이 나가는데?"라고 먼저 말을 걸어주는 기능입니다. 단순히 한도를 넘었을 때 알려주는 Budget보다 정교하며, 우리가 놓치기 쉬운 비정상적인 지출 패턴을 즉시 잡아내 줍니다. 다른 옵션인 A(Budgets)는 우리가 미리 정한 금액을 넘어야 연락이 오므로, 정해진 금액 안에서 발생하는 비정상적인 패턴은 잡아내기 어렵습니다.

정답은 D입니다. '1년에 한두 번'이라는 키워드는 가끔 쓰는 데이터(Infrequent Access)를 위한 'S3 Standard-IA' 등급이 딱이라는 신호입니다. 저장 비용이 훨씬 저렴할 뿐만 아니라, 요청 시 즉시 파일을 꺼낼 수 있어 성능도 합격입니다. 서버 없이 S3만으로 웹사이트를 돌리면 관리비도 0에 가까워집니다. 다른 옵션인 C(Standard)는 언제든 꺼냈기엔 좋지만, 매달 내는 저장 공간 사용료가 IA 등급보다 비싸서 가성비 면에서 밀립니다.

정답은 C입니다. '미리 서명된 URL'은 특정 파일에만 1시간이나 10분 동안만 쓸 수 있는 '일회성 비밀번호'를 붙인 것과 같습니다. 이 주소를 받은 사람만 딱 정해진 시간 동안 파일을 내려받을 수 있어 보안 모범 사례에 가장 부합합니다. 다른 옵션인 D(공개 개방)는 단 1초라도 전 세계 해커들에게 설계도를 노출하는 꼴이 되므로 실무에서는 절대 해서는 안 될 위험한 행동입니다.

정답은 A입니다. S3에 쌓인 텍스트 로그 파일들을 별도의 데이터 이동 없이 마치 엑셀이나 DB 테이블처럼 조작할 수 있는 마법 같은 도구가 'Athena'입니다. SQL 언어만 조금 알면 수천억 건의 로그 중에서도 "A 직원이 어제 삭제한 파일" 같은 걸 단 몇 초 만에 찾을 수 있습니다. 다른 옵션인 B(Neptune)는 친구 관계 같은 복잡한 연결망(Graph)을 분석하는 툴이라 단순 로그 검색에는 맞지 않습니다.

정답은 A입니다. 보고서는 데이터 읽기 작업이 핵심입니다. 대장 DB(Primary)는 원래 하던 주문/결제 처리를 하게 두고, 똑같은 데이터 사본을 가진 조수 DB(Read Replica)를 하나 만들어서 보고서용 조회를 거기서 처리하면 대장의 부담을 100% 덜어줄 수 있습니다. 다른 옵션인 C(사양 업)는 비용이 계속 비싸질 뿐만 아니라, 결국 한계에 도달하게 되므로 '읽기 부하 분산'이 훨씬 똑똑한 해결책입니다.

정답은 A입니다. 가장 안전한 방법은 필요한 것만 허용하는 '최소 권한의 원칙'입니다. 'arn:aws:s3:::AdminTools'와 'arn:aws:s3:::AdminTools/*' 이 두 가지 리소스에 대해 쓰기/읽기 권한을 명시적으로 주면, 언급되지 않은 다른 버킷은 기본적으로 아무도 못 보게 막히게 됩니다. 다른 옵션인 D(일단 다 주기)는 보안상 가장 위험한 대처입니다. 신입 사원이 실수로 전용 파일을 삭제하기라도 하면 돌이킬 수 없는 피해를 입게 됩니다.

정답은 A입니다. 장거리 인터넷은 거리가 멀수록 속도가 뚝 떨어집니다. 'Transfer Acceleration'은 전 세계 AWS 고속도로 입구를 통해 데이터를 받으므로 속도가 압도적으로 빠릅니다. 여기에 큰 파일을 조각내서 병렬로 쏘는 '멀티파트 업로드'를 더하면 가속도가 배가 됩니다. 다른 옵션인 C(Snowball)는 데이터 전송에는 강력하지만, '매일' 500GB씩 발생하는 데이터를 처리하기 위해 매일 택배를 주고받기엔 운영상 불가능에 가깝습니다.

정답은 A입니다. 서버를 옆자리에 바짝 붙여 앉히는 것이 '클러스터 배치 그룹'입니다. 네트워크 지연 시간을 최소로 줄여주죠. 여기에 하나의 EBS(io1/io2) 하드디스크를 최대 16대 서버가 동시에 꽂아 쓰는 'Multi-Attach' 기능을 더하면 완벽한 HPC 환경이 완성됩니다. 다른 옵션인 B(EFS)는 파일 시스템 방식이라 공유는 편하지만, 성능(IOPS) 면에서 하드디스크 직결 방식인 EBS Multi-Attach(A)를 따라오기 어렵습니다.

정답은 D입니다. 람다는 '일회용' 함수라 실행될 때마다 DB 문(Connection)을 열고 닫습니다. 분당 800번이나 문을 열어젖히니 DB 본체는 한가해도 '문(연결 개수)' 자체가 부족해 사고가 나는 겁니다. 'RDS Proxy'는 이 문을 미리 열어두고 람다들이 돌려 쓰게 해주므로 연결 오류가 즉시 해결됩니다. 다른 옵션인 A(사양 증가)는 본체가 아닌 '통로' 부족 문제라 사양을 키워도 근본적인 해결책이 되지 못하고 비용만 많이 듭니다.

정답은 D입니다. 항상 떠 있어야 하는 최소 2대는 미리 약정해서 할인받는 'Reserved' 또는 'Savings Plan'이 제일 쌉니다. 가끔 늘어나는 3대는 그때그때 빌려 쓰는 온디맨드가 제격이며, 1년 내내 24시간 켜둘 DB는 'Reserved Instance'로 사두는 것이 정답입니다. 다른 옵션인 C는 '주말엔 DB를 끈다'고 했는데, 앱이 항상 사용 가능해야 한다는 조건에 어긋납니다. 또한 스팟 인스턴스(C)는 AWS가 필요할 때 언제든 뺏어갈 수 있어 안정적인 서비스에는 적합하지 않습니다.

정답은 D입니다. CloudFront(CDN)를 쓰면 두 마리 토끼를 잡습니다. 사용자 근처 서버에 문서를 복사해두니 응답 속도가 '밀리초' 단위로 빨라지고, S3에서 나가는 데이터 전송료(Data Transfer Out)가 할인되거나 없어질 수 있어 전체 비용이 확 줄어듭니다. 다른 옵션인 C(가속화)는 '업로드' 속도를 높이는 데는 좋지만, 다수의 사용자가 문서를 '내려받는' 속도와 비용 절감에는 CloudFront(D)가 훨씬 우월합니다.

정답은 B입니다. '가끔 쓰지만 즉시 나와야 함'의 교과서적인 정답은 'S3 Standard-IA'입니다. 여기에 실수로 지우는 대참사를 막기 위해 파일의 과거 상태를 기억하는 '버전 관리'와, 지울 때마다 핸드폰 인증을 요구하는 'MFA 삭제'를 조합하면 완벽한 철통 보안 저장소가 됩니다. 다른 옵션인 A(Glacier)는 가격은 제일 싸지만 데이터를 꺼낼 때 최소 몇 분에서 몇 시간을 기다려야 하므로 '즉시 사용'이라는 조건에 탈락입니다.

정답은 B, E입니다. Athena는 읽은 데이터 양만큼 돈을 받고 성능이 결정됩니다. '파티셔닝(B)'을 통해 딱 필요한 날짜 폴더만 뒤지게 하고, 'Parquet 형식(E)'으로 변환해서 필요한 열만 쏙쏙 뽑아 읽게(Columnar) 만들면 속도는 빛의 속도로 빨라지고 요금은 바닥으로 떨어집니다. 다른 옵션인 C(거대 파일 하나)는 데이터를 병렬로 나눠서 읽는 클라우드의 장점을 하나도 못 쓰게 만드므로 성능이 최악이 됩니다.

정답은 C입니다. '교차 계정 역할'은 상대방의 신분증(자기 계정 아이디)을 그대로 믿어준 채, 우리 집 드라이브만 잠시 쓸 수 있게 '임시 출입증'을 주는 방식입니다. 운영 수고가 거의 없고, 상대방이 퇴사하면 그쪽 계정에서 처리하면 되니 보안 관리도 훨씬 깔끔합니다. 다른 옵션인 D는 상대방 직원이 바뀔 때마다 우리 쪽에서도 일일이 사원 이름을 등록해야 하므로 관리 오버헤드가 너무 큽니다.

정답은 D입니다. 사용량이 들쭉날쭉할 때는 지가 알아서 사양을 조절하는 'Aurora Auto Scaling'이 최고입니다. 또한 Aurora는 기본적으로 과거 어떤 시점으로든 되돌리는 기능(PITR)이 강력해서 5시간 미만의 RPO 요구사항을 식은 죽 먹기로 해결하며, 감사 로그 보관도 체크박스 하나로 끝납니다. 다른 옵션인 A(DynamoDB)는 기록 보관(Streams) 기간이 기본 24시간 뿐이라 7일간의 감사 기록을 직접 보관하기에는 별도의 추가 코딩이 필요해 운영 오버헤드가 큽니다.

정답은 C입니다. 이미 알고 있는 이벤트(광고 날짜 등)가 있을 때는 '예측 조정'이나 '예약 조정'이 좋지만, '갑자기 증가하는 트래픽'에 대응하는 기본은 '동적 조정(Dynamic Scaling)'입니다. CPU 사용량 등이 올라가면 바로 서버를 투입하므로 성능을 가장 확실하게 보장하며, 필요 없을 땐 서버를 빼서 돈도 아껴줍니다. 다른 옵션인 A(수동 조정)는 반응 속도가 너무 느려 손님이 다 떠난 뒤에야 서버가 늘어날 우려가 큽니다.

정답은 C입니다. 람다는 요청 한 번에 연결 하나를 맺으려 하므로, 수천 명의 사용자가 오면 DB 입구가 꽉 막혀버립니다. 'RDS Proxy'는 숙련된 매니저처럼 연결 통로(Pool)를 소수만 열어두고 람다들에게 번갈아 쓰게 하므로, DB를 바꾸거나 코드를 고칠 필요 없이 즉시 문제가 해결됩니다. 다른 옵션인 B(사양 증가)는 근본적인 통로 관리 문제가 아니기에 결국 같은 한계에 도달하게 되고 비용만 눈덩이처럼 불어납니다.

정답은 C입니다. CloudFront와 무료 인증서(ACM)의 궁합은 정해져 있습니다. 무조건 '버지니아 북부(us-east-1)' 지역의 ACM에서 발급받은 공인 인증서만 인식됩니다. 이 인증서는 AWS 서비스 내에서 쓰면 무료이므로, 추가 비용 없이 전문적이고 안전한 사이트를 만들 수 있습니다. 다른 옵션인 A(사설 인증서)는 회사 내부용이라 일반 사용자들이 웹사이트에 올 때 '경고 창'이 뜨게 되므로 일반적인 웹 배포에는 부적합합니다.

정답은 A입니다. 네트워크 속도는 '물리적 거리'에 비례합니다. '클러스터 배치 그룹'은 AWS 데이터 센터 안에서 가장 속도가 빠른 통로로 연결된 가까운 구역에 서버들을 옹기종기 모아줍니다. HPC처럼 서버끼리 대화를 많이 해야 하는 작업엔 이보다 더 중요한 설정은 없습니다. 다른 옵션인 B(전용 인스턴스)는 보안이나 규정 준수에는 좋지만, 네트워크 속도 자체를 획기적으로 빠르게 해주는 마법의 도구는 아닙니다.

정답은 B입니다. 람다는 평소엔 쉬다가 손님이 오면 엔진을 켭니다(Cold Start). 이게 아침 첫 손님에겐 응답 지연으로 느껴지죠. '프로비저닝된 동시성'은 아침 9시(업무 시작) 전에 미리 엔진 10개를 따끈하게 데워두라는 명령어입니다. 이렇게 하면 첫 손님도 기다림 없이 즉시 화면을 볼 수 있습니다. 다른 옵션인 D(메모리 증가)는 시동이 걸린 '후'의 속도는 높여주지만, 아예 처음 시동을 거는 '지연 시간' 자체를 없애주지는 못합니다.

정답은 A입니다. 한 가용 영역(AZ)이 통째로 정전이 나도 옆 동네 가용 영역에 있는 조수(Replica)가 즉시 대장으로 승격(Failover)되려면 '다중 AZ' 설정이 필수입니다. 여기에 데이터를 여러 덩어리로 나눠 담는 '샤딩'까지 더하면 성능과 안정성이라는 두 마리 토끼를 완벽하게 잡을 수 있습니다. 다른 옵션인 B(AOF)는 데이터 보존에는 좋지만, 장비 장애 시 자동으로 옆 영역에서 서비스를 이어가게 해주는 '고가용성' 시스템을 대체할 수는 없습니다.