AWS SAA C03 연습 문제 (51~75번)

정답은 B와 D입니다. 매일 아침 정해진 시간에 데이터를 추출하여 보고서를 작성하고 싶다면, EventBridge의 예약 기능을 통해 람다 함수를 깨우는 방식이 가장 깔끔합니다. 람다가 데이터를 모아 예쁜 HTML 양식으로 가공하면, 이를 대량 메일 발송에 특화된 서비스인 Amazon SES를 통해 각 담당자에게 배달하게 됩니다. 이 조합은 서버를 24시간 켜둘 필요가 없어 비용 효율적이며 관리도 매우 간편합니다.

정답은 C입니다. 수 테라바이트급의 방대한 데이터를 '표준 폴더 구조'로 관리하면서 용량 걱정 없이 쓰고 싶다면 Amazon EFS가 정답입니다. EFS는 여러 대의 서버가 동시에 연결할 수 있는 공유 창고 같은 역할을 하며, 데이터가 늘어나는 만큼 알아서 공간을 넓혀주기 때문에 관리자가 일일이 디스크 용량을 증설하는 수고를 덜어줍니다. 또한 여러 가용 영역에 데이터가 복제되어 안정성도 매우 높습니다.

정답은 C입니다. 최고 권한자인 루트 사용자조차도 10년 동안 절대로 데이터를 지울 수 없게 잠그는 하드웨어 수준의 보안이 바로 Object Lock의 규정 준수 모드입니다. 여기에 수명 주기 정책을 곁들여 1년 뒤에는 비용이 가장 저렴한 Deep Archive라는 창고로 옮겨두면, 법적 의무는 완벽히 지키면서도 창고 유지 비용은 극적으로 낮출 수 있는 가장 현명한 설계가 됩니다.

정답은 C입니다. 직원들이 쓰던 기존의 윈도우 파일 탐색기 환경을 그대로 유지하면서 고장 나지 않는 튼튼한 저장소를 만들고 싶다면 FSx for Windows File Server가 제격입니다. 별도로 서버 두 대를 띄워 복제 설정을 할 필요 없이, AWS가 알아서 여러 구역에 데이터를 복사해두고 문제가 생기면 즉시 대기 중인 장비로 연결해주므로 관리자는 더 이상 밤잠을 설치지 않아도 됩니다.

정답은 C입니다. 데이터베이스에는 아무나 들어오지 못하게 문을 걸어잠가야 합니다. 오직 '특정 자격'을 갖춘 서버들만 통과시키고 싶을 때는 보안 그룹이라는 방화벽을 사용합니다. DB의 문지기(보안 그룹)에게 '프라이빗 구역에 있는 서버들의 신원'을 확인하고 들여보내라는 명확한 규칙을 부여하면, 외부 인터넷이나 다른 구역의 엉뚱한 접속 시도를 원천 봉쇄할 수 있습니다.

정답은 C입니다. 복잡한 API 주소 대신 회사의 예쁜 도메인 이름을 붙여주고 싶다면, API 게이트웨이에서 사용자 지정 도메인 설정을 해줘야 합니다. 이때 보안 연동(HTTPS)을 위해 해당 리전의 인증서 관리자인 ACM에 디지털 도장을 등록하고, 이를 API 입구에 걸어둔 뒤 마지막으로 전화번호부(Route 53)에 이 주소를 알려주면 전 세계 어디서든 안전하게 우리 API를 호출할 수 있게 됩니다.

정답은 B입니다. 수많은 이미지를 사람의 눈으로 일일이 검사하는 건 불가능에 가깝습니다. 하지만 인공지능인 Amazon Rekognition을 쓰면 기계가 알아서 유해한 요소를 콕 잡아냅니다. 기계가 판단하기 애매한 부분은 실제 사람에게 검토 요청(A2I)을 보내는 똑똑한 워크플로까지 갖추고 있어, 개발자가 복잡한 알고리즘을 짤 필요 없이 서비스의 청정함을 유지할 수 있습니다.

정답은 C입니다. 실행 환경(서버)이 잘 돌아가는지 매일 체크하는 스트레스에서 벗어나고 싶다면 Fargate라는 서버리스 엔진이 정답입니다. 사용자는 '내 앱을 컨테이너에 담아 실행하라'는 명령만 내리면 되고, 실제 서버가 몇 대가 필요하고 어떻게 관리할지는 AWS가 다 알아서 해줍니다. 이를 통해 개발자는 서버 운영 대신 앱의 본질적인 기능 향상에만 온전히 집중할 수 있습니다.

