모의고사 5

EC2의 IAM 사용자 액세스 키는 장기 자격 증명이며, 역할 기반 임시 자격 증명보다 교체와 보호가 어렵습니다. 주의: 권한 자체는 비슷해 보이지만 EC2 워크로드에 자격 증명을 전달하는 방식이 안전하지 않습니다.

Parameter Store 액세스는 IAM 및 KMS 권한으로 제어됩니다. Aurora가 EC2의 파라미터 액세스를 허용하는 신뢰 관계를 설정하지 않습니다. 주의: 리소스 정책과 신뢰 관계라는 말은 보안과 관련 있어 보이지만, 제어 평면이 잘못되었습니다.

VPC 엔드포인트는 트래픽을 비공개로 유지하는 데 도움이 될 수 있지만 GetParameter 호출을 승인하거나 SecureString 값을 복호화할 권한을 부여하지는 않습니다. 주의: 프라이빗 네트워크 액세스만으로는 충분하지 않으며 IAM과 KMS 권한이 여전히 필요합니다.

S3 Object Lock 거버넌스 모드는 필요한 권한을 가진 사용자가 우회할 수 있으므로 엄격한 규제 보존에서 불변성을 보장하지 못합니다. 주의: 거버넌스 모드는 규정 준수처럼 들리지만, 통제된 우회가 가능한 시나리오를 위해 설계되었습니다.

SSE-S3는 운영 부담이 낮지만 고객이 키 교체 동작을 구성하지 않으므로 명시된 키 관리 요구 사항을 충족하지 않습니다. 주의: S3 관리형 암호화는 쉽지만, 단서는 구성 가능한 키 교체 거버넌스를 요구합니다.

가져온 KMS 키 자료는 생성, 가져오기, 만료, 교체에 대한 고객 측 수명 주기 작업을 만들므로 최소 운영 오버헤드와 충돌합니다. 주의: 더 강한 제어처럼 들리지만 운영 부담이 함정입니다.

AWS WAF는 HTTP 요청을 필터링합니다. 계정이 사용할 수 있는 리전을 통제하거나 VPC 인터넷 게이트웨이 연결을 방지할 수 없습니다. 주의: WAF는 인터넷 보안 제어처럼 들리지만, 이 문제는 계정 및 네트워크 거버넌스입니다.

네트워크 ACL은 패킷을 차단할 수 있지만 금지된 리소스 생성을 막지 못하며, 사용자별 IAM 정책은 계정 전반에서 일관되게 유지하기 어렵습니다. 주의: 로컬 트래픽과 자격 증명은 제어하지만 조직 전체의 예방적 경계는 아닙니다.

AWS Config는 주로 탐지형입니다. 비준수 리소스가 나타난 뒤 경고할 수 있지만, 문제는 방지를 요구합니다. 주의: 지속적 모니터링은 증거 확보에 유용하지만 단서는 우발적 위반을 방지하라고 말합니다.

SNS는 push 알림 서비스이며, 그 자체만으로는 처리 서비스에 필요한 pull 기반 버퍼링, visibility timeout, 소비자 backpressure를 제공하지 않습니다. 주의: Pub/sub는 분리된 구조처럼 들리지만, SNS 단독은 여기서 설명하는 내구성 있는 작업 대기열이 아닙니다.

Lambda는 컴퓨팅 서비스이지 메시지 백본이 아니며, 메시지 전달용으로 사용하면 visibility timeout이나 redrive 같은 대기열 의미 체계 없이 결합도가 높아집니다. 주의: 서버리스 컴퓨팅은 이벤트를 처리할 수 있지만, 문제는 서비스 간 안정적인 통신을 묻고 있습니다.

DynamoDB Streams는 테이블 변경 데이터 캡처이지, 마이크로서비스 간 배치 작업 분산을 위한 가장 단순한 범용 대기열이 아닙니다. 주의: Streams로 처리를 트리거할 수는 있지만, 대기열 형태의 문제에 테이블과 스트림 관리를 추가합니다.

DataSync는 온라인 전송에 유용하지만 제한된 인터넷 연결에 계속 의존하므로 마감 기한을 놓칠 위험이 있습니다. 주의: VPC 엔드포인트는 효율적으로 들리지만 데이터 센터에서 AWS까지의 대역폭을 늘려 주지는 않습니다.

Direct Connect는 전용 연결을 제공하지만, 프로비저닝과 용량 계획은 보통 긴급한 10일 대량 마이그레이션에 맞지 않습니다. 주의: 전용 대역폭은 매력적이지만 시나리오는 즉각적인 일회성 전송 솔루션이 필요합니다.

Storage Gateway는 하이브리드 스토리지 액세스와 캐싱을 지원하지만, 결국 제한된 네트워크 링크를 통해 시간이 지나며 데이터를 업로드해야 합니다. 주의: 스토리지 마이그레이션과 관련된 서비스이지만 긴급한 75TB 초기 적재에 가장 적합한 도구는 아닙니다.

