AWS SAA C03 연습 문제 (376~400번)

정답은 A입니다. 서버리스 앱(Lambda 등)은 필요할 때 수백, 수천 개가 동시에 실행되면서 DB 연결을 순식간에 고갈시키곤 합니다. 이때 RDS 프록시를 사용하면 프록시가 DB 연결을 미리 맺어두고 여러 요청이 이를 돌려쓰게(인텐트 풀링) 관리해줍니다. 운영자가 직접 서버를 관리할 필요 없이 클릭 몇 번으로 '연결 거부' 문제를 깔끔하게 해결할 수 있는 가장 효율적인 레이어입니다. 다른 옵션인 B(캐시)는 데이터 조회 속도는 높여주지만 근본적인 '연결 수' 부족 문제를 풀지는 못합니다. C(인스턴스 업그레이드)는 비용만 많이 들고 서버리스의 폭발적인 연결 속도를 따라가기엔 한계가 있으며, D(다중 AZ)는 장애 대비용이지 연결 관리를 분산해주는 장치는 아닙니다.

정답은 B입니다. 서버의 '탄생'과 '죽음'을 정확히 포착해서 특정 작업을 수행하고 싶을 때는 수명 주기 후크(Lifecycle Hook)가 정답입니다. 서버가 완전히 켜지기 전(Pending)이나 꺼지기 직전(Terminating)에 잠시 멈춤 상태로 두고, 감사 시스템에 보고하는 스크립트를 완벽히 실행한 뒤 다음 단계로 넘어가게 보장해줍니다. 자동화된 감사 시스템 구축에 있어 가장 신뢰할 만한 방식입니다. 다른 옵션인 A는 실시간성이 떨어지고 관리 포인트가 늘어납니다. C는 서버가 '종료'될 때의 보고를 놓치게 되며, D는 운영 체제와 Auto Scaling 간의 통신을 직접 구현해야 하므로 운영 비효율이 큽니다.

정답은 B입니다. 두 가지만 기억하면 됩니다. 'UDP'와 '비관계형 자동 확장'입니다. 먼저 UDP 프로토콜을 완벽하게 처리하며 수만 건의 연결을 안정적으로 배달하는 로드 밸런서는 NLB(Network Load Balancer)가 유일한 정답입니다. 그리고 관리자가 용량 설계를 일일이 할 필요 없이 트래픽에 맞춰 무한대로 커지는 NoSQL 데이터베이스는 DynamoDB 온디맨드(On-demand) 모드입니다. 이 조합이 게임 서비스에 가장 완벽한 짝궁입니다. 다른 옵션인 D(ALB)는 UDP를 지원하지 않고, A와 C(Aurora)는 관계형 DB라 '비관계형 데이터를 관리 개입 없이 저장'하려는 목적에는 DynamoDB보다 복잡하고 비용이 많이 듭니다.

정답은 B입니다. 람다가 처음 켜질 때 라이브러리를 로드하느라 굼뜬 현상을 '콜드 스타트(Cold Start)'라고 합니다. 이를 해결하는 가장 확실한 '치트키'가 바로 프로비저닝된 동시성(Provisioned Concurrency)입니다. 람다를 미리 따뜻하게 '예열'해두고 라이브러리까지 다 불러온 상태로 대기시키기 때문에, 요청이 오는 즉시 빛의 속도로 응답할 수 있습니다. 다른 옵션인 A는 보안상 매우 위험하고 아키텍처를 파괴하는 처사입니다. C는 캐시 구현 코드를 새로 짜야 해서 변경 사항이 많고, D는 DB 사양만 높일 뿐 람다의 초기 로딩 속도를 개선해주지는 못합니다.

정답은 D입니다. 매일 정해진 시각에 서버의 전원을 내리고 올리는 단순 반복 작업에는 '람다(Lambda) + 이벤트브릿지(EventBridge)' 조합이 가성비와 효율 면에서 최고입니다. 서버를 따로 관리할 필요 없이 코드만 몇 줄 올려두면, AWS 시계가 알람을 울려 람다 일꾼이 알아서 껐다 켰다 해줍니다. 인프라 유지 보수가 거의 없어 매우 경제적입니다. 다른 옵션인 A는 RDS 용량을 0으로 줄이는 기능이 없어 불가능합니다. B는 추가 비용이 들고, C는 관리용 서버를 따로 관리해야 하는 '배보다 배꼽이 큰' 상황이 발생합니다.