정답은 D입니다. 전 세계에서 쏟아지는 엄청난 양의 로그를 일일이 파일로 모으는 건 너무 느립니다. Kinesis라는 거대한 물줄기를 통해 데이터를 실시간으로 흘려보내야 합니다. 이 물줄기를 Firehose가 받아 분석 창고(Redshift)로 바로 연결해주면, 하루 30테라가 넘는 빅데이터도 막힘없이 처리하고 즉시 유의미한 비즈니스 통찰력을 얻어낼 수 있습니다.

정답은 C입니다. 보안이 취약한 옛날 방식(HTTP)으로 들어오는 사람들을 안전한 보안 연결(HTTPS)로 자동 안내해주고 싶다면 로드 밸런서에게 리디렉션 규칙을 주면 됩니다. 로드 밸런서가 현관문에서 '여기는 보안이 강화된 문으로만 들어오세요'라고 친절하게 경로를 틀어주기 때문에, 사용자는 불편함 없이 가장 안전한 상태로 우리 웹사이트를 이용하게 됩니다.

정답은 C입니다. 소스 코드에 비밀번호를 적어두는 건 현관문 앞에 열쇠를 두는 것만큼 위험합니다. 금고 대여소인 Secrets Manager를 빌려 비밀번호를 보관하세요. 이 금고 대여소는 시간이 지나면 알아서 비밀번호를 새 걸로 바꿔주는 자동 순환 기능까지 있어, 보안 사고를 원천적으로 방지하면서도 개발자가 비밀번호 관리에 신경 쓸 일을 없게 해줍니다.

정답은 D입니다. AWS가 직접 관리해주는 인증서가 아니라 밖에서 사 온 인증서는 AWS가 대신 갱신해주고 싶어도 권한이 없습니다. 이럴 땐 ACM이라는 문서함에 인증서를 잘 넣어두고 쓰되, 유통기한이 다 되어간다는 알람을 받으면 새 인증서를 사 와서 수동으로 바꿔줘야 합니다. 내 집 비밀번호를 직접 관리하는 것처럼 주관적인 보안 관리가 필요한 영역입니다.

정답은 A입니다. 문서가 업로드되는 즉시 '그걸 잡아내서 그림으로 바꿔라'라는 자동화 명령을 람다 함수에 내려보세요. S3는 무제한 창고라 용량 걱정이 없고, 람다는 딱 변환하는 그 찰나의 순간에만 일하고 사라집니다. 이 방식은 사용자가 1명이든 100만 명이든 똑같이 유연하게 대응하며, 서버를 한 대라도 덜 띄웠을 때 아끼는 비용은 회사 운영에 큰 힘이 됩니다.

정답은 D입니다. 하이브리드 클라우드 환경에서 '로컬 파일 시스템의 속도'와 '클라우드의 방대한 용량'을 다 잡고 싶다면 FSx 파일 게이트웨이가 환상적인 가교 역할을 해줍니다. 특히 윈도우 파일 시스템(SMB)을 고집하는 환경이라면, 익숙한 사용법을 그대로 유지하면서도 뒤쪽에서는 클라우드와 실시간으로 동기화되니 사용자들은 인프라가 바뀌었는지조차 모를 정도로 매끄러운 이전을 경험하게 됩니다.

정답은 C입니다. 병원 차트의 복잡한 표와 글씨를 정교하게 읽어내는 Textract라는 눈과, 그 안에서 환자의 개인정보만 똑똑하게 가려내는 Comprehend Medical이라는 뇌를 연결하는 전략입니다. 이 두 서비스를 함께 쓰면 의료진이 매일 지루하고 힘든 데이터 분류 작업에 시간을 뺏기지 않고 정작 중요한 환자 진료에 더 많은 시간을 쏟을 수 있게 됩니다.

정답은 C입니다. 30일 지나면 가끔 보긴 하겠지만 '보고 싶을 때 바로 나와야 하는' 중요 데이터라면 Standard-IA 계층이 정답입니다. 비용을 더 아끼겠다고 Glacier로 보내면 자료를 꺼낼 때 한참을 기다려야 하고, One Zone 계층을 쓰면 만약의 재해 때 자료를 통째로 잃을 수 있습니다. 중요도와 접근성을 고려할 때 Standard-IA가 가장 균형 잡힌 안식처입니다.

정답은 D입니다. 서버 한 대가 일을 다 마치기도 전에 대기열에서 메시지가 다시 '나 여기 있어' 하고 나타나면 다른 서버가 또 가져가게 됩니다. 이럴 땐 '가시성 시간 초과'라는 기능을 통해, 누군가 메시지를 집어 가면 충분한 시간 동안 다른 사람 눈에 안 보이게 꽁꽁 숨겨두어야 합니다. 그러면 중복 처리로 인한 데이터 오염을 깔끔하게 막을 수 있습니다.