read replica를 더 추가하면 읽기 확장에는 도움이 되지만, writer 장애 조치 중 애플리케이션 연결 중단 문제는 해결하지 못합니다. 주의: 복제본은 고가용성처럼 들리지만 중단은 writer endpoint와 관련되었습니다.

다른 리전의 보조 클러스터는 DR 기능을 추가하지만, 애플리케이션 전환 로직과 확장 연습을 위한 더 많은 운영 오버헤드가 필요합니다. 주의: Cross-Region 장애 조치는 복원력이 높아 보이지만 일반적인 장애 조치 다운타임을 줄이기에는 너무 무겁습니다.

ElastiCache는 데이터베이스 읽기 부하를 줄일 수 있지만 Aurora writer 장애 조치나 애플리케이션 데이터베이스 연결을 관리하지 않습니다. 주의: 캐싱은 성능을 개선할 수 있지만 문제는 장애 조치 다운타임입니다.

PostgreSQL을 EC2 Auto Scaling과 NLB 뒤에 두는 방식은 안전한 단일 writer 의미 체계, 복제, 관리형 장애 조치를 제공하지 않습니다. 주의: 웹 계층 확장 아이디어를 빌린 선택지이지만 상태 저장 데이터베이스에는 로드 밸런싱된 writer가 아니라 데이터베이스 HA가 필요합니다.

Apache 웹 로직을 Lambda로 리팩터링하는 것은 큰 재작성이며 호환성 중심 마이그레이션 요구를 충족하지 않습니다. 주의: 서버리스는 확장할 수 있지만 이 시나리오는 마이그레이션 중 호환성 위험을 최소화하라고 합니다.

PostgreSQL을 DynamoDB로 교체하려면 스키마와 쿼리 재설계가 필요하므로 관계형 호환성이 깨집니다. 주의: DynamoDB는 복원력과 확장성이 있지만 PostgreSQL의 드롭인 대체재가 아닙니다.

적합하지 않습니다. S3 PUT으로 Lambda를 트리거할 수는 있지만 약 2GB 파일 처리는 Lambda 제한과 제약에 잘 맞지 않습니다. 임시 스토리지 크기, 메모리와 실행 시간, 대용량 객체 다운로드/변환/업로드 비효율 문제가 있습니다. 튜닝으로 가능하더라도 타임아웃, 재시도, 부분 처리 같은 실패 위험과 운영 부담이 관리형 ETL보다 큽니다. 주의: Lambda는 S3에서 쉽게 트리거되지만 멀티 GB 파일 변환은 Lambda의 편한 운영 범위를 벗어납니다.

기술적으로는 Spark가 대규모 변환에 적합하므로 가깝지만 운영 오버헤드가 더 큽니다. 일반적인 Spark 작업은 EMR 클러스터나 Spark 인프라 관리, 의존성 패키징, 확장, 모니터링을 의미합니다. Lambda로 이를 호출하면 오케스트레이션 복잡성도 추가됩니다. AWS Glue는 같은 JSON-to-Avro 변환 요구에 대해 더 적은 설정과 관리 포인트로 관리형 Spark를 제공합니다. 주의: Spark는 기술적으로 맞지만 직접 Spark 작업을 운영하면 클러스터와 오케스트레이션 부담이 늘어납니다.

서비스 패턴이 맞지 않습니다. Glue 크롤러와 테이블, Athena는 데이터를 제자리에서 대화형 SQL 분석하기 위한 조합이지, 들어오는 각 객체를 새로운 Avro 객체 집합으로 변환하는 용도가 아닙니다. Athena 쿼리 결과는 일반적으로 쿼리 결과 위치에 CSV/JSON/Parquet 등으로 쓰이며, Lambda로 주기적 쿼리를 실행하면 지연, 복잡성, 비용이 늘고 일대일 파일 변환 의미도 보장하기 어렵습니다. 주의: Athena는 데이터를 쿼리할 수 있지만, 이 요구 사항은 테이블 분석이 아니라 객체 형식 변환입니다.

S3 동기화는 오래된 로컬 복사본을 만들 수 있으며 동시 업데이트가 가능한 공유 파일 시스템을 제공하지 않습니다. 주의: Transfer Acceleration은 장거리 업로드에 도움이 되지만 VPC 내부의 저지연 공유 파일 액세스를 해결하지 않습니다.

CloudFront와 S3는 객체 검색이나 API 변경이 필요하므로 기존 파일 액세스 방식을 유지해야 한다는 요구 사항을 위반합니다. 주의: 파일을 전 세계에 배포할 수는 있지만 마운트된 공유 파일 시스템은 아닙니다.

EBS는 Availability Zone에 묶인 블록 스토리지이며, 여러 AZ의 15개 인스턴스에 연결되는 하나의 공유 파일 시스템으로 적합하지 않습니다. 주의: Provisioned IOPS는 빠르게 들리지만 블록 스토리지는 다중 AZ 공유 파일 액세스를 해결하지 않습니다.