AWS SAA C03 연습 문제 (301~325번)

정답은 C입니다. 대량의 데이터를 온라인으로 옮길 때 가장 똑똑한 도구는 DataSync입니다. 단순히 파일을 복사하는 게 아니라 전송 속도(대역폭)를 내 맘대로 조절할 수 있어서, 낮에는 업무에 방해 안 되게 조금만 쓰고 밤에는 풀가동하는 식으로 유연하게 대처할 수 있습니다. 30TB 정도의 분량도 며칠 안에 안전하고 빠르게 옮겨줍니다. 다른 옵션인 A는 물리적 장비라 속도 조절이 어렵고, B는 하이브리드 연결용이며 D는 파일 전송 프로토콜 서비스라 대규모 이사용으로는 DataSync가 훨씬 강력합니다.

정답은 A와 C입니다. 영상 서비스의 정석은 '최적화 후 배달'입니다. 먼저 Elastic Transcoder라는 자동 요리사(C)에게 영상을 맡겨서 스마트폰에서 보기 딱 좋은 가벼운 형식으로 바꾸고, 이 영상을 CloudFront(A)라는 전 세계 배달망에 실어 보내면 됩니다. 이렇게 하면 사용자는 집 근처 에지 서버에서 가벼워진 영상을 바로 받아보니 버퍼링 걱정 없이 즐길 수 있습니다. 다른 옵션인 B는 단순 복제일 뿐 성능 개선과는 거리가 멀고, D와 E는 서버를 직접 관리해야 하는 수고가 커서 '운영 수고를 줄인다'는 조건에 맞지 않습니다.

정답은 D입니다. 컨테이너 서비스(ECS)에는 그에 맞는 자동 조절기인 Application Auto Scaling이 필요합니다. 특히 '대상 추적 정책'은 'CPU 사용량을 50%로 맞춰줘'라고 목표만 정해주면, 트래픽이 몰릴 때 컨테이너 개수를 알아서 늘리고 한가해지면 줄여줍니다. 사용자는 복잡한 계산 없이도 성능과 비용 두 마리 토끼를 잡을 수 있습니다. 다른 옵션인 A는 고정된 패턴에만 강하고, B는 수동이라 번거롭습니다. C는 EC2 전용이라 Fargate 환경에서는 Application Auto Scaling을 쓰는 D가 정답입니다.

정답은 A입니다. 지역(Region) 간 파일 전송에도 DataSync가 전문가입니다. NFS 프로토콜을 완벽히 이해하고 있어서, 한번 설정해두면 정해진 시간마다 알아서 바뀐 데이터만 골라 반대편 지역으로 슝 보내줍니다. 서버를 직접 관리할 필요도 없고 전송 상태도 한눈에 볼 수 있어 매우 효율적입니다. 다른 옵션인 B는 며칠씩 걸리는 물리적 이동이라 실시간이나 정기 전송에 안 맞고, C는 서버 관리 독박을 써야 합니다. D는 파일이 아니라 DB 전문이라 탈락입니다.

정답은 C입니다. 윈도우 전용 공유 폴더(SMB)가 필요하다면 고민 없이 FSx for Windows를 고르면 됩니다. AWS가 윈도우 서버 엔진을 기반으로 미리 다 만들어둔 서비스라, 클릭 몇 번이면 수백 대의 서버가 동시에 쓸 수 있는 거대한 공유 하드가 생깁니다. 보안 업데이트나 백업도 AWS가 알아서 해주니 관리자는 게임 개발에만 집중하면 됩니다. 다른 옵션인 A와 D는 정식 파일 공유 방식이 아니라 불안정하며, B는 서버 관리를 직접 해야 하는 '노가다' 방식입니다.

정답은 A입니다. 속도와 비용이 최우선이라면 한 울타리 안에 모이는 게 상책입니다. 서버들을 하나의 가용 영역(AZ)에 다닥다닥 붙여놓고 'Cluster Placement Group'으로 설정하면, 서버들 사이에 광속의 전용 차선이 깔립니다. 같은 구역이라 데이터 전송료도 안 나오고 속도는 전 세계 최고 수준으로 빨라집니다. 다른 옵션인 B는 안정성에는 좋지만 속도(지연 시간) 면에서는 A보다 불리하며, C와 D는 서버를 분산시키기 때문에 전송 비용이 발생할 수 있습니다.

