AWS SAA C03 연습 문제 (226~250번)

정답은 A와 E입니다. 수백만 개의 장치에서 쏟아지는 대량의 데이터를 수동으로 서버(EC2)를 늘려 받는 것은 운영상 재앙에 가깝습니다. 대신 관리형 서비스인 API Gateway로 요청을 받고, 이를 Kinesis Data Streams라는 데이터 고속도로에 태운 뒤, Firehose라는 자동 배달부를 통해 S3에 착륙시키는 구조(E)가 훨씬 확장성 있고 관리가 편합니다. 이렇게 저장된 원시 데이터는 서버를 띄울 필요 없는 서버리스 ETL 도구인 AWS Glue(A)를 사용하여 깔끔하게 가공하면 전체 시스템의 운영 오버헤드를 획기적으로 낮출 수 있습니다. 다른 옵션인 B와 C는 여전히 관리 포인트가 많은 EC2 서버 기반이라 '운영 오버헤드 최소화'라는 목표에 어긋나며, D 역시 대규모 트래픽 상황에서 EC2 관리 부담을 완전히 털어내지 못합니다.

정답은 B입니다. 범인은 바로 '버전 관리(Versioning)'입니다. S3 버킷에 버전 관리가 켜져 있으면, 파일이 삭제되어도 '삭제 마커'가 붙은 채로 예전 기록(이전 버전)들이 창고 구석에 고스란히 남게 됩니다. 단순히 현재 파일을 지우라는 정책만으로는 이 유령 같은 이전 버전들을 없앨 수 없습니다. 따라서 수명 주기 정책 설정에서 '이전 버전 만료' 항목을 체크하여 3년이 지난 과거 버전들까지 싹 정리하도록 수정해야 합니다. 다른 옵션인 A는 S3의 물리적 저장 상태를 해결해주지 못하며, C는 이미 S3 자체 기능으로 가능한 일을 어렵게 코딩하는 낭비입니다. D 역시 데이터 삭제 로직과는 전혀 관련이 없는 권한 설정일 뿐입니다.

정답은 C입니다. 데이터베이스가 힘들어하는 이유는 '동시에 너무 많은 손님(연결)이 한꺼번에 들이닥쳐서'입니다. 이때 SQS라는 입국 심사 대기줄을 만들면 좋습니다. API는 DB를 직접 건드리지 않고 SQS에 데이터를 휙 던져놓기만 하면 임무 완료입니다. 그러면 람다 일꾼이 DB가 소화할 수 있는 속도로 대기열에서 하나씩 꺼내 차곡차곡 집어넣게 되어, DB 연결 수도 줄어들고 아무리 트래픽이 몰려도 데이터가 버려지지 않습니다. 다른 옵션인 A는 임시방편일 뿐이며 비용이 많이 듭니다. B는 Aurora가 아닌 일반 RDS의 경우 쓰기 분산이 어렵고, D의 SNS는 '방송' 서비스라 데이터를 차례대로 줄 세워 DB에 넣는 버퍼 역할로는 적합하지 않습니다.

정답은 A입니다. 기존 MySQL 환경을 유지하면서 운영의 고통에서 벗어나는 최선의 선택은 Aurora Serverless입니다. 이 서비스를 이용하면 더 이상 '서버 사양을 얼마로 할까' 고민할 필요가 없습니다. 손님이 많으면 알아서 고성능으로 변신하고, 손님이 없으면 비용을 아끼기 위해 스스로 작아집니다. 복제와 고가용성 관리도 AWS가 알아서 다 해주니 운영자는 이제 발 뻗고 잘 수 있습니다. 다른 옵션인 B는 데이터베이스 종류가 바뀌어 코드 수정이 필요할 수 있고, C는 확장의 한계가 명확하며 돈 낭비가 심합니다. D는 DB 서버의 상태값 전이(복제 동기화 등)를 오토 스케일링으로만 해결하려다 데이터가 꼬일 수 있는 위험한 방식입니다.

정답은 C입니다. 예전 방식인 NAT 인스턴스는 우리가 서버를 직접 관리해야 해서 번거롭고 확장도 어렵습니다. 반면 'NAT 게이트웨이'는 AWS가 관리해주는 바구니 같은 서비스로, 초당 최대 45Gbps까지 알아서 확장됩니다. 특히 서로 다른 가용 영역(AZ)에 하나씩 두어야 한쪽 데이터 센터에 불이 나도 다른 쪽을 통해 인터넷 연결이 유지되는 진정한 고가용성을 확보할 수 있습니다. 다른 옵션인 A는 한 AZ가 무너지면 끝장이라 위험하고, B와 D는 여전히 우리가 관리해야 할 '서버(인스턴스)'가 남아 있어 운영 부담과 관리 포인트가 사라지지 않습니다.