정답은 B입니다. 관계형 데이터베이스의 보고서 쿼리가 너무 무겁다면 원본(Master) 서버의 힘을 빌리지 말고 '읽기 전용 복제본'을 활용하는 것이 정석입니다. 특히 Aurora PostgreSQL은 복제본 생성이 빠르고 성능이 강력하여, 복제본에서 무거운 리포트 작업을 돌려도 실제 서비스 중인 메인 서버에는 아무런 지장을 주지 않습니다. 코드를 거의 안 고치고 엔드포인트(주소)만 바꿔주면 되니 효율적입니다. 다른 옵션인 A와 D는 DB 종류를 아예 바꿔야 해서 대공사가 필요하고, C인 RDS 다중 AZ의 대기 노드는 장애 대응용일 뿐 평소에는 쿼리 접속이 불가능합니다.

정답은 A입니다. 네트워크 선을 타고 데이터가 오갈 때 엿듣지 못하게 하는 '전송 중 보안'의 기본은 암호화(HTTPS/TLS)입니다. NLB(Network Load Balancer)가 서버 인증서를 들고 손님과 TLS 통신을 맺게 설정하면, 그 뒤에 있는 서버들까지 가는 모든 길이 암호화된 터널이 됩니다. 전송 중 보안 강화를 위해 가장 정석적이고 확실한 첫 단계입니다. 다른 옵션인 B와 C인 WAF는 데이터 암호화보다는 악성 공격 필터링에 가깝고, D인 EBS 암호화는 '보관 중(저장된) 데이터' 보안이지 네트워크 이동 중인 데이터 보안은 아닙니다.

정답은 A입니다. 코어 수나 소켓 기반의 기존 라이선스를 가져와야 한다면(BYOL), 가상 서버가 아닌 '물리 서버 전체'를 통째로 빌려 쓰는 Dedicated Host가 필수입니다. 여기에 장기 사용을 약속하고 '예약(Reserved)' 방식까지 선택한다면, 물리 서버 한 대를 통째로 쓰면서도 가장 저렴한 가격에 라이선스 규정까지 완벽히 준수할 수 있습니다. 다른 옵션인 C와 D(인스턴스)는 물리적 서버 정보를 제어하기 힘들어 코어 기반 라이선스를 적용하기 어렵고, B인 온디맨드는 예약 방식보다 가격이 훨씬 비쌉니다.

정답은 C입니다. 리눅스 서버 간의 파일 공유와 'POSIX 호환'이라는 조건이 나오면 정답은 Amazon EFS입니다. 여러 가용 영역(AZ)에 걸쳐 데이터를 복제하여 고가용성을 챙겨야 하므로 일반 Standard 모드가 적합하며, 비용 절감을 위해 자주 안 쓰는 파일은 자동으로 Standard-IA(Infrequent Access) 계층으로 보내는 수명 주기 수명 관리 기능을 쓰면 아주 알뜰하게 운영할 수 있습니다. 다른 옵션인 A와 B(S3)는 파일 시스템 형식이 아니라서 공유 드라이브처럼 쓰기엔 'POSIX 호환' 면에서 부족함이 있고, D인 One Zone은 데이터 센터 한 곳에만 저장하므로 '고가용성' 조건에 맞지 않습니다.

정답은 C입니다. 보안의 핵심은 '누구인지(보안 그룹 ID)'를 보고 문을 열어주는 것입니다. 웹 서버는 전 세계(0.0.0.0/0)에 문을 열 게 아니라, 오직 로드 밸런서라는 문지기를 거쳐온 신호만 받도록 LB의 보안 그룹 ID를 소스로 설정해야 합니다. DB 역시 마찬가지로 웹 서버의 보안 그룹 ID만 허용하면 됩니다. 이렇게 '보안 그룹 간의 참조'를 쓰면 IP 주소가 바뀌어도 알아서 관리되므로 운영 수고가 최소화됩니다. 다른 옵션인 A는 웹 서버를 외부 인터넷에 직접 노출하는 셈이라 위험하고, B와 D인 네트워크 ACL은 IP 주소 기반이라 관리가 매우 번거로우며 유연하지 못합니다.