정답은 D입니다. 똑똑한 '캐시(Cached) 방식'을 쓰면 됩니다. 전체 데이터는 무제한 창고인 S3에 모셔두고, 사무실 하드디스크에는 직원들이 금방 썼던 '따끈따끈한 자료'들만 올려두는 거죠. 직원들은 사무실 하드에서 바로 자료를 꺼내니 빠르고, 사무실에 큰 서버를 들일 필요도 없으니 공간과 비용이 획기적으로 절약됩니다. 다른 옵션인 A는 파일 단위 접근(NFS/SMB)에 좋고, C인 '보관형'은 전체 데이터를 사내 서버에 다 두는 방식이라 용량을 아끼는 데는 캐시형(D)이 최고입니다.

정답은 B와 D입니다. 비용 절감의 지름길은 '노는 서버 찾기(D)'와 '전체 계정 총괄 감시(B)'입니다. Trusted Advisor를 통해 아무 일도 안 하면서 전기세(비용)만 먹는 유휴 DB를 찾아내서 끄고, 이 모든 과정을 통합 결제 계정에서 한눈에 파악하면 관리가 훨씬 쉽습니다. 24시간 계속 돌아가는 서버라면 예약 인스턴스(RI) 추천도 함께 보면 금상첨화입니다. 다른 옵션인 A는 너무 비효율적이고, C는 좋은 옵션이지만 D처럼 당장 새나가는 돈을 막는 게 우선순위인 경우가 많습니다. E는 오라클 DB와 상관없는 Redshift 이야기입니다.

정답은 A입니다. S3 전용 망원경인 'Storage Lens'를 써보세요. 굳이 로그를 분석하지 않아도, 어떤 버킷에 사람이 안 오는지, 어디에 용량만 차지하는 찌꺼기 파일이 많은지 대시보드로 예쁘게 보여줍니다. 이걸 보면 어떤 버킷을 지워도 될지 바로 알 수 있어 비용 최적화에 큰 도움이 됩니다. 다른 옵션인 B는 수동이라 불가능에 가깝고, C와 D는 분석 전문가 수준의 실력이 필요하며 공수도 너무 많이 듭니다.

정답은 B입니다. 전 세계 배달망인 CloudFront를 활용하는 게 가장 이득입니다. 먼 나라 고객들도 자기 근처 에지 서버에서 데이터를 받아가니 훨씬 빠르고, AWS 내부망을 이용하니 직접 S3에서 내려받는 것보다 전송료도 훨씬 저렴해집니다. 여기에 'CloudFront 서명 URL'을 더하면, 돈을 낸 유료 고객만 일정 시간 동안 자료를 받을 수 있게 완벽히 통제할 수 있습니다. 다른 옵션인 A는 전송료가 더 비싸질 수 있고, C는 관리 노가다가 심합니다. D는 서버 부하만 늘리는 최악의 선택입니다.

정답은 C입니다. 가장 믿음직한 조합인 'SNS + SQS'를 쓰면 됩니다. 먼저 SNS라는 우체국에 모든 요청을 던지면, 우체국이 '이건 자동차 보험이네?', '이건 생명 보험이네?' 하고 미리 정해둔 규칙(필터)대로 해당 SQS 대기열(바구니)에 쏙 넣어줍니다. 서버들은 자기 바구니에 담긴 일감만 차례대로 처리하면 되니 섞일 염려도 없고 절대 잃어버리지도 않습니다. 다른 옵션인 A와 D는 구사가 너무 복잡하고 운영 부담이 큽니다. B는 알림 위주라 데이터 보존성(누락 방지) 면에서 SQS를 섞어 쓰는 C보다 약합니다.

정답은 B입니다. 서버 전체(EC2)를 대상으로 AWS Backup을 돌리는 게 가장 완벽합니다. 단순히 하드디스크뿐만 아니라 CPU 사양이나 네트워크 설정 같은 서버 통째의 정보(AMI)를 백업해주기 때문입니다. 백업 계획표에 '다른 나라 리전으로 자동 복사' 옵션 하나만 체크해두면, 나중에 한국 리전이 정전되어도 미국 리전에서 즉시 서버를 똑같이 살려낼 수 있습니다. 다른 옵션인 A는 코딩 노가다가 심하고, C는 서버 본체 설정이 빠져서 나중에 복구할 때 머리가 아파집니다. D는 너무 원시적인 방법입니다.