정답은 B입니다. 두 네트워크(VPC)를 하나처럼 묶어주는 가장 표준적인 방법은 VPC 피어링입니다. 이를 설정하면 내부망(Private IP)으로만 트래픽이 흐르게 되어 보안상 매우 안전하며, 성능도 마치 같은 네트워크에 있는 것처럼 빠릅니다. 인터넷 게이트웨이를 통과할 필요조차 없으므로 해킹 위험도 현저히 낮아집니다. 다른 옵션인 A와 C는 귀중한 데이터가 담긴 DB를 공용 인터넷에 노출해야 하므로 보안팀에서 당장 달려올 위험한 설계입니다. D는 관리가 복잡할 뿐만 아니라 성능 저하와 장애 포인트만 늘리는 비효율적인 방식입니다.

정답은 C입니다. 네트워크에 누가 들어오고 나가는지를 가장 정확하게 기록하는 장부는 'VPC 흐름 로그'입니다. 모든 통신 기록이 남기 때문에, 여기서 RDP(3389)나 SSH(22) 포트로 트래픽이 발생하는 순간을 포착하는 메트릭 필터를 걸어두면 됩니다. 이 필터가 반응할 때 SNS를 통해 알림을 쏘게 설정하면, 관리자가 서버에 발을 들이는 즉시 운영팀에 문자가 가게 됩니다. 다른 옵션인 A와 B는 앱 내부나 인스턴스 관리에 집중되어 있어 '네트워크 접근' 자체를 실시간으로 낚아채기에 부족합니다. D는 서버가 켜지는 것만 알 뿐, 실제로 누군가 원격 접속을 시도했는지는 알 수 없습니다.

정답은 A와 B입니다. 루트 사용자는 모든 것을 할 수 있는 왕과 같습니다. 보안의 제1 원칙은 이 '왕의 권한'을 최대한 사용하지 않는 것입니다. 먼저 추측 불가능한 강력한 비번을 걸고(A), OTP 기기나 폰 앱을 통한 MFA(B)를 걸어서 비번이 유출되더라도 로그인을 막아야 합니다. 그 후엔 별도의 IAM 사용자를 만들어 일상 업무를 보고 루트 계정은 금고에 깊숙이 넣어둬야 합니다. 다른 옵션인 C는 루트 계정의 액세스 키를 만드는 것 자체가 보안상 금기 사항입니다. D와 E는 이미 모든 권한을 가진 루트 사용자에게는 아무런 의미가 없는 작업이며, 오히려 관리 포인트만 늘리는 셈입니다.

정답은 C입니다. AWS에서 '유휴 데이터' 암호화의 표준은 KMS입니다. EBS 하드디스크나 Aurora DB를 만들 때 KMS 키를 선택만 하면 저장되는 순간 암호화가 됩니다. '전송 중 데이터'는 HTTPS 통신이 필수인데, 이때 ACM(인증서 관리자)에서 무료로 발급받은 인증서를 ALB 로드 밸런서에 붙여주기만 하면 손님과 서버 사이의 모든 대화가 안전하게 암호화됩니다. 다른 옵션인 A는 도구의 용도를 거꾸로 말하고 있어 틀렸고, B는 그런 마법 같은 단 하나의 체크박스는 존재하지 않습니다. D는 클라우드 시대에 어울리지 않는 엄청난 운영 노가다와 추가 비용을 유발합니다.

정답은 C입니다. 오라클과 PostgreSQL은 서로 말이 안 통하는 외국인과 같습니다. 먼저 SCT(설계도 변환 도구)를 써서 DB 구조를 번역해야 합니다. 그 후 데이터를 옮길 때는 DMS(데이터베이스 마이그레이션 서비스)를 쓰는데, '전체 로드'로 기존 데이터를 넘기고 'CDC(변경 데이터 캡처)' 기능으로 새로 들어오는 수정사항을 실시간으로 따라잡게 만들어야 합니다. 이때 성능 저하 없이 대량의 데이터를 소화하려면 메모리가 넉넉한 DMS 서버를 쓰는 것이 고수의 선택입니다. 다른 옵션인 A와 B의 DataSync는 단순 파일 복사용이지 DB 내부의 복잡한 트랜잭션을 따라잡기엔 역부족입니다. D는 일부 데이터만 옮기기 때문에 전체 동기화라는 목표를 달성할 수 없습니다.

