AWS SAA C03 연습 문제 (451~475번)

정답은 B, C, F입니다. AWS 공동 책임 모델에 따라 AWS는 '클라우드 자체의 보안(물리 시설, 하드웨어)'을 책임지고, 고객은 '클라우드 내에서의 보안(데이터, 설정)'을 책임집니다. 하드웨어나 OS 관리는 AWS가 해주지만, 어떤 DB를 띄울지(B), 내 서비스에 필요한 보안 소프트웨어를 깔지(C), 그리고 전용선을 타고 흐르는 소중한 데이터를 암호화할지(F)는 전적으로 우리 운영팀의 몫입니다. 다른 옵션인 A, D, E는 AWS가 관리해주는 영역이므로 고객이 직접 할 필요가 없거나 할 수 없는 일들입니다.

정답은 B입니다. 1시간에 딱 10초만 일하는 작업은 서버를 켜두는 것 자체가 낭비입니다. Lambda는 코드가 실행되는 '밀리초' 단위로만 요금을 내기 때문에 이런 간헐적 작업에 축복과도 같은 서비스입니다. 넉넉하게 메모리 1GB를 할당하고 EventBridge로 매시간 쿡 찔러주기만 하면, 남은 59분 50초 동안의 비용은 0원이 됩니다. 다른 옵션인 D처럼 서버를 껐다 켰다 하는 건 부팅 시간도 걸리고 관리가 매우 번거로우며, 초 단위 과금인 Lambda보다 비쌉니다.

정답은 D입니다. 데이터 변조 방지(WORM)를 위한 끝판왕은 AWS Backup의 '규정 준수 모드 볼트 잠금'입니다. 이 모드를 활성화하면 보존 기간이 끝나기 전에는 루트 사용자나 AWS 직원조차도 백업을 지울 수 없습니다. 거버넌스 모드는 특정 권한이 있으면 해제가 가능하지만, 규정 준수 모드는 법적 요구 사항을 충족하기 위한 불멸의 자물쇠를 채우는 것입니다. 다른 옵션들은 삭제 권한이 있는 관리자가 마음만 먹으면 지울 수 있는 구조라 '변조 불가' 조건을 완벽히 만족하기 어렵습니다.

정답은 C입니다. 복잡하게 얽힌 클라우드 자원을 한눈에 보고 싶을 때 쓰는 전용 도구가 'Workload Discovery on AWS'입니다. 계정과 리전을 싹 훑어서 서버, DB, 네트워크가 어떻게 연결되어 있는지 실시간으로 멋진 그림(다이어그램)을 그려줍니다. 운영자가 일일이 조사해서 그릴 필요가 없으니 운영 효율이 최고입니다. 다른 옵션인 A(Inventory)는 단순 목록만 보여줄 뿐 관계를 그려주지 않고, B와 D는 수작업 노력이 너무 많이 들어 '운영상 효율적'이지 않습니다.

정답은 B, D, F입니다. 단순히 돈이 나가는 걸 보는 게 아니라 '강제 차단'까지 하려면 'AWS Budgets Actions' 기능을 써야 합니다. 예산을 설정(B)하고, 그 예산이 넘었을 때 출동할 IAM 역할(D)에게 권한을 줍니다. 그리고 그 역할이 Organizations의 SCP를 해당 계정에 탁 붙여서(F) 추가적인 서버나 DB 생성을 원천 봉쇄하게 만드는 구조입니다. 다른 옵션인 A는 예산 설정 위치가 틀렸고, E는 구성 규칙만으로는 실시간 생성을 막기보다 사후 탐지에 가깝습니다.

정답은 C입니다. 중앙 집중 관리와 자동화를 한 번에 해결해주는 도구는 AWS Backup입니다. 백업 계획(Backup Plan) 하나만 잘 짜두면 알아서 스냅샷을 찍고, 전 세계 어디든 원하는 리전으로 복사본을 보내줍니다. 서버를 미리 켜둘 필요가 없으니 저장 비용만 내면 되어 매우 효율적입니다. 다른 옵션인 A와 D는 서버를 계속 켜두거나 전송용 자원을 써야 해서 비용이 많이 들고, B는 사람이 직접 해야 하므로 실수의 위험이 큽니다.