정답은 C입니다. 수백만 명을 감당하려면 CloudFront 외엔 대안이 없습니다. 보안은 '서명된 URL(Signed URL)'이 책임집니다. 사용자가 로그인하면 서버가 '이 주소는 10분만 유효해요'라는 암호가 붙은 전용 링크를 만들어주고, CloudFront는 이 링크를 가진 정당한 사용자에게만 영상을 빠르게 쏴줍니다. 속도와 보안, 두 마리 토끼를 다 잡는 표준적인 방법입니다. 다른 옵션인 A는 보안이 너무 취약하고, B와 D는 수백만 명의 연결을 감당하다가 네트워크 장비가 불타버릴 것입니다.

정답은 B입니다. 가끔씩 쓰는 창고라면 '서버리스(Serverless)' 모델이 딱입니다. Aurora Serverless는 아무도 안 쓰면 잠자코 있다가, 누가 접속하면 즉시 깨어나 서버를 구성하고 손님이 많아지면 용량을 알아서 키웁니다. 관리자가 서버 크기(CPU, 메모리)를 미리 정할 필요도 없고, 쓴 만큼만 돈을 내니 비용 면에서도 매우 경제적입니다. 다른 옵션인 A와 D는 정해진 크기의 서버를 계속 켜둬야 하며, C는 데이터 분석용이지 일반 DB가 아닙니다.

정답은 D입니다. 서버의 '건강 검진'은 Inspector의 몫입니다. 서버 안에 요원(에이전트)을 한 명씩 배치해두면, 매일 같이 서버 설정이 잘못됐는지, 낡아서 해킹 위험이 있는 소프트웨어가 깔려 있는지 꼼꼼히 검사해서 보고서를 써줍니다. 운영 체제 내부의 취약점을 직접 파고드는 서비스는 Inspector가 유일하다고 봐도 무방합니다. 다른 옵션인 A는 디도스 방어용이고, B는 파일 속 개인 정보 찾기용입니다. C는 전반적인 네트워크 행동을 감시하는 '레이더' 역할이지 내부 취약점을 직접 스캔하지는 않습니다.

정답은 C입니다. 24시간 대기하는 서버는 비효율적입니다. 메시지가 들어올 때만 반응하는 Lambda로 바꾸는 게 최선입니다. Lambda는 SQS에 메시지가 쌓이면 알아서 깨어나 일을 시작하고, 메시지가 수백 개면 수백 개의 Lambda가 동시에 나타나 일을 처리한 뒤 다시 사라집니다. 일한 만큼만 돈을 내니 비용은 확 줄고 처리 능력은 무한대로 커집니다. 다른 옵션인 A는 여전히 돈이 낭비되고, B는 낮에도 일감이 없을 때 돈을 내야 합니다. D는 수동이라 인건비가 더 나올 판입니다.

정답은 A입니다. 데이터 형식 변환의 달인은 'AWS Glue'입니다. 'S3에 든 CSV를 가져가서 Redshift 모양으로 예쁘게 깎아 넣어줘'라고 작업(ETL) 하나만 만들어두면 됩니다. 서버 한 대 관리할 필요 없는 완전 관리형 서비스라, 정해진 시간마다 로봇처럼 파일을 변환해서 DB에 넣어주니 분석 도구는 평화롭게 데이터만 읽으면 됩니다. 다른 옵션인 B는 코딩과 서버 관리가 고역이고, C는 배보다 배꼽이 더 큰 설계입니다. D는 빅데이터 분석용이라 단순 변환에는 너무 과한 장비입니다.

정답은 A와 D입니다. 범인을 잡고 규칙을 세우는 팀입니다. CloudTrail(A)이란 CCTV로 '누가' 했는지 기록을 남기고, Config(D)라는 기록관을 통해 리소스가 어떻게 '변했는지' 히스토리를 관리합니다. 특히 Config에 '비싼 서버는 못 만든다'는 규칙을 적어두면, 누군가 규칙을 어겼을 때 즉시 알림을 주므로 사후 감사나 관리가 매우 쉬워집니다. 다른 옵션인 B나 C는 기록 추적과는 거리가 멀고, E는 너무 극단적인 대처라 실무에서 쓰기 힘듭니다.

정답은 A입니다. 이제 '열쇠(Key)'는 잊어버리세요. Session Manager를 쓰면 브라우저 화면에서 버튼 하나만 누르면 서버 터미널이 바로 뜹니다. SSH 포트(22번)를 열어둘 필요도 없고, 열쇠를 잃어버려 당황할 일도 없습니다. 누가 들어왔는지 기록도 남고 관리하기에 너무나 편한 최신 방식입니다. 다른 옵션인 C는 여전히 키 관리와 징검다리 서버 관리가 필요해서 보안상 더 복잡합니다. B와 D는 바퀴를 새로 발명하는 격의 과한 설계입니다.