정답은 D입니다. '최소한의 코드 변경'으로 고가용성을 얻으려면 Elastic Beanstalk가 최고입니다. 서버 운영(OS 업데이트, 로드 밸런싱 등)을 대신 해주기 때문입니다. 여기에 데이터베이스는 RDS의 '다중 AZ' 기능을 켜서 한쪽 센터가 무너져도 1~2분 안에 복구되게 하고, 용량이 크고 변하지 않는 이미지는 무제한 저장소인 S3에 따로 보관하는 것이 클라우드 아키텍처의 정석입니다. 다른 옵션인 A는 앱 코드를 완전히 새로 짜야 해서 부담이 크고, B는 DB의 읽기 성능은 좋지만 쓰기 장애 시 대응이 늦습니다. C는 여전히 운영자가 서버 인프라를 직접 챙겨야 할 부분이 많아 효율이 떨어집니다.

정답은 A입니다. VPC 피어링은 계정이 달라도 같은 지역(리전)에 있다면 클릭 몇 번으로 둘을 하나처럼 묶어줍니다. 별도의 장비(VPN 등)를 거치지 않고 AWS의 내부 고속 전용 통로를 타기 때문에 성능 저하나 대역폭 제한 걱정이 거의 없습니다. 단일 장애 지점(Single Point of Failure)도 없으니 '안 끊기고 빠른' 이번 요구 사항에 딱 맞는 정답입니다. 다른 옵션인 B의 엔드포인트는 S3나 DynamoDB 같은 특정 서비스를 위한 것이지 서버 대 서버 연결용이 아닙니다. C는 VPN 장비 자체의 성능 한계와 설정의 복잡함이 있고, D는 본래 온프레미스와 연결할 때 쓰는 비싼 기술이라 계정 간 연결에는 과한 선택입니다.

정답은 C입니다. 돈 문제를 가장 확실히 감시하는 수문장은 AWS Budgets입니다. 단순히 전체 비용뿐만 아니라 'EC2만 콕 집어서' 혹은 '특정 태그가 붙은 것만' 예산을 정해둘 수 있습니다. 예상 금액이나 실제 사용액이 설정한 임계값(예: 80%)을 넘으면 즉시 SNS로 문자를 주도록 설정할 수 있어, 요금 폭탄이 터지기 전에 미리 대처할 수 있는 최고의 도구입니다. 다른 옵션인 A와 B는 이미 돈이 다 나간 뒤에 확인하는 '소 잃고 외양간 고치기' 식이고, D는 고작 예산 알림 하나 받으려고 너무 큰 개발 공수를 들이는 배보다 배꼽이 더 큰 방식입니다.

정답은 A입니다. 단순히 주소만 필요한 게 아니라 '인증과 관리'가 필요할 때는 API Gateway가 왕입니다. REST API 방식을 선택하면 IAM 인증 기능을 클릭 한 번으로 활성화할 수 있을 뿐만 아니라, 나중에 요청이 폭주해도 알아서 막아주는(Throttling) 기능이나 주소 관리 기능까지 한꺼번에 얻을 수 있습니다. 운영자가 일일이 코딩하지 않아도 보안 요건을 완벽히 충족합니다. 다른 옵션인 B는 정말 단순한 호출용이지 기업용 서비스로 관리하기엔 기능이 부족하고, C와 D는 '에지(Edge) 위치'라는 특수한 환경에서 돌아가는 서비스라 일반적인 마이크로서비스 배포용으로는 복잡성만 키울 뿐입니다.

정답은 D입니다. AWS 요금 체계에서 가장 비싼 것 중 하나가 'AWS 밖으로 나가는 데이터(Egress)' 비용입니다. 50MB씩 수천 번 나가는 걸 막으려면, 결과 값을 보여주는 '시각화 서버'를 데이터 창고(Redshift) 바로 옆인 AWS 안에 두어야 합니다. 그러면 50MB는 내부망(무료 또는 저렴)으로 이동하고, 본사 사람들에게는 가공된 가벼운 화면 정보(500KB)만 전용선을 타고 전송되므로 전체 송신 비용이 획기적으로 줄어듭니다. 다른 옵션인 A, B, C는 여전히 50MB라는 무거운 데이터를 리전 밖으로 내보내야 하므로, 인터넷 비용이든 전용선 비용이든 결국 비싼 요금 청구서를 받게 됩니다.