정답은 C입니다. AS2(Applicability Statement 2) 같은 특수 전송 프로토콜은 AWS Transfer Family가 전문입니다. SFTP, FTPS는 물론 AS2 전송까지 완벽히 지원하며, 백엔드에는 S3나 EFS를 연결할 수 있죠. 특히 사내 로그인 시스템과 연동할 때는 커스텀 ID 공급자(Custom IdP) 옵션을 통해 Lambda 함수로 인증 로직을 연결해주면 완벽한 보안 게이트웨이가 완성됩니다. 다른 옵션들은 AS2 프로토콜을 지원하지 않거나 파일 전송에 최적화된 도구가 아닙니다.

정답은 B와 C입니다. 가장 손이 안 가는(최소 관리 노력) 컴퓨팅은 서버 관리 없는 Lambda(B)입니다. Lambda는 최근 저장 공간 옵션(최대 10GB)도 늘어나서 2GB 정도는 거뿐합니다. 그리고 관계형 데이터를 다루는 데 최고의 관리형 서비스는 단연 RDS(C)입니다. 이 두 조합이면 개발자는 코드에만 집중하고 인프라 관리는 AWS에게 다 맡길 수 있습니다. 다른 옵션인 A(EC2)와 E(EKS)는 서버 패치부터 복잡한 환경 설정까지 운영자가 할 일이 너무 많습니다.

정답은 A입니다. 태그가 달려 있다고 해서 비용 보고서에 바로 나오는 건 아닙니다. 마스터(관리) 계정에서 \\\\\\\"이 태그를 비용 계산용으로 쓸 거야!\\\\\\\"라고 '비용 할당 태그(Cost Allocation Tag)'로 활성화해줘야 합니다. 특히 우리가 직접 붙인 태그는 '사용자 정의 태그'이므로 이를 활성화하면, 전 계정의 EC2 비용을 '부서' 이름별로 예쁘게 그룹화된 보고서로 바로 볼 수 있습니다. 다른 옵션인 B는 우리가 만든 태그에는 해당하지 않고, C는 사람이 고생하는 비효율적인 방식입니다.

정답은 C입니다. 외부 SaaS 앱(Salesforce, Slack, Google Analytics 등)과 AWS를 잇는 고속도로는 Amazon AppFlow입니다. 코딩 한 줄 없이 마우스 클릭만으로 데이터를 가져올 수 있고, 전송 중 암호화와 S3 저장 시 KMS 암호화까지 완벽하게 지원합니다. '최소한의 개발 노력'이라는 단어가 나오면 무조건 AppFlow를 떠올리세요. 다른 옵션들은 서버를 관리하거나 복잡한 코드를 직접 짜야 하므로 배보다 배꼽이 더 큰 상황이 됩니다.

정답은 B입니다. 게임에서 많이 쓰는 UDP 프로토콜과 글로벌 가속을 동시에 만족하는 건 'AWS Global Accelerator'와 'NLB'의 조합입니다. Global Accelerator는 전 세계 고정 IP를 제공해 지연 시간을 획기적으로 줄여주며, NLB는 L4 계층에서 TCP/UDP 트래픽을 빛의 속도로 분산해줍니다. 반면 ALB나 CloudFront는 기본적으로 HTTP나 TCP 기반이라 UDP 통신이 불가능하거나 제한적입니다. 다른 옵션인 A(ALB)와 C, D(CloudFront)는 UDP 트래픽 처리에 한계가 있어 게임용으로는 부적합합니다.

정답은 B입니다. 시스템 간의 충격을 완화하는 '완충지대'가 필요합니다. SQS(메시지 큐)는 주문이 1초에 수만 건이 들어와도 일단 다 받아줍니다. 그 뒤에서 서버들이 \\\\\\\"나는 1초에 10개씩 처리할 수 있어\\\\\\\"라며 자기 페이스대로 가져가면(Decoupling), 트래픽이 폭주해도 시스템이 뻗거나 주문이 유실되지 않습니다. 이것이 클라우드 아키텍처의 핵심인 '비동기 분산 처리'입니다. 다른 옵션인 A(SNS직결)는 DB에 너무 큰 충격을 한꺼번에 줘서 오히려 폭발할 수 있고, D는 관리가 너무 복잡해서 추천하지 않습니다.