정답은 B입니다. 같은 걸 자꾸 물어본다면 대답을 미리 적어두는 '메모지'가 필요합니다. ElastiCache는 데이터를 하드디스크가 아닌 광속의 메모리에 담아두는 캐시 서버입니다. DB까지 가지 않고 메모리에서 바로 대답해주니 응답 속도가 비약적으로 빨라지고 DB의 부담도 획기적으로 줄어듭니다. 중복 데이터 조회의 성능 개선에는 캐싱만한 게 없습니다. 다른 옵션인 C(복제본)는 전반적인 읽기 용량은 늘려주지만, '같은 데이터를 반복 조회'하는 비효율을 근본적으로 없애주지는 못합니다. A와 D는 캐싱과는 무관한 통신 도구들입니다.

정답은 D와 E입니다. 보안의 황금률은 '필요한 만큼만 주는 것'입니다. 이 직원은 리소스를 직접 하나씩 만들기보다 CloudFormation이라는 도구로 자동 배포하는 게 주 업무이므로, CloudFormation 서비스 자체를 다루는 권한(D)과 그 과정에서 허용된 리소스만 만들 수 있는 구체적인 IAM 역할(E)을 주는 것이 가장 안전하고 올바른 권한 설정입니다. 다른 옵션인 A, B, C는 너무 과하게 큰 권한을 주는 것이라 보안 사고의 위험이 매우 큽니다. 특히 루트 계정 공유나 관리자 권한 부여는 절대 피해야 할 금기 사항입니다.

정답은 D입니다. AWS의 기본 보안 그룹은 '나가는 건 자유롭지만 들어오는 건 철저히 막는' 속성이 있습니다. 따라서 RDS 입장에서 보면 웹 서버가 보내는 신호는 낯선 외부인의 침입일 뿐입니다. RDS 보안 그룹을 열어서 '우리 서비스 웹 서버 보안 그룹 딱지를 붙이고 오는 손님은 통과시켜줘'라고 규칙을 추가하는 것이 정답입니다. 대다수의 연결 문제는 이 보안 그룹 설정에서 해결됩니다. 다른 옵션인 A는 기본 ACL이 이미 다 열려있어 원인이 아닐 확률이 높고, B(라우팅 테이블)는 같은 VPC 내부 가동 중이라면 기본적으로 길이 다 뚫려 있습니다. C는 문제를 더 복잡하게 만드는 불필요한 작업입니다.

정답은 A입니다. 관계형 데이터베이스에서 '조회(읽기) 쿼리'가 버겁다면 읽기 전용 복제본이 만병통치약입니다. 메인 DB는 오직 저장(쓰기)에만 집중하게 하고, 무거운 보고서 작업은 복사본 서버(Read Replica)에서 따로 돌리면 원본에는 아무런 영향이 없습니다. 비용 대비 가장 확실하게 데이터베이스의 숨통을 틔워주는 방법입니다. 다른 옵션인 B는 일반적인 관계형 DB 구조에서는 불가능하며, C(스케일 업)는 비용만 치솟고 부하 분산의 근본 원인을 해결하지 못합니다. D(다중 AZ)는 장애 복구용이지 읽기 성능을 높여주지는 않습니다.

정답은 B와 D입니다. 고객의 로그인 정보(세션)는 서버(EC2) 안에 두면 안 됩니다. 서버가 죽거나 새로 생기면 로그인이 풀려버리기 때문이죠. 그래서 서버 밖의 별도 창고에 둬야 합니다. 첫 번째 추천은 빛의 속도로 읽고 쓰는 ElastiCache(Redis)이고, 두 번째는 데이터가 아무리 늘어나도 끄떡없는 DynamoDB입니다. 이 두 곳은 서버가 바뀌어도 세션을 안전하게 유지해줍니다. 다른 옵션인 A(고정 세션)는 서버가 죽으면 결국 세션도 날아가기에 불안전하고, C(Cognito)는 인증 도구이지 실시간 세션 상태 저장소로 쓰기엔 목적이 조금 다릅니다.