정답은 C입니다. '여러 리전에서 온라인 사용'이라는 요건을 충족하려면 지역 간 복제가 필수입니다. RDS의 읽기 전용 복제본 기능을 쓰면, 메인 지역(한국)에 데이터를 쓰는 즉시 다른 지역(미국, 유럽 등)의 복제 DB로 내용이 전달됩니다. 그쪽 지역 사람들은 자기 근처의 DB에서 데이터를 빠르게 읽을 수 있고, 한국 지역에 큰 장애가 나도 복제본을 메인으로 승격시켜 서비스를 이어갈 수 있습니다. 다른 옵션인 A는 서버 관리가 너무 힘들고, B의 다중 AZ는 한 지역 안에서의 장애만 막아줄 뿐 리전 전체 장애에는 속수무책입니다. D는 실시간이 아닌 '과거 데이터'만 복구하는 방식이라 항상 온라인 사용이라는 요건에 맞지 않습니다.

정답은 C입니다. 다중값 응답 정책은 로드 밸런서(ALB) 없이도 여러 서버에 부하를 나누는 가장 원시적이면서도 강력한 방법입니다. Route 53에 7대 서버 아이피를 다 등록해두면, 손님의 쿼리에 대해 정상인 녀석들의 아이피를 최대 8개까지 무작위로 골라 응답해줍니다. 장애가 난 서버는 상태 확인(Health Check)을 통해 알아서 명단에서 제외하니 안심하고 쓸 수 있습니다. 다른 옵션인 A는 고정된 결과만 주고, B는 가장 빠른 서버만 추천하며, D는 접속자의 국가에 따라 다른 서버를 알려주는 정책이라 '모든 정상 아이피 반환'이라는 목표와는 방향이 다릅니다.

정답은 A입니다. 파일 게이트웨이는 '구식 파일 서버(NFS/SMB)'와 '최첨단 S3 창고' 사이를 이어주는 가교입니다. 진료소 직원은 자기네 익숙한 폴더에 파일을 넣고 빼는 것처럼 쓰지만, 실제 데이터는 S3에 보관됩니다. 특히 자주 쓰는 파일은 진료소 내부 장비인 VM(파일 게이트웨이)에 '캐시'로 저장해두므로 인터넷 속도와 상관없이 빛의 속도로 읽을 수 있습니다. 다른 옵션인 B는 실시간성이 떨어지고 관리가 복잡하며, C는 '파일' 단위 접근이 아닌 '블록' 단위라 이번 용도에 맞지 않습니다. D의 EFS는 전용선 없는 상태에서 전국 규모로 연결하기엔 성능 이슈와 설정 난이도가 너무 높습니다.

정답은 C입니다. 진정한 고가용성은 '자동화'와 '분산'에서 나옵니다. 데이터베이스는 죽지 않는 Aurora를 쓰고, 웹 서버는 이미지를 떠서(AMI) 오토 스케일링 그룹에 담아야 합니다. 여기에 로드 밸런서(ALB)가 두 지역(AZ)에 손님을 나눠주게 설정하면, 서버 한 대가 죽거나 심지어 데이터 센터 하나가 통째로 정전이 되어도 서비스는 중단 없이 계속됩니다. 다른 옵션인 A와 B는 '수동으로 서버를 띄운다'는 점에서 확장성이 부족하고 사람의 실수가 개입될 여지가 큽니다. D는 DB를 여전히 우리가 관리해야 할 '서버' 형태로 두었기에 관리 부담과 장애 위험을 완전히 떨쳐내지 못했습니다.

정답은 A입니다. 개발 환경은 내부 직원들만 테스트용으로 쓰기 때문에 굳이 여러 대의 서버를 띄워 고가용성을 유지할 필요가 없습니다. 로드 밸런서 뒤에서 일하는 서버 숫자를 1대로 줄여버리는 것이 가장 직접적이고 확실한 돈 절약 방법입니다. 서버 대수 자체가 줄어드니 월세(EC2 비용)가 반토막 이상으로 줄어듭니다. 다른 옵션인 B는 일하는 방식만 바꾸는 거지 서버 월세는 똑같이 나가고, C는 운영 환경의 성능까지 낮춰버려 실제 서비스에 지장을 줍니다. D는 손님이 몰릴 때의 상한선만 정하는 거지 평소 나가는 기본 요금을 줄여주지는 못합니다.