정답은 C입니다. 파일 하나당 2MB는 데이터 세계에서 아주 '귀여운' 수준입니다. 이런 작은 일을 하는 데 Glue나 EMR 같은 거대 장비를 꺼내는 건 닭 잡는 데 소 잡는 칼을 쓰는 격입니다. Lambda는 1GB 메모리 설정 시 요금이 매우 저렴하고, 30초 내외의 작업이라면 거의 공짜에 가까운 비용으로 수천 명의 데이터를 처리할 수 있습니다. 다른 옵션들은 최소 비용 단위가 크거나 실행 준비(Cold Start) 시간이 길어서 이런 소규모 작업에는 비효율적입니다.

정답은 A입니다. RDS의 마법 같은 기능 중 하나입니다. 이미 가동 중인 '싱글 리전' DB라도 설정에서 '다중 AZ'만 클릭하면, AWS가 알아서 다른 데이터 센터에 복사본(대기 서버)을 만들고 데이터를 실시간 복제해줍니다. 접속 주소(Endpoint)는 그대로 유지되므로 앱 코드를 고칠 필요도 없고, 장애 시 자동으로 보조 DB가 메인이 되어 서비스 중단을 막아줍니다. 다른 옵션인 B는 불필요하게 서버를 새로 만드는 수고가 들고, C는 가용성보다는 읽기 성능 향상에 초점이 맞춰져 있습니다.

정답은 C입니다. EBS 볼륨은 원래 1:1 연결이 원칙이지만, 특별히 'Provisioned IOPS SSD(io1/io2)' 타입은 하나의 볼륨을 최대 16대의 서버가 동시에 연결할 수 있는 'Multi-attach' 기능을 제공합니다. 이를 통해 클러스터형 애플리케이션이나 고가용성 시스템을 구축할 수 있습니다. 우리가 흔히 쓰는 gp2, gp3 볼륨은 이 기능을 지원하지 않습니다. 다른 옵션들은 볼륨 한 개당 서버 한 대씩만 붙을 수 있는 일반적인 타사 제한이 있습니다.

정답은 A입니다. '고가용성'의 기본 공식입니다. 서버를 하나만 두지 말고, Auto Scaling 그룹에 넣어두면 서버가 고장 났을 때 자동으로 옆 동네(다른 가용 영역)에 새 서버를 띄워줍니다. 그리고 입구에 로드 밸런서(ALB)를 두면 사용자는 어느 데이터 센터의 서버가 일하고 있는지 신경 쓸 필요 없이 늘 일관된 주소로 접속할 수 있습니다. 다른 옵션인 B는 복구에 시간이 너무 많이 걸리고, C와 D는 장애 복구보다는 속도 개선에 가깝습니다.

정답은 B입니다. Organizations로 묶인 계정들은 기본적으로 예약 할인(RI)이나 세이빙스 플랜 혜택을 서로 나눠 가질 수 있습니다. 단, 이 권한은 조직의 대장인 '마스터 계정'이 제어합니다. 마스터 계정의 결제 설정에서 할인 공유를 승인하면, A 계정이 남긴 혜택을 바쁜 B 계정이 가져다 쓸 수 있어 조직 전체의 비용을 최적화할 수 있습니다. 다른 옵션인 D는 예약 인스턴스(RI)에만 해당하며 세이빙스 플랜은 판매가 불가능합니다.

정답은 B입니다. 프라이빗 서브넷(안전한 내부망)에 숨겨진 서버에 외부의 API 요청을 전달할 때는 'VPC Link'가 필수입니다. API Gateway가 전달자(Proxy) 역할을 수행하며, 'VPC Link'라는 전용 통로를 통해 내부망의 로드 밸런서나 ECS 서비스에 데이터를 넘겨줍니다. 사용자는 REST API라는 편한 문으로 들어오고, 서버는 안전하게 방벽 뒤에 숨어있을 수 있죠. 다른 옵션인 A와 C는 실시간 채팅용인 WebSocket을 제안하고 있어 일반적인 검색 서비스 요청에는 맞지 않습니다.

정답은 C입니다. 이름 그대로 인공지능급 센스를 가진 'Intelligent-Tiering'이 정답입니다. 이 옵션을 켜두면 S3가 파일 하나하나의 사용 패턴을 지켜보다가, 한 달 동안 아무도 안 본 파일은 자동으로 저렴한 창고로 옮기고, 다시 누군가 찾으면 즉시 원래 자리로 복귀시킵니다. 사용자가 예측할 수 없는 상황에서 운영 오버헤드 없이 돈을 아끼는 최고의 방법입니다. 다른 옵션인 B는 예측 불가능한 상황에서 갑자기 필요해진 파일을 꺼낼 때 추가 비용이 발생할 수 있어 위험합니다.