정답은 C입니다. 서버가 '상태 비저장(데이터를 서버에 안 담음)'이라면 굳이 시시콜콜하게 하드디스크 백업을 할 필요가 없습니다. 그냥 서버 설정이 다 되어있는 이미지(AMI) 하나만 잘 보관해두면 언제든 새 서버를 찍어낼 수 있으니까요. 대신 데이터가 중요한 RDS는 '자동 백업'을 켜두면 초 단위로 과거를 돌릴 수 있는 '지정 시간 복구(PITR)'가 가능해져서 2시간 RPO를 아주 가뿐하게 만족할 수 있습니다. 다른 옵션인 A와 D는 의미 없는 서버 하드 백업에 돈과 시간을 낭비하는 꼴입니다. B는 관리 수고가 C보다 조금 더 많이 듭니다.

정답은 A입니다. 글로벌 웹 서비스라면 웹 서버는 당연히 전 세계 어디서든(0.0.0.0/0) 들어올 수 있게 HTTPS(443)를 열어야 합니다. 하지만 소중한 DB는 전 세계에 노출되면 큰일 나죠. 그래서 '우리 회사의 웹 서버 딱지(보안 그룹 ID)'를 붙인 신호만 쏙쏙 골라 받도록 설정하는 것이 보안의 정석입니다. 이렇게 하면 복잡한 IP 주소 관리 없이도 외부 침입을 완벽히 차단하면서 고객에겐 활짝 열린 사이트를 만들 수 있습니다. 다른 옵션인 B는 전 세계 고객의 변화무쌍한 IP를 일일이 등록하는 게 불가능하고, C는 DB를 도둑에게 노출하는 매우 위험한 짓입니다.

정답은 C입니다. '음성을 텍스트로(Speech-to-Text)' 만들어주는 전문가가 바로 Amazon Transcribe입니다. 이 서비스에는 'Redaction(가리기)' 기능이 있어서, "안녕하세요, 제 전화번호는 010-1234..."라는 말을 듣는 즉시 텍스트에서 번호를 [PII]로 가려줄 수 있습니다. 람다로 수동 코딩할 필요 없이 클릭 설정만으로 인공지능이 알아서 해부해주니 운영 오버헤드가 가장 적습니다. 다른 옵션인 B(Textract)는 문서 이미지에서 글자를 뽑는 도구이지 소리를 듣는 도구가 아닙니다. A나 D는 구현 난이도가 너무 높고 관리가 힘듭니다.

정답은 C입니다. (최근 gp3 성능 한계와 비용 효율을 고려할 때 io2로의 전환이 정석적인 답변입니다.) gp3 볼륨은 가성비가 좋지만 성능 한계가 명확합니다. 만약 20,000 IOPS 이상의 엄청난 부하를 지속적으로 안정적이게 처리해야 한다면, 기업용 고성능 전용 저장소인 'io2'나 'io1'으로 갈아타는 것이 정답입니다. 이들은 높은 비용만큼이나 강력한 입출력 성능을 보장해주어 대규모 트래픽에도 DB가 버벅이지 않게 지탱해줍니다. 다른 옵션인 A(마그네틱)는 구식이고 훨씬 느립니다. B는 일정 수준 이상의 IOPS를 감당하기엔 gp3 체급 자체가 모자랄 수 있으며, D처럼 볼륨을 쪼개는 건 RDS 구조상 관리가 매우 까다로워 일반적인 해결책이 아닙니다.

정답은 C입니다. AWS 계정 안에서 벌어지는 모든 '누가(Who)' 관련 기록은 CloudTrail이 쥐고 있습니다. "누가 저번 주 화요일 오후 3시에 보안 그룹 문을 열었어?"라는 질문에 정확히 그 직원의 이름을 알려주는 감사관 역할을 합니다. 보안 그룹 변경뿐만 아니라 서버 생성, 삭제 등 모든 API 요청 내역이 여기에 고스란히 남습니다. 다른 옵션인 A(GuardDuty)나 B(Inspector)는 나쁜 짓이나 구멍을 찾아내는 도구이지 '범인 찾기' 기록 장부는 아닙니다. D(Config)는 설정이 '어떻게' 바뀌었는지는 잘 보여주지만, '누구인지'를 찾는 일차적인 감사 로그는 CloudTrail이 주인공입니다.