정답은 A입니다. 평소에는 비싸더라도 전용선(Direct Connect)을 깔아 시원시원하게 데이터를 주고받고, 만약 전용선에 문제가 생기면 임시로 인터넷 길(VPN)을 이용해 우회하는 전략입니다. 비상용으로 전용선을 하나 더 깔면 돈이 너무 많이 드니, 조금 느리더라도 저렴한 VPN을 비상로로 챙겨두는 것이 가장 가성비 좋고 현명한 하이브리드 설계라 할 수 있습니다.

정답은 B입니다. '고장 나도 멈추지 않는 시스템'을 만들고 싶다면 계란을 여러 바구니(가용 영역)에 나눠 담아야 합니다. 웹 서버도 나누고, DB도 다중 AZ로 설정해두면 한쪽 바구니가 깨져도 다른 쪽에서 즉시 역할을 넘겨받습니다. 특히 RDS 프록시까지 곁들이면 장애가 터졌을 때 연결을 갈아타는 그 찰나의 순간도 사용자가 느끼지 못할 정도로 매끄러운 고가용성을 유지할 수 있게 됩니다.

정답은 C입니다. NLB는 단순히 서버가 켜져 있는지(L4)만 확인하기 때문에, 서버 안의 서비스가 먹통이 된 것까진 모릅니다. 반면 ALB(L7)는 앱이 실제 잘 돌아가는지(HTTP) 꼼꼼하게 살핍니다. 똑똑한 관절형 로드 밸런서인 ALB로 갈아타서 앱 상태를 정밀하게 체크하면, 앱이 죽은 인스턴스만 쏙 골라내어 새것으로 바꾸라고 Auto Scaling에 시킬 수 있어 훨씬 튼튼한 서비스 유지가 가능합니다.

정답은 B입니다. 실수로 데이터를 지웠을 때 '아, 10분 전으로 돌아가고 싶다'라는 소원을 들어주는 기능이 지정 시간 복구(PITR)입니다. 이 기능은 초 단위 정밀도로 과거의 어떤 시점이라도 새 테이블로 뚝딱 살려내 주기 때문에, 15분 이내의 유실 방지라는 엄격한 약속을 지켜내기에 가장 믿음직하고 빠른 방법입니다.

정답은 D입니다. 같은 리전 안에서도 굳이 인터넷 망을 타고 S3에 가는 건 택시를 타고 골목길을 도는 것처럼 비효율적이고 비쌉니다. VPC 안에 S3로 가는 무료 직통 엘리베이터(게이트웨이 엔드포인트)를 설치해보세요. 인터넷을 타지 않고 AWS 내부망으로만 소통하기 때문에 데이터가 아무리 넘쳐나도 전송료 걱정 없이 쾌적하게 사진을 주물럭거릴 수 있습니다.

정답은 C와 D입니다. 길 입구(배스천)에는 오직 우리 회사 소속임을 증명하는 고정된 외부 주소만 통과시키세요(C). 그리고 진짜 중요한 내부 서버는 '입구를 통과해 온 사람들(배스천의 내부 주소)'에게만 문을 열어주세요(D). 이렇게 이중으로 주소 필터링을 걸면, 지나가던 해커가 내부 서버에 침입해보려 해도 입구부터 막히고, 설령 입구를 보더라도 내부로 가는 문은 아예 보이지 않는 철통 보안이 완성됩니다.

정답은 A와 C입니다. 웹 사이트 대문은 누구나 들어올 수 있게 활짝 열어두되(443 포트), 집안 깊숙한 현금 상자(DB)는 오직 집에서 일하는 사람(웹 서버 보안 그룹)만 만질 수 있게 해야 합니다. 특히 데이터베이스 보안 그룹 설정 시 IP 주소가 아닌 '웹 서버 보안 그룹의 ID'를 지정하면, 웹 서버가 몇 대가 되든 늘어나든 줄어들든 상관없이 그들로부터 오는 정당한 요청만 찰떡같이 구분해 받아들일 수 있습니다.

정답은 A입니다. 일이 몰려서 시스템이 비명을 지르다 자료를 놓치는 건 결합이 너무 빡빡해서 생기는 병입니다. 중간에 SQS라는 임시 보관함을 하나 두어 완충 지대를 만드세요. 그리고 그 일을 처리할 엔진으로 필요한 만큼만 나타나 일하는 람다 요정을 배치하면, 갑자기 손님이 몰려도 예약 대기표(SQS)를 끊고 차례로 처리해내기 때문에 트랜잭션 유실 없는 튼튼하고 세련된 앱이 완성됩니다.