정답은 A입니다. 실시간 데이터의 정석 'Streams-Analytics' 조합입니다. 데이터를 시냇물(Streams)처럼 끊임없이 받아내고, 그 흐르는 물속에서 즉시 SQL로 분석(Analytics)을 수행합니다. 데이터는 AWS 내부에서 3곳 이상에 안전하게 복제되므로 서버가 꺼져도 절대 잃어버리지 않으며 실시간 조회까지 완벽하게 해냅니다. 다른 옵션인 B는 쿼리를 하기까지 몇 분의 지연이 발생하며, C는 서버가 꺼지면 데이터가 증발하는 가장 위험한 선택입니다. D는 실시간 분석용이 아니라 웹 서빙용에 가깝습니다.

정답은 D입니다. 업로드 요청(PutObject)에 '암호화해서 저장해줘!'라는 쪽지(x-amz-server-side-encryption 헤더)가 없으면 퇴짜를 놓는 정책을 세우면 됩니다. 이렇게 하면 실수로 생으로 파일을 올리려는 시도가 원천 차단되므로, S3에 저장되는 모든 파일은 무조건 AWS가 알아서 잠궈주는 안전한 상태가 됩니다. 다른 옵션인 A, B, C는 암호화와는 직접적인 관련이 없는 엉뚱한 보안 설정들입니다.

정답은 C입니다. 비동기 처리를 위한 'SQS 바구니' 전략입니다. 사용자가 이미지를 올리면 '알았어요, 이 바구니(SQS)에 넣어둘 테니 나중에 확인하세요'라고 0.1초 만에 답을 줍니다. 그럼 한가한 일꾼 서버가 이 바구니에서 일감을 꺼내 60초 동안 정성껏 썸네일을 만드는 거죠. 사용자는 기다리지 않아도 되니 앱이 아주 빠릿빠릿하다고 느끼게 됩니다. 다른 옵션인 A는 여전히 사용자가 람다 결과가 나올 때까지 기다릴 위험이 있고, B나 D는 단순한 이 작업에 비해 너무 거창하거나 알림에만 치중되어 있습니다.

정답은 B입니다. 서버리스 콤비인 'API Gateway + Lambda'가 제격입니다. 건물 입구의 장치는 이 문지기(API)에게 데이터만 던지면 되고, Lambda라는 일꾼이 나타나서 출입 기록을 DynamoDB라는 고속 수첩에 착 적어줍니다. 서버 관리도 필요 없고 24시간 멈추지 않는 아주 견고하고 현대적인 출입 관리 시스템이 됩니다. 다른 옵션인 A는 서버가 죽으면 기록이 다 날아가고, C는 길 찾기 도구를 엄무에 동원하는 격입니다. D는 단순 데이터 전송을 위해 너무 비싼 전용선을 까는 낭비입니다.

정답은 D입니다. 직원들이 대기 시간 없이 즉시 파일을 열어봐야 하므로, 모든 데이터가 사무실에 그대로 있는 '보관형(Stored)'이 정답입니다. 이 방식은 사무실 장비에 데이터를 저장하면서 동시에 S3로 복사본을 날려줍니다. 나중에 사무실이 침수되어도 클라우드에 든 스냅샷 파일을 클릭 한 번으로 새 서버에 붙저서 복구할 수 있는 아주 든든한 보험입니다. 다른 옵션인 C는 일부 데이터만 로컬에 두는 방식이라 '원본 100% 보관' 조건에 어긋나며, A와 B는 용도가 전혀 다릅니다.

정답은 A입니다. 로그인하는 곳(User Pool)과 권한을 주는 곳(Identity Pool)은 다릅니다. 사용자가 로그인하면 그에게 '이런 일을 할 수 있다'는 신분증(IAM Role)을 줘야 하는데, 이 신분증 설정이 부실해서 금지된 구역(S3)에 못 들어가는 것입니다. 자격 증명 풀 설정에서 적절한 권한을 가진 역할을 지정해주기만 하면 문제는 깔끔하게 해결됩니다. 다른 옵션인 B는 구식 방식이라 추천하지 않고, C는 뜬금없는 소리입니다. D는 로그인을 더 복잡하게 만들 뿐 정작 중요한 '금고 열쇠(권한)'와는 상관이 없습니다.