정답은 A입니다. DDoS 공격 방어의 끝판왕은 'AWS Shield Advanced'입니다. 기본 제공되는 Standard보다 훨씬 강력한 보호 기능을 제공하며, 특히 '가속기(Global Accelerator)' 앞단에서 공격을 미리 차단해버리면 뒤에 있는 서버들은 공격이 오는지도 모를 만큼 안전해집니다. 가속기 자체를 보호 대상으로 등록하는 것이 가장 상단에서 공격을 막는 효율적인 방법입니다. 다른 옵션인 B는 공격이 이미 네트워크 깊숙이 들어온 뒤에 막는 것이라 효율이 떨어지며, C인 WAF는 특정 웹 공격은 막아도 대규모 트래픽 폭탄(DDoS)을 전문적으로 방어하기엔 한계가 있습니다.

정답은 C입니다. 이 문제의 함정은 '1시간'이라는 실행 시간입니다. 람다(Lambda)는 최대 15분까지만 버틸 수 있어서 1시간짜리 대작업은 중도 하차하게 됩니다. 그래서 서버 관리 걱정 없는 Fargate(서버리스 컨테이너)를 선택하고, EventBridge로 매일 알람을 맞춰 '작업(Task)'이 켜졌다가 끝나면 꺼지게 만드는 조합이 운영 면에서 가장 편리하고 경제적입니다. 다른 옵션인 A와 B는 람다 시간 제한 때문에 실패하고, D는 서버를 직접 관리해야 하는 번거로움(인프라 오버헤드)이 큽니다.

정답은 C입니다. 100Mbps 속도로 600TB를 보내려면 이론상 1년도 넘게 걸립니다. '네트워크가 느린데 데이터가 너무 많다'면 실제 하드디스크 장비를 택배로 주고받는 Snowball 서비스가 정답입니다. Snowball Edge 장비 여러 대에 데이터를 꽉꽉 담아 보내면 2주 안에 거뜬히 전송을 끝낼 수 있습니다. 가장 물리적이고 확실한 '대형 이사 장비'입니다. 다른 옵션인 A와 B는 속도 한계 때문에 기한 내 불가능하며, D는 전용선을 새로 까는 데만 수개월이 걸릴 수 있어 '2주 이내'라는 조건에 맞지 않습니다.

정답은 B입니다. 무차별적으로 쏟아붓는 요청 폭탄(Flood)을 막는 명사수는 WAF의 'Rate-based Rule'입니다. "동일인이 5분 동안 2,000번 넘게 호출하면 넌 범인이니 차단해!"라고 규칙만 정해두면 WAF가 알아서 실시간으로 나쁜 놈들을 걸러줍니다. 클릭 몇 번으로 끝나니 개발자가 직접 차단 로직을 짤 필요가 전혀 없습니다. 다른 옵션인 A(캐시)는 실시간 주식 정보 조회에는 맞지 않고, C는 알림만 줄 뿐 방어를 직접 해주지는 않으며, D(코딩)는 운영 오버헤드가 너무 큽니다.

정답은 C입니다. 'DB에 변화가 생기면 즉시 알린다'는 시나리오에는 DynamoDB 스트림(Streams)이 최고입니다. DB 자체에 무리를 주지 않고도 뒤쪽에서 살짝 변경 이력을 읽어와서 SNS(알림 서비스)로 소식을 툭 던져줄 수 있습니다. 람다 트리거 하나면 되니 아주 가볍고 실시간성까지 확보한 우아한 설계입니다. 다른 옵션인 A와 B는 메인 앱이 알림 일까지 직접 챙겨야 하므로 서버가 느려질 수 있고, D(스캔)는 데이터가 많아질수록 서버 비용이 폭탄이 될 수 있는 아주 위험한 방식입니다.