Q626 온프레미스 저장 용량이 꽉 차서 S3로 데이터를 옮기려 합니다. 이사가 끝난 뒤 데이터가 하나도 깨지지 않고 잘 전송되었는지 자동으로 확인하고 싶은데, 어떤 도구가 좋을까요? Snowball Edge 장비를 주문하고 배경에서 온라인 전송을 하도록 설정합니다. AWS DataSync 에이전트를 설치하고 S3로 전송을 예약합니다. S3 파일 게이트웨이를 설치해서 윈도우 탐색기처럼 파일을 복사합니다. S3 Transfer Acceleration 기능을 켜서 업로드 속도만 높입니다. 정답 확인 및 해설 📖 해설 정답은 B입니다. AWS DataSync는 대규모 데이터를 옮길 때 전송 중이나 전송 후에 데이터가 원본과 똑같은지 자동으로 검증(Verification)해주는 기능이 내장되어 있습니다. 신뢰성이 가장 높으며 설정도 간편합니다. 다른 옵션인 D는 속도만 빨라질 뿐 데이터 무결성을 자동으로 꼼꼼히 체크해주지는 않습니다. 💡 이 문제의 핵심 용어 AWS DataSync: 온프레미스와 AWS 사이의 대용량 데이터 전송을 자동화하고 가속화하는 서비스 Data Integrity (데이터 무결성): 데이터가 전송이나 저장 과정에서 변조되거나 깨지지 않고 원래 상태를 유지하는 성질 Verification (검증): 데이터가 목표지에 정확하게 도착했는지 원본과 대조하여 확인하는 과정
Q627 온프레미스에서 직접 운영하던 DNS 서버 2대를 AWS로 옮기려 합니다. 관리 수고는 줄이면서 가용한도는 높이고 싶은데, 가장 강력한 추천 방법은? Amazon Route 53 콘솔에서 영역 파일을 가져와(Import) 호스트 존을 만듭니다. 아주 커다란 EC2 서버를 하나 띄워서 수동으로 영역 파일을 관리하고 감시합니다. Server Migration Service(SMS)를 써서 기존 서버 이미지를 그대로 복제해 옵니다. 두 개의 가용 영역(AZ)에 EC2 서버를 띄우고 오토 스케일링을 걸어 직접 관리합니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. 기존에 서버를 직접 관리(패치, 업데이트 등)하던 수고를 없애는 가장 좋은 방법은 서버가 필요 없는 '관리형 서비스'인 Route 53을 쓰는 것입니다. 영역 파일을 한 번만 옮겨두면 AWS가 알아서 전 세계에 분산해주고 가용성도 100%에 가깝게 보장합니다. 원문에서 서버 복제(C)나 EC2(D)를 언급했지만, 이는 '운영 오버헤드 최소화'라는 목적에는 어울리지 않는 하수입니다. 💡 이 문제의 핵심 용어 Amazon Route 53: 서버 관리 없이 도메인 이름과 트래픽을 지휘하는 AWS의 똑똑한 길잡이(DNS) 서비스 Hosted Zone (호스트 존): 특정 도메인의 DNS 레코드를 모아놓은 가상의 관리 바구니 Operational Overhead (운영 오버헤드): 서버를 유지하고 관리하기 위해 담당자가 들여야 하는 귀찮은 수고의 총량
Q628 여러 계정의 S3 버킷에 거대한 파일을 올리다 실패한 찌꺼기(불완전한 멀티파트 업로드)들이 쌓이고 있습니다. 이걸 한눈에 보고 관리하고 싶은데, 가장 편한 분석 툴은? AWS Config를 설정해서 규칙 위반 사항으로 메일을 받습니다. 조직 전체에 SCP 정책을 걸어서 실패한 업로드를 원천 차단합니다. S3 Storage Lens를 구성하여 조직 전체의 업로드 실패 현황을 대시보드로 봅니다. 다중 리전 액세스 포인트를 만들어서 로그를 분석합니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 'S3 Storage Lens'는 전사적인 S3 사용 현황을 화려한 대시보드로 보여주는 분석 도구입니다. 여기에는 용량뿐만 아니라 '불완전한 멀티파트 업로드'처럼 돈만 나가고 쓸모없는 파일들의 개수도 포함되어 있어 비용 절감 포인트를 찾기에 딱입니다. 다른 옵션인 B(SCP)는 보고(Reporting) 기능이 아니라 차단 서비스이므로 문제의 의도와 다릅니다. 💡 이 문제의 핵심 용어 S3 Storage Lens: 수천 개의 버킷에 담긴 데이터 양과 활동 패턴을 한눈에 분석해주는 전사적 통계 서비스 Incomplete Multipart Upload: 큰 파일을 쪼개서 올리다가 중간에 끊겨서 용량만 차지하고 완성되지 못한 파일 조각들 Multi-account 가시성: 여러 계정의 정보를 한곳에서 뚫어지게 볼 수 있는 능력
Q629 운영 중인 MySQL(RDS)의 버전을 올리고 싶은데, 워낙 중요한 데이터라 안전하게 테스트해보고 싶습니다. 데이터 손실 없이 가장 빠르게 업로드하는 법은? 수동 스냅샷을 찍고 운영 서버를 잠시 끈 뒤 버전을 즉시 올립니다. 데이터를 백업받아 새 버전의 서버에 수동으로 복원합니다. DMS(데이터베이스 마이그레이션 서비스)를 써서 실시간으로 데이터를 새 버전에 복제합니다. Amazon RDS '블루/그린 배포(Blue/Green)' 기능을 써서 조용히 테스트하고 한 번에 교체합니다. 정답 확인 및 해설 📖 해설 정답은 D입니다. '블루/그린 배포'는 똑같은 복제 서버(그린)를 옆에 하나 더 만들어서 그쪽 버전만 살짝 올린 뒤 충분히 테스트 해보는 방식입니다. 모든 게 완벽하면 버튼 하나로 손님들을 새 서버(그린)로 옮길 수 있어 사고 위험이 거의 없습니다. 다른 옵션인 A는 서버를 꺼야 하거나 테스트 중에 실제 데이터가 오염될 위험이 있어 고수들은 피하는 방식입니다. 💡 이 문제의 핵심 용어 Blue/Green Deployment: 현재 가동 중인 환경(Blue)과 똑같은 새 환경(Green)을 만들어 안전하게 검증하고 교체하는 배포 전략 Amazon RDS: DB 설치와 버전 업그레이드를 자동화해주는 AWS의 고마운 DB 관리 서비스 Zero Data Loss (데이터 무실): 이동이나 작업 과정에서 단 한 조각의 정보도 잃어버리지 않는 상태
Q630 하루에 딱 한 번, 2시간 정도 걸리는 데이터 작업이 있습니다. 중간에 끊기면 처음부터 다시 해야 하는데, 가장 가성비 좋게 돌리는 법은? 24시간 켜져 있는 예약 인스턴스(RI) 서버에 스케줄러를 등록합니다. 시간 제한이 있는 람다(Lambda) 함수를 억지로 이어 붙여서 돌립니다. EventBridge로 시간을 맞춰놓고, 딱 그때만 ECS Fargate 작업을 실행시킵니다. ECS on EC2 방식을 택해서 매번 서버를 껐다 켰다 하게 만듭니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. (원문 index 2) 2시간이라는 긴 작업 시간은 람다(최대 15분)로는 감당이 안 됩니다. 그렇다고 서버(EC2)를 계속 켜두는 건 돈 낭비죠. 이럴 땐 필요할 때만 컨테이너를 잠깐 빌려 쓰는 'Fargate'가 정답입니다. 작업이 끝나면 비용 청구도 멈추므로 경제적입니다. 다른 옵션인 A는 하루 22시간 동안 놀고 있는 서버 비용을 내야 하므로 가성비가 매우 떨어집니다. 💡 이 문제의 핵심 용어 AWS Fargate: 서버 사양을 고민할 필요 없이 컨테이너만 실행하면 되는 서버리스 컴퓨팅 엔진 Amazon EventBridge: 정해진 시간이나 특정 사건(이벤트)에 맞춰 다른 서비스를 실행시키는 일종의 똑똑한 타이머 Batch Job (배치 작업): 데이터를 한꺼번에 모아서 한 번에 처리하는 방식의 작업
Q631 SNS 친구 추천 알고리즘을 위해 사용자 관계와 상호작용을 분석하려 합니다. 이런 '관계도(그래프)' 모델에 특화된 DB와 감시 통로의 조합은? Amazon Neptune에 저장하고 Kinesis로 실시간 변화를 감시합니다. Amazon Neptune에 저장하고 내장 기능인 'Neptune Streams'로 변화를 추적합니다. 가계부 전용인 QLDB에 저장하고 Kinesis로 소통합니다. 데이터 요약본을 QLDB에 넣고 Neptune Streams로 엉뚱한 감시를 합니다. 정답 확인 및 해설 📖 해설 정답은 B입니다. 친구의 친구, 좋아하는 관심사 등 거미줄처럼 얽킨 데이터를 분석하는 데는 그래프 전용 DB인 'Amazon Neptune'이 필수입니다. 여기에 데이터가 바뀔 때마다 즉시 알려주는 'Neptune Streams'를 더하면 실시간 추천 시스템을 가장 편하게 만들 수 있습니다. 원문에서 언급한 C나 D(QLDB)는 데이터의 위변조 방지가 중요한 장부 기록용이지, 복잡한 인맥 분석용이 아닙니다. 💡 이 문제의 핵심 용어 Amazon Neptune: 사람, 장소, 사물 간의 복잡한 관계를 연결하고 탐색하는 데 특화된 고성능 그래프 데이터베이스 Neptune Streams: Neptune 데이터베이스에 새 정보가 오거나 바뀔 때 그 내역을 실시간으로 알려주는 통로 Graph Database: 데이터를 점(노드)과 선(엣지)으로 연결해 관계를 분석하기 유리하게 만든 DB 형태
Q632 여러 가용 영역(AZ)에 흩어진 수많은 리눅스 서버들이 하나의 똑같은 폴더를 공유하면서 실시간으로 계속 데이터를 수정해야 합니다. 어떤 저장소가 필수일까요? 무작정 싸게 S3 Glacier에 넣고 접근 권한만 열어둡니다. 성능 좋은 EBS 볼륨을 각 서버에 개별적으로 달아주고 수동으로 맞춥니다. Amazon EFS를 만들어서 수많은 리눅스 서버들이 동시에 마운트하게 합니다. 비싼 프로비저닝된 IOPS(SSD) 볼륨을 여러 서버가 같이 쓰도록 억지로 엮습니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 여러 대의 리눅스 서버가 하나의 저장소를 '동시에' 읽고 쓰고 싶다면 정답은 무조건 EFS입니다. 가용 영역(AZ)에 상관없이 네트워크를 통해 연결되므로 서버가 늘어나도 관리하기가 매우 편합니다. 다른 옵션인 D(EBS 공유)는 특수한 클러스터링 설정이 필요하고 관리가 까다로워 일반적인 파일 공유에는 EFS(C)가 훨씬 유리합니다. 💡 이 문제의 핵심 용어 Amazon EFS (Elastic File System): 수천 대의 EC2 인스턴스가 동시에 공유해서 쓸 수 있는 리눅스용 클라우드 파일 저장소 Concurrent Access (동시 접속): 여러 대의 컴퓨터가 하나의 데이터에 한꺼번에 달라붙어 작업하는 상태 Mount (마운트): 외부 저장 장치를 내 컴퓨터의 특정 폴더처럼 보이게 연결하는 행위
Q633 중요한 RDS(PostgreSQL)가 손님들이 몰리면서 느려졌습니다. 분석해보니 '조회(Read) 쿼리'가 범인이었는데, 주 서버의 짐을 덜어줄 가장 효과적인 조치는? 비상 대기 중인 스탠바이(Standby) 서버에게 몰래 읽기 숙제를 시킵니다. S3에나 쓰는 Transfer Acceleration 기능을 억지로 DB에 입힙니다. 주 서버의 내용을 그대로 복제한 '읽기 전용 복제본(Read Replica)'을 만들어 숙제를 넘깁니다. Kinesis Data Firehose를 앞에 세워서 모든 쿼리를 줄 세워 기다리게 합니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 주 서버는 데이터의 수정과 삭제만으로도 벅찹니다. 단순히 정보를 읽어가는 조회 작업들은 '읽기 전용 복제본'을 여러 명 고용해서 그 친구들에게 맡기면 주 서버의 숨통이 트이고 전체 앱 속도가 빨라집니다. 다른 옵션인 A(스탠바이 서버)는 장애 시 교체용이라 평소에는 일을 시킬 수 없는 비상 대기조일 뿐입니다. 💡 이 문제의 핵심 용어 Read Replica (읽기 전용 복제본): 주 DB의 복사본을 만들어 오직 정보 조회 작업만 전담시키는 보조 서버 Query (쿼리): 데이터베이스에게 정보를 달라고 하거나 수정하라고 내리는 컴퓨터 명령어 Multi-AZ Deployment: 장애를 대비해 다른 곳에 똑같은 서버를 한 대 더 예비로 두는 고가용성 배치
Q634 우리 S3에 담긴 귀한 데이터를 여러 외부 컨설팅 업체 분석가들에게 보여줘야 합니다. 보안은 철저히 하면서도 관리하기 가장 깔끔한 공유 방식은? 전 세계 어디서든 보게 S3 글로벌 테이블을 켜고 복제본을 뿌립니다. 점심시간 동안만 S3 버킷을 전체 공개(Public)로 열고 업체에 몰래 알려줍니다. 업체 계정의 아이디들이 우리 S3에 접근할 수 있게 '교차 계정(Cross-account) 권한'을 설정합니다. 컨설팅 직원 100명에게 우리 회사 IAM 아이디를 일일이 하나씩 다 발급해줍니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 남의 집 열쇠를 새로 만드는 것보다, 그 사람이 가진 열쇠를 우리 집 문에 등록해주는 것이 훨씬 안전합니다. 업체 직원들은 자기네 회사 아이디로 로그인한 상태에서 우리 S3 데이터를 읽을 수 있게 되므로, 우리는 남의 회사 아이디를 관리할 수고를 덜 수 있습니다. 다른 옵션인 D는 업체 직원이 퇴사할 때마다 우리가 아이디를 삭제해야 하므로 관리가 지옥이 됩니다. 💡 이 문제의 핵심 용어 Cross-account Access: 서로 다른 AWS 계정끼리 자원을 공유할 수 있도록 허가해주는 보안 설정 Bucket Policy (버킷 정책): S3 바구니에 누가 들어오고 나갈 수 있는지 적어놓은 깐깐한 출입 명부 Operational Efficiency (운영 효율성): 최소한의 관리 포인트로 시스템을 문제없이 돌리는 능력
Q635 고급 저장소인 'NetApp ONTAP'을 쓰는데, 재난 상황을 대비해 다른 리전에 똑같은 쌍둥이 저장소를 만들어두고 싶습니다. 같은 전용 기술을 써서 가장 편하게 복제하는 법은? 람다(Lambda) 함수를 짜서 S3로 데이터를 한 땀 한 땀 옮기고 리전 복제를 겁니다. AWS Backup으로 매일 백업을 받아 서부 리전으로 택배 보내듯 복사해 둡니다. NetApp의 전용 기술인 'SnapMirror' 기능을 켜서 리전 간에 실시간 동기화를 돌립니다. 관계형 DB 전문인 EFS로 모든 데이터를 옮기고 리전 복제 버튼을 누릅니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. FSx for NetApp ONTAP은 실제 NetApp 장비와 똑같은 소프트웨어를 씁니다. 따라서 NetApp의 전용 복제 기술인 'SnapMirror'를 쓰면 수천 킬로미터 떨어진 리전 사이에서도 데이터가 마치 거울처럼 똑같이 유지됩니다. 가장 빠르고 정확하며 설정도 쉽습니다. 다른 옵션인 A나 B는 윈도우/리눅스 파일 시스템의 특성을 100% 반영하지 못하거나 복구 시간이 오래 걸릴 수 있습니다. 💡 이 문제의 핵심 용어 Amazon FSx for NetApp ONTAP: 기업용 고성능 저장 장치인 NetApp ONTAP을 AWS에서 그대로 쓰게 해주는 서비스 SnapMirror: NetApp 장비끼리 데이터를 광속으로 복제하고 동기화하는 전용 기술 Disaster Recovery (DR): 주 센터가 무너졌을 때 멀리 떨어진 보조 센터에서 즉시 서비스를 재개하는 비상 계획
Q636 S3에 파일이 들어올 때마다 람다가 처리하는데, 한꺼번에 수만 개가 들어오면 람다가 감당을 못 할까 봐 걱정됩니다. 중간에 '줄 세우기'를 하려면? SNS 알림이 오면 ECS 서버를 띄워서 천천히 하나씩 꺼내보게 합니다. 쿠버네티스(EKS)를 도입해서 대규모 메시지 처리 시스템을 직접 구축합니다. SNS 뒤에 SQS(대기열)를 붙여서 데이터를 일단 차곡차곡 쌓아두고 람다가 꺼내 쓰게 합니다. 서버 이사 서비스인 SMS를 통해 메시지를 실시간으로 낚아채서 람다로 던집니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 갑자기 쏟아지는 요청에 서버가 터지지 않게 '번호표'를 뽑고 기다리게 만드는 것이 SQS(대기열)의 역할입니다. SNS로 받은 알림을 SQS에 차곡차곡 쌓아두면, 람다는 자신이 처리할 수 있는 만큼만 꺼내 가므로 시스템이 절대 무너지지 않고 확장성(Scalability)도 최고가 됩니다. 다른 옵션인 A나 B는 구조가 너무 복잡해져서 배보다 배꼽이 더 커지는 상황이 됩니다. 💡 이 문제의 핵심 용어 Amazon SQS (Simple Queue Service): 메시지나 데이터를 임시로 보관하며 순서대로 처리할 수 있게 돕는 클라우드 대기열 서비스 Amazon SNS: 메시지를 여러 곳으로 한 번에 뿌려주는 방송국 같은 푸시 알림 서비스 Fan-out (팬아웃): 하나의 이벤트를 여러 개의 대기열이나 서비스로 동시에 전달하는 설계 패턴
Q637 API Gateway 뒷단에서 초당 0건부터 500건까지 요동치는 트래픽을 처리하려 합니다. 데이터는 1GB 미만의 아주 간단한 형태인데, 가장 궁합이 좋은 서버리스 듀오는? Fargate 컨테이너 서버를 씁니다. 계산은 AWS Lambda(람다)에게 맡깁니다. 저장은 가성비 NoSQL인 Amazon DynamoDB에 합니다. EC2 오토 스케일링을 걸어 서버를 무한 복제합니다. MySQL 전통 DB인 Aurora를 씁니다. 정답 확인 및 해설 📖 해설 정답은 B, C(원문 index 1, 2)입니다. 이런 무작위 트래픽(0~500건/초)에는 서버 사양을 고민할 필요 없는 '람다'와 'DynamoDB' 조합이 천생연분입니다. 람다는 요청이 올 때만 반짝 일하고, DynamoDB는 간단한 데이터(키-값 형태) 저장에 최적화되어 있어 속도도 빠르고 비용도 매우 저렴합니다. 다른 옵션인 E(Aurora)는 1GB 미만의 작은 데이터를 담기에는 설정이 과하고 비용도 람다+DynamoDB 조합보다 비쌉니다. 💡 이 문제의 핵심 용어 AWS Lambda: 서버 관리 없이 코드만 올리면 트래픽에 맞춰 자동으로 수천 번 실행되는 서버리스 엔진 Amazon DynamoDB: 규모에 상관없이 10밀리초 안에 데이터를 찾아주는 초고성능 NoSQL 데이터베이스 Predictable Cost (예측 가능한 비용): 사용한 만큼만 돈을 내므로 요금 폭탄 걱정이 상대적으로 적음
Q638 전 세계 직원들에게 연구 자료(S3)를 공유하려 합니다. 보안을 위해 '딱 그 사람만, 일정 시간 동안만' 쓸 수 있는 비밀 주소를 발급하고 싶은데? 람다를 써서 유효 기간이 있는 'S3 사전 지정 URL(Pre-signed URL)'을 생성해 전달합니다. 직원 2천 명에게 각각 IAM 계정을 만들어주고 매일 로그인하게 교육합니다. S3 파일 게이트웨이를 사무실마다 깔고 매번 공유 드라이브를 마운트하게 합니다. SFTP 서버를 따로 구축하고 Secrets Manager로 모든 직원의 비밀번호를 관리합니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. '사전 지정 URL'은 일종의 '임시 입장권'입니다. 로그인 없이도 이 주소만 있으면 정해진 시간(예: 1시간) 동안만 파일을 내려받을 수 있습니다. 관리자가 아이디를 일일이 만들지 않아도 안전하게 파일을 공유할 수 있는 가장 가볍고 똑똑한 방법입니다. 다른 옵션인 D는 SFTP 서버 유지비와 관리 수고가 너무 많이 들어 '운영 오버헤드 최소화'에 어긋납니다. 💡 이 문제의 핵심 용어 S3 Presigned URL: S3 객체에 대해 특정 시간 동안만 유효한 임시 접근 권한을 부여한 보안 인터넷 주소 Temporary Access (임시 접근): 필요할 때만 잠시 문을 열어주고 시간이 지나면 자동으로 닫히는 보안 방식 IAM (Identity and Access Management): 누가 우리 AWS 계정에 들어올 수 있는지 관리하는 보안 대장
Q639 로드 밸런서(ALB) 뒤에 서버가 여러 대 있는데, 유독 한 대만 일이 몰려서 땀을 뻘뻘 흘립니다. 이 편식을 고치기 위해 가장 먼저 체크할 설정은? ALB의 '세션 고정(Sticky Session)' 기능을 꺼서 트래픽을 골고루 섞어줍니다. ALB를 갖다 버리고 더 비싼 Network Load Balancer로 교체합니다. 일이 몰리는 게 정상이니 인스턴스 숫자를 2배로 무작정 늘립니다. 서버가 죽었는지 체크하는 상태 확인(Health Check) 주기를 더 빠르게 바꿉니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. '세션 고정'이 켜져 있으면, 한 번 접속한 손님은 계속 그 서버랑만 대화하게 됩니다. 운 나쁘게 헤비 업로더들이 한 서버에만 몰리면 그 서버만 과부하가 걸리게 되죠. 이 기능을 끄면 로드 밸런서가 손님들을 모든 서버에 공평하게 랜덤으로 나눠주게 되어 부하가 균일해집니다. 다른 옵션인 B는 문제 해결과 상관없는 장비 교체일 뿐 근본적인 라우팅 정책을 바꾸지는 못합니다. 💡 이 문제의 핵심 용어 Sticky Session (스티키 세션): 사용자의 로그인 상태유지 등을 위해 특정 서버로만 계속 안내하는 기능 Load Balancing (부하 분산): 밀려드는 트래픽을 여러 대의 서버에 골고루 나눠주어 시스템이 안 터지게 하는 것 Latency (지연 시간): 어떤 일을 처리하는 데 걸리는 응답 시간. 부하가 몰리면 이 시간이 길어짐
Q640 람다(Lambda)가 S3의 파일을 읽어서 암호를 풀어야(KMS Decrypt) 합니다. 권한 설정을 완벽하게 하려면 어떤 2가지 정석 단계를 밟아야 할까요? 람다 함수 자체의 리소스 정책에 암호 해독 권한을 직접 적어 넣습니다. KMS 키의 주인(Key Policy) 메뉴에서 '람다의 IAM 역할'에게 암호 해독 허락을 줍니다. 람다에게 모든 KMS 키를 다 열어볼 수 있는 마스터 권한을 부여합니다. 람다가 차고 있는 배지(IAM Role)에 'KMS 암호 해독' 정책을 부착합니다. 새로운 실행 역할(Role)을 만들어서 람다에게 선물하고 다시는 안 건드킵니다. 정답 확인 및 해설 📖 해설 정답은 B, D(원문 index 1, 3)입니다. KMS 보안은 이중 잠금장치와 같습니다. ①람다가 그 키를 쓸 권리가 있는지 배지(IAM Policy)를 확인하고, ②금고 키(Key Policy) 쪽에서도 그 람다를 아는 사람으로 등록해줘야 합니다. 이 두 가지가 모두 맞아야 비로소 기밀 파일을 열어볼 수 있습니다. 다른 옵션인 A나 C는 보안상 위험하거나 기술적으로 KMS 정책 구조에 맞지 않는 방식입니다. 💡 이 문제의 핵심 용어 AWS KMS (Key Management Service): 데이터 암호화에 쓰는 열쇠를 안전하게 보관하고 누가 썼는지 기록하는 보안실 Key Policy: 누가 이 자물쇠(암호화 키)를 만질 수 있는지 키 자체에 적어둔 깐깐한 허가서 Decryption (복호화/해독): 암호화되어 읽을 수 없는 데이터를 다시 원래대로 풀어내는 과정
Q641 회장님 보고를 위해 우리 회사의 모든 AWS 계정 청구서(비용 보고서)를 한 달에 한 번씩 분석하려 합니다. 가장 똑똑하고 가성비 좋은 분석 시스템은? Kinesis로 매일 실시간 스트리밍을 받고 EMR 하둡 클러스터를 돌려 계산합니다. 보고서(CUR)를 S3에 담아두고, 무거운 서버 없이 'Amazon Athena'로 필요할 때만 SQL을 날려 분석합니다. 각 지사 계정마다 Redshift라는 비싼 분석 전용 DB 서버를 24시간 켜서 데이터를 모읍니다. 데이터를 다 받아다가 QuickSight라는 그래프 툴에서 매일 실시간으로 봅니다. 정답 확인 및 해설 📖 해설 정답은 B입니다. 한 달에 딱 한 번만 하는 분석에 비싼 서버(Redshift, EMR)를 24시간 켜두는 건 돈 낭비입니다. S3에 보고서 파일을 생성해두고, 분석하고 싶을 때만 'Athena'를 켜서 SQL 명령어를 날리면 쓴 만큼만 돈을 내므로 가장 합리적인 가성비 분석법이 됩니다. 다른 옵션인 A는 실시간 처리용이라 한 달에 한 번 보는 월간 보고용에는 너무 과한(Overkill) 장비입니다. 💡 이 문제의 핵심 용어 AWS Cost and Usage Report (CUR): 비용과 사용량에 대한 가장 상세한 내역을 담은 일종의 가계부 파일 Amazon Athena: S3에 담긴 텍스트 파일을 서버 없이 SQL(데이터베이스 언어)로 검색해주는 서비스 Query (쿼리): 방대한 데이터 속에서 내가 원하는 정보만 골라내서 보여달라고 명령하는 일
Q642 인터넷 게임 서버를 만드는데 UDP 패킷을 써야 하고 트래픽에 따라 서버 대수도 자동으로 늘어나야 합니다. 입구에 어떤 로드 밸런서를 세울까요? 초당 수백만 건을 번개처럼 처리하고 UDP도 지원하는 'Network Load Balancer(NLB)'를 씁니다. 웹 전용(HTTP/HTTPS)인 Application Load Balancer를 고집합니다. 로드 밸런서 없이 Route 53 주소 여러 개를 줘서 손님들이 알아서 찾아가게 합니다. 서버 앞단에 NAT 인스턴스를 겹겹이 쌓아 모든 패킷을 직접 전달합니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. UDP 패킷을 사용하는 게임 서버에는 고성능 L4 장비인 NLB가 정답입니다. NLB는 UDP를 공식 지원할 뿐만 아니라 오토 스케일링 그룹과도 찰떡궁합이라, 손님이 갑자기 늘어나도 지연 시간(Latency) 없이 매끄럽게 게임을 즐기게 해줍니다. 다른 옵션인 B(ALB)는 UDP를 처리할 줄 모르는 웹 전용 장비라 게임 서버에는 쓸 수 없습니다. 💡 이 문제의 핵심 용어 Network Load Balancer (NLB): 가장 낮은 계층에서 엄청난 속도로 트래픽을 나눠주며 TCP/UDP를 모두 지원하는 장비 UDP (User Datagram Protocol): 속도를 위해 데이터가 중간에 조금 새도 괜찮으니 일단 빨리 보내는 방식. 실시간 게임이나 방송에 필수 Auto Scaling: 서버가 바쁘면 새 서버를 자동 투입하고, 한가하면 빼서 비용을 아끼는 시스템
Q643 여러 브랜드 사이트에서 매일 기가바이트씩 쏟아지는 로그를 일주일에 한 번씩만 분석하려 합니다. SQL로 편하게 쿼리하면서도 비용을 제일 많이 아끼는 법은? S3에 로그를 무조건 다 쌓아두고, 딱 분석할 때만 'Amazon Athena'를 켭니다. 나중에 찾기 편하게 RDS(관계형 DB) 서버를 크게 띄워 하나하나 저장해 둡니다. 검색 전문인 OpenSearch 클러스터를 24시간 띄워서 실시간 검색 대시보드를 만듭니다. EMR 빅데이터 클러스터를 구축해서 매일 모든 데이터를 정제하고 닦습니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. 매일 로그가 쌓이지만 주 1회 단기 분석만 한다면, 저렴한 창고인 S3에 데이터를 던져두고 분석할 때만 Athena로 훑는 것이 압도적으로 쌉니다. 서버 유지비가 0원이고 쿼리한 데이터 양만큼만 돈을 내기 때문입니다. 다른 옵션인 C(OpenSearch)는 실시간 검색에는 좋지만, 주 1회 분석을 위해 24시간 서버비를 내는 건 가성비 면에서 낙제점입니다. 💡 이 문제의 핵심 용어 Amazon Athena: S3에 있는 데이터에 대고 SQL을 날리면 바로 답을 알려주는 서버리스 분석 서비스 SQL (Structured Query Language): 표 형태의 데이터에서 정보를 찾아내기 위해 사용하는 전 세계 표준 컴퓨터 언어 On-demand (온디맨드): 미리 예약하지 않고 내가 필요할 때만 즉석에서 빌려 쓰는 방식
Q644 example.com과 나라별 주소(country1.example.com 등) 모두에 보안(HTTPS)을 걸고 싶습니다. 어떤 인증서를 어떻게 관리하는 게 가장 똑똑할까요? (2개 선택) ACM 전용 콘솔에서 본진 주소(example.com)와 '와일드카드(*.example.com)' 인증서를 한꺼번에 요청합니다. 개인 정보 보호를 위해 유료 비공개 인증서를 여러 개 비싸게 삽니다. 공개용과 비공개용 인증서를 복잡하게 섞어서 쓰도록 설계합니다. 담당자 메일로 확인 번호를 받는 이메일 증명 방식을 매번 반복합니다. DNS 관리자에게 레코드 하나만 추가하면 끝나는 'DNS 유효성 검사' 방식을 택합니다. 정답 확인 및 해설 📖 해설 정답은 A, E(원문 index 0, 4)입니다. 전체 하위 도메인을 한 번에 보호하려면 '와일드카드(*)' 인증서가 가성비 최고입니다. 여기에 증명 방식으로 'DNS 유효성 검사'를 선택하면, AWS가 알아서 도메인 주인을 확인하고 만료 전에 갱신까지 해주므로 운영자가 손댈 일이 아예 없어집니다. 다른 옵션인 D는 매번 이메일을 확인하고 버튼을 누르는 귀찮은 작업이 필요해 '자동화'에 매우 불리합니다. 💡 이 문제의 핵심 용어 Wildcard Certificate (와일드카드 인증서): 하나의 인증서로 *.example.com에 속한 모든 하위 도메인들을 한꺼번에 보호하는 가성비 인증서 DNS Validation (DNS 유효성 검사): 도메인 설정값(CNAME)을 통해 내가 주인임을 인증하는 방식으로, 자동 갱신이 지원됨 ACM (AWS Certificate Manager): SSL/TLS 인증서 발급과 갱신을 무료(공통)로 해주는 아주 유용한 보안 비서
Q645 회사의 귀중한 암호 키를 법률 때문에 반드시 회사 전산실(온프레미스) 장비에만 둬야 합니다. 그래도 AWS 서비스에서 그 키를 쓰고 싶다면 어떤 기술을 쓸까요? CloudHSM이라는 비싼 물리 장비를 AWS 안에 따로 설치합니다. AWS KMS의 '외부 키 저장소(XKS)' 기능을 써서 사무실 장비와 AWS를 연결합니다. 그냥 AWS가 주는 기본 관리형 키 저장소를 믿고 사용합니다. 조금 저렴한 사용자 지정 키 저장소를 만들어 우리만의 암호 규칙을 정합니다. 정답 확인 및 해설 📖 해설 정답은 B입니다. '외부 키 저장소(XKS)'는 AWS의 보안 자물쇠(KMS)를 쓰긴 하되, 실제 금고 열쇠는 회사 내부(온프레미스) 장비에 두는 기술입니다. AWS는 열쇠를 직접 보관하지 않고 필요할 때만 회사 장비에 물어보게 되므로, 가장 까다로운 규제 요건까지 만족시킬 수 있습니다. 다른 옵션인 A(CloudHSM)는 열쇠가 AWS 데이터 센터 안에 있게 되므로 'AWS 클라우드 외부 보관'이라는 조건을 만족하지 못합니다. 💡 이 문제의 핵심 용어 AWS KMS External Key Store (XKS): AWS 외부의 전산실(HSM 등)에 보관된 키를 사용하여 AWS 리소스를 암호화하는 가장 높은 보안 수준의 기술 HSM (Hardware Security Module): 암호 키를 해킹으로부터 물리적으로 완벽히 격격하여 보관하는 전용 보안 하드웨어 Compliance (규제 준수): 법이나 회사 내규에 따라 데이터를 안전하게 관리해야 하는 전산 관습
Q646 수백 개의 서버가 엄청난 데이터를 동시에 훑으며 초고성능 계산(HPC)을 해야 합니다. 1ms 미만의 광속 응답이 필요하고 결과는 S3에 담아야 할 때 최적은? 리눅스용 EFS 공유 드라이브를 만들어 수천 대를 다닥다닥 연결합니다. S3 버킷을 각 서버에 드라이브처럼 마운트해서 직접 쓰고 읽습니다. HPC 끝판왕인 'Amazon FSx for Lustre'를 쓰고 S3 버킷과 영혼의 단짝으로 묶어둡니다. Resource Access Manager를 써서 계정 간의 복잡한 공유 설정을 수동으로 잡습니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 수백 대의 노드가 병렬로 동시에 달려드는 HPC(슈퍼컴퓨팅) 작업에는 'Lustre'라는 파일 시스템이 전 세계 표준입니다. AWS의 FSx for Lustre는 S3와 실시간으로 연결되어 데이터를 가져오고, 계산이 끝나면 다시 결과를 S3로 쏴주는 기능이 아주 강력해 전문가들이 가장 선호합니다. 다른 옵션인 A(EFS)는 일반적인 파일 공유에는 좋지만, 1ms 미만의 극적인 성능 요구와 대규모 병렬 계산(HPC)에는 Lustre에 비해 힘이 부칩니다. 💡 이 문제의 핵심 용어 Amazon FSx for Lustre: 수천 대의 서버가 동시에 데이터에 달려들어 계산할 수 있게 돕는 초고성능 HPC용 파일 시스템 HPC (High Performance Computing): 기상 예측이나 신약 개발처럼 슈퍼컴퓨터를 써야 할 정도의 방대한 계산 작업 Parallel Processing (병렬 처리): 하나의 큰 숙제를 여러 명이 동시에 쪼개서 수행해 시간을 획기적으로 줄이는 방법
Q647 전 세계 레이턴시 0.1초가 아쉬운 글로벌 게임의 VoIP(음성 채팅) 서버를 운영하려 합니다. 리전 장애 시 즉시 복구되면서 IP 캐싱 문제도 없는 마법의 장치는? 상태 확인 기능이 탑재된 'AWS Global Accelerator'를 전격 투입합니다. Route 53에서 지리적 위치 라우팅을 쓰고 사용자들이 주소를 갱신하길 기도합니다. CloudFront 배포를 하나 만들고 모든 게임 데이터를 그쪽으로 억지로 태웁니다. 경로 기반 라우팅을 쓰는 ALB 로드 밸런서로 지역마다 정성껏 안내합니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. 'Global Accelerator'는 전 세계 AWS 전용망 입구(Edge)에 2개의 고정된 애니캐스트(Anycast) IP 주소를 줍니다. 사용자는 가장 가까운 AWS 입구로 들어가서 전용 광랜을 타고 서버로 가기 때문에 인터넷 정체가 없고, 서버 리전에 장애가 나면 0.1초 만에 다른 리전으로 손님들을 옮겨주어 주캐싱 문제도 해결합니다. 다른 옵션인 B(Route 53)는 DNS 방식이라, 통신사가 IP 주소를 옛날 걸로 기억(Caching)하고 있으면 장애 시에도 손님이 계속 죽은 서버로 가려고 해서 문제 해결이 늦습니다. 💡 이 문제의 핵심 용어 AWS Global Accelerator: 전 세계 사용자의 트래픽을 AWS 전용망을 통해 최단 경로로 인도하고 장애 시 즉시 경로를 바꿔주는 가속 서비스 VoIP (Voice over IP): 인터넷망을 이용해 실시간으로 목소리를 주고받는 기술. 지연 시간에 매우 예민함 Anycast IP: 전 세계 어디서 접속하든 가장 가까운 AWS 관문으로 연결되는 마법의 통일된 IP 주소
Q648 일기 예보를 위해 수천 대의 서버가 수백 GB 데이터를 동시에 들락날락하며 계산합니다. 1ms 미만 속도와 내구성까지 갖춘 '영구적' 슈퍼 컴퓨팅 저장소는? 임시 사용 후 지워지는 FSx for Lustre '스크래치(Scratch)' 모드를 씁니다. 데이터가 보존되고 속도도 광속인 'FSx for Lustre 퍼시스턴트(Persistent)' 모드를 선택합니다. EFS 저장소의 버스팅 모드를 켜서 간헐적으로만 속도를 높입니다. EFS 프로비저닝된 처리량 모드를 써서 일정한 돈을 내고 속도를 고정합니다. 정답 확인 및 해설 📖 해설 정답은 B입니다. 수천 대의 서버가 동시에 붙는 예보 시스템에는 Lustre 파일 시스템이 딱입니다. 특히 'Persistent(지속형)' 모드를 쓰면, 계산 중에 서버 한두 대가 죽어도 데이터가 날아가지 않고 안전하게 보관되므로 며칠씩 걸리는 예보 작업을 안심하고 돌릴 수 있습니다. 다른 옵션인 A(Scratch)는 일시적인 연산용이라 한 대만 고장 나도 데이터가 다 날아갈 수 있어 '영구 저장' 요건에 맞지 않습니다. 💡 이 문제의 핵심 용어 Persistent (퍼시스턴트/지속형): 데이터가 사라지지 않고 하드디스크에 영구적으로 안전하게 기록되는 상태 Throughput (처리량): 통로를 통해 한 번에 얼마나 많은 데이터를 흘려보낼 수 있는지를 나타내는 척도 Sub-millisecond Latency: 0.001초 미만의 눈 깜빡임보다 수천 배 빠른 응답 속도
Q649 PostgreSQL(RDS) 서버를 운영하는데, 하드디스크 용량은 작아도 좋은데 '입출력 속도(15,000 IOPS)'만큼은 무조건 보장받고 싶을 때 가성비 갑 선택은? 이전 세대인 범용 SSD(gp2)를 고수하며 억지로 용량을 확 키워 속도를 맞춥니다. 최고 사양인 프로비저닝된 IOPS(io1)를 써서 가장 비싸게 속도를 삽니다. 최신 가성비 모델인 '범용 SSD(gp3)'를 선택하고 IOPS만 15,000으로 따로 조절합니다. 값싼 마그네틱 테이프 방식을 쓰면서 속도가 나오길 기원합니다. 정답 확인 및 해설 📖 해설 정답은 C입니다. 최신형 EBS인 gp3는 '용량'과 '속도(IOPS)'를 따로 떼어서 살 수 있는 혁신적인 녀석입니다. 용량은 조금만 사고 속도만 15,000으로 높이면, 비싼 io1 볼륨보다 훨씬 저렴한 가격에 똑같은 쾌적함을 누릴 수 있어 가성비 끝판왕으로 불립니다. 다른 옵션인 A(gp2)는 속도를 높이려면 용량도 같이 뻥튀기해서 사야 하므로 불필요한 비용이 나갑니다. 💡 이 문제의 핵심 용어 Amazon EBS GP3: 성능(IOPS)을 용량과 상관없이 독립적으로 업그레이드할 수 있는 최신 가성비 SSD IOPS (Input/Output Operations Per Second): 하드디스크가 초당 얼마나 많은 읽기/쓰기 작업을 처리할 수 있는지 나타내는 성능 지표 Cost-effective (비용 효율적): 적은 돈으로 최대의 효과를 내는 '가성비'가 좋다는 뜻
Q650 온프레미스 SQL Server를 AWS로 옮기려는데, 운영 서버 한 대로 손님도 받고 분석팀 보고서도 뽑으니 너무 힘들어합니다. 관리 수고 없이 짐을 덜어주는 비책은? RDS SQL Server로 옮기고, 보고서용 전용 '읽기 복제본(Read Replica)'을 만듭니다. EC2 서버에 직접 SQL Server를 깔고 복잡한 Always-on 복제 설정을 수동으로 잡습니다. NoSQL인 DynamoDB로 강제 개종하여 분석 대용량 작업을 처리하게 합니다. 엔진 자체를 Aurora MySQL로 완전히 바꿔서 마이그레이션 모험을 떠납니다. 정답 확인 및 해설 📖 해설 정답은 A입니다. 가장 편한 방법은 관리형 서비스인 RDS를 쓰는 것입니다. RDS SQL Server는 '읽기 전용 복제본'을 버튼 클릭 몇 번으로 만들 수 있어, 주 서버는 장사를 하고 조수 서버(복제본)는 보고서를 뽑는 식으로 역할을 분담해 성능과 운영 효율이라는 두 마리 토끼를 다 잡을 수 있습니다. 다른 옵션인 B는 서버를 직접 관리해야 하므로 '운영 오버헤드 최소화'라는 조건에서 탈락입니다. 💡 이 문제의 핵심 용어 Read Replica (읽기 전용 복제본): 주 데이터베이스의 데이터를 실시간으로 복사해 오직 조회용 업무만 전담하는 보조 서버 Amazon RDS for SQL Server: 윈도우용 주력 DB인 SQL Server의 설치, 백업, 복제를 AWS가 대신 해주는 서비스 Transactional (트랜잭션): 구매, 조회 등 앱에서 일어나는 실제 비즈니스 기록 행위