정답은 D입니다. 인터넷 로드 밸런서(ALB)는 반드시 '퍼블릭 서브넷'에 발을 걸치고 있어야 외부 손님의 요청을 받을 수 있습니다. 하지만 실제 데이터를 다루는 서버는 '프라이빗 서브넷'에 숨겨두는 것이 보안의 정석입니다. 따라서 ALB만 햇볕이 드는 퍼블릭 서브넷으로 옮기고, 거기서 프라이빗 서브넷에 있는 서버로 트래픽을 쏙 쏴주도록 라우팅을 잡으면 보안과 소통이라는 두 마리 토끼를 다 잡게 됩니다. 다른 옵션인 A는 로드 밸런서 종류를 바꿔도 위치 문제가 해결되지 않으면 똑같고, B는 보안을 포기하는 행위입니다. C는 프라이빗 서버가 직접 인터넷에 노출되어 해킹의 표적이 되기 쉬운 위험한 구성입니다.

정답은 C와 E입니다. 복제본을 만드는 원리는 '현재 상태의 사진(스냅샷)'을 찍어 옆동네에 똑같은 DB를 굽는 것입니다. 그러려면 일단 AWS가 자동으로 사진을 찍을 수 있게 '자동 백업'이 켜져 있어야 합니다(E). 또한 사진 찍는 도중에 데이터가 계속 바뀌면 사진이 흔들릴 수 있으니, 진행 중인 무거운 작업들은 다 끝난 뒤에 시작하는 것이 안전합니다(C). 다른 옵션인 A는 RDS가 내부적으로 알아서 하는 영역이며, B는 고가용성(Multi-AZ) 승격 문제지 단순히 읽기용 복제본을 만드는 조건은 아닙니다. D의 글로벌 테이블은 DynamoDB 전용 용어라 MySQL과는 어울리지 않습니다.

정답은 D입니다. 서버가 '나 죽겠다'고 비명을 지르면, 일단 일감을 길에 쏟지 말고 안전한 바구니(SQS)에 담아두어야 합니다. 그러면 서버가 감당 못 할 만큼 요청이 쏟아져도 일단 바구니에 보관되니 유실은 사라집니다. 여기에 바구니에 쌓인 일의 양(대기열 크기)을 보고 서버 대수를 늘려주는 오토 스케일링을 붙이면, 손님이 많을 땐 서버가 일제히 달려들고 적을 땐 퇴근하는 아주 유연하고 경제적인 시스템이 됩니다. 다른 옵션인 A는 S3에서 직접 쏘는 요청(이벤트)을 받기엔 부적절하고, B는 네트워크 통로만 넓힐 뿐 서버의 연산 한계를 해결해주진 못합니다. C는 확장의 한계가 있고 손님이 없을 때도 비싼 월세를 내야 합니다.

정답은 D입니다. 윈도우용 공유 폴더(SMB)가 필요하다면 'FSx for Windows'가 정답입니다. 이건 우리가 윈도우 서버를 직접 조립할 필요 없이, AWS가 미리 다 만들어 놓은 '완성된 공유 하드' 서비스입니다. 보안, 백업, 확장까지 버튼 하나로 다 되니 운영 노가다가 가장 적고 신뢰성도 높습니다. 다른 옵션인 A는 온프레미스와 연동할 때나 쓰는 기술이고, B는 예전 영화관 테이프처럼 장기 보관용이라 실시간 파일 공유와는 거리가 멉니다. C는 서버 설치부터 업데이트까지 우리가 다 해야 해서 '완전 관리형'이라는 목표에 탈락입니다.

정답은 D입니다. VPC 흐름 로그는 곧바로 S3로 던질 수 있습니다. S3는 장기 보관에 최적화되어 있고 수명 주기 정책(Lifecycle Policy)이 매우 강력합니다. 처음 90일은 언제든 빨리 볼 수 있는 Standard 등급에 두고, 90일이 지나는 순간 '자주 안 보는 등급(Standard-IA)'으로 옮기라고 규칙만 정해두면 성능과 비용이라는 두 마리 토끼를 다 잡게 됩니다. 다른 옵션인 A는 90일 후에 로그가 영원히 사라져버려 '간헐적 액세스' 요건을 못 지키고, B는 스트리밍용이지 보관용이 아닙니다. C는 API 로그용 도구를 굳이 거쳐가는 불필요하게 복잡한 방식입니다.