정답은 D입니다. IPv4 환경에서의 'NAT Gateway' 역할을 IPv6에서 수행하는 것이 바로 'Egress-only Internet Gateway'입니다. 말 그대로 'Egress(나가는 것)만' 허용하겠다는 뜻이죠. 우리 서버가 업데이트를 위해 외부 주소로 편지를 보낼 수는 있지만, 밖에서 우리 집 주소를 알고 먼저 초인종을 누르는 것은 물리적으로 차단되는 완벽한 일방통행 보안 장치입니다. 다른 옵션인 A(NAT Gateway)는 IPv4 전용이며, B는 밖에서도 들어올 수 있는 양방향 통로라 보안 규정에 어긋납니다.

정답은 C입니다. VPC 내부의 서버가 S3를 집 앞 골목길(내부망)처럼 쓰게 해주는 기술이 'VPC 엔드포인트'입니다. 특히 S3와 DynamoDB용으로 제공되는 '게이트웨이' 방식은 무료이며, 인터넷 게이트웨이나 NAT을 거치지 않아 데이터 전송 비용(Data Transfer)이 전혀 발생하지 않습니다. 보안과 가성비라는 두 마리 토끼를 잡는 표준 설계입니다. 다른 옵션인 D(인터페이스 엔드포인트)는 거의 모든 상황에서 유료이므로 '비용 최소화' 목적에는 무료인 게이트웨이 방식이 앞섭니다.

정답은 A입니다. DynamoDB 전용 터보 엔진이 바로 DAX입니다. DAX는 DynamoDB API를 그대로 이해하는 똑똑한 메모리 캐시라서, 개발자는 주소(Endpoint)만 DAX로 살짝 바꿔주면 별도의 캐시 동기화 로직을 짤 필요 없이 마이크로초 단위의 빛의 속도를 경험할 수 있습니다. 다른 옵션인 B는 DynamoDB에는 없는 기능(RDS 전용)이고, D는 캐시를 관리하고 데이터를 일치시키는 복잡한 코드를 직접 써야 해서 '최소한의 변경' 조건에서 탈락입니다.

정답은 A입니다. 정적 파일(이미지, 영상) 비용을 줄이는 공식은 '사용자 근처에서 해결하기'입니다. CloudFront(CDN)를 쓰면 이미지가 전 세계 엣지 서버에 복제됩니다. 사용자는 멀리 리전까지 올 필요 없이 바로 옆 동네에서 이미지를 받아가므로, 서버 부하는 물론 비싼 리전간 데이터 전송 요금까지 극적으로 아낄 수 있습니다. 다른 옵션인 B는 파일 전송용이 아닌 데이터 캐싱용이고, D는 관리 비용만 두 배로 늘어나는 악수가 됩니다.

정답은 C입니다. 네트워크의 중앙 허브 역할을 하는 것이 'Transit Gateway'입니다. 리전 내의 수많은 VPC를 이 허브(Transit Gateway)에 꽃기만 하면 그들끼리 알아서 통신이 됩니다. 또한 다른 리전의 허브와도 '피어링'으로 대화할 수 있어, 전 세계의 우리 망을 거대한 하나의 가상 네트워크로 관리할 수 있습니다. 피어링(A)을 일대일로 맺는 것보다 관리가 수만 배 편해집니다. 다른 옵션인 A는 연결 개수가 선형적으로 늘어나 관리가 불가능해지고, D는 관리가 너무 깐깐하고 설정이 어렵습니다.

정답은 C입니다. 컨테이너와 찰떡궁합인 '공유 파일 이름표'는 AWS EFS입니다. EFS는 가용 영역마다 접속 통로(Mount Target)를 만들어주어 리전 전체에서 편리하게 파일을 공유할 수 있고, 'AWS Backup' 서비스와 연동하면 다른 리전으로의 복제 관리도 매우 쉽습니다. 특히 ECS 서비스에서 기본적으로 지원하는 공유 스토리지라 설정이 가장 간단합니다. 다른 옵션인 FSx 시리즈들은 특정 운영체제(Windows 등)나 특수 목적용이라 범용적인 컨테이너 앱 공유 저장소로는 EFS가 가성비와 가용성 면에서 앞섭니다.