Practice Test #4

GuardDuty는 주로 탐지 서비스입니다. S3 보호와 관련된 결과(예: 의심스러운 접근 패턴)를 생성할 수 있고 Lambda로 수정을 자동화할 수 있지만 이는 여전히 사후 대응적입니다. 버킷을 퍼블릭으로 만드는 잘못된 구성과 수정 작업 사이에 시간 차이가 있을 수 있습니다. "절대 노출되지 않음"의 경우 S3 Block Public Access와 같은 예방적 제어가 더 적절합니다.

Trusted Advisor는 퍼블릭으로 접근 가능한 S3 버킷을 보고할 수 있지만 예방적 제어가 아니며 주기적인 검사와 수동 수정에 의존합니다. 이메일 알림 및 사람의 개입은 지연 및 운영 위험을 초래하며 이는 엄격한 HIPAA 요구 사항과 충돌합니다. 이 옵션은 많은 버킷에 걸쳐 잘 확장되지 않으며 데이터가 절대 노출되지 않는다고 보장하지 않습니다.

AWS Resource Access Manager(RAM)는 AWS 계정 간에 리소스(예: 서브넷, Transit Gateway)를 공유하기 위한 것이며 퍼블릭 S3 버킷 접근을 검색하거나 관리하는 데 사용되지 않습니다. 설명된 탐지 및 수정 흐름은 RAM의 작동 방식과 일치하지 않습니다. 다른 서비스와 함께 구현되더라도 강력한 예방 가드레일이라기보다는 사후 대응적일 것입니다.

가장 적합하지 않습니다. AWS Backup은 백업 계획 및 일정을 통해 DynamoDB 백업을 관리할 수 있으므로 일부 노력을 줄일 수 있지만, 여전히 특정 시점의 어느 초가 아닌 개별 백업 시점으로 복원하는 것이 일반적입니다. "지난 24시간 내의 특정 시점"을 충족하려면 매우 빈번한 백업이 필요하며 여전히 PITR의 세분성과 일치하지 않습니다. 운영상 백업 계획, 일정 및 보존 정책을 관리해야 합니다.

오답입니다. Lambda를 통한 시간당 온디맨드 백업은 운영 오버헤드(Lambda 코드, IAM 권한, 예약, 모니터링, 재시도, 오류 처리)를 도입하고 "특정 시점"이 아닌 시간당 복원 지점만 제공합니다. 또한 실행이 실패하거나 스로틀링이 발생할 경우 공백이 생길 위험이 있습니다. 이는 DynamoDB PITR보다 더 많은 노력이 필요하고 복구 정밀도가 낮습니다.

최소 운영 복원(least-ops restore)에 대해 오답입니다. DynamoDB Streams와 S3 스토리지는 사용자 지정 재생/이벤트 소싱을 지원할 수 있지만 재생 메커니즘을 구축 및 운영하고 순서 지정, 중복, 스키마 변경 및 보존을 처리해야 합니다. PITR에 비해 복잡하고 운영 부담이 큽니다. 또한 추가 처리 없이는 테이블 상태에 대한 기본 특정 시점 복원 기능이 아닙니다.

"Amazon RDS Idle DB Instances" Trusted Advisor 검사는 데이터베이스가 활용도가 낮거나 사용되지 않을 때 유용하며 중지, 삭제 또는 축소 후보를 식별하는 데 도움이 됩니다. 그러나 질문에는 RDS for Oracle 인스턴스가 일관되게 높은 사용률을 보인다고 명시되어 있으므로 유휴 상태가 아닙니다. 이 검사는 이 워크로드 프로필에 대해 의미 있는 절감액을 표면화할 가능성이 낮습니다.

각 member account에서 Trusted Advisor를 검토하면 RDS 인스턴스가 실행되는 RI 기회를 기술적으로 식별할 수 있지만 중앙 집중식 재무 계획 팀에는 덜 효과적입니다. 계정을 전환하고 결과를 수동으로 집계해야 합니다. AWS Organizations 환경에서 management account의 중앙 집중식 검토는 일반적으로 교차 계정 가시성을 위한 의도된 모범 사례입니다.

Trusted Advisor "컴퓨팅 최적화" 검사 및 AWS Compute Optimizer는 주로 EC2 인스턴스, Auto Scaling groups 및 Lambda functions와 같은 컴퓨팅 리소스에 중점을 둡니다. RDS for Oracle Reserved Instance 구매 기회를 식별하기 위한 기본 도구가 아닙니다. 귀중한 비용 도구이기는 하지만 설명된 RDS RI 최적화 요구 사항을 직접 해결하지는 않습니다.

오답입니다. Amazon Inspector는 컴퓨팅(EC2 인스턴스), ECR의 컨테이너 이미지 및 Lambda 함수에 대한 취약성 관리에 중점을 둡니다. PHI/PII를 감지하기 위해 S3 객체 콘텐츠를 스캔하지 않습니다. EventBridge + SNS가 유효한 알림 패턴이더라도 기본 감지 서비스는 S3 객체 내부의 민감한 데이터를 식별하는 요구 사항에 대해 잘못되었습니다.

오답입니다. Macie는 올바른 감지 서비스이지만 결과를 SQS로 보내는 것은 "규정 준수 팀에 즉시 알리는" 가장 효과적인 방법이 아닙니다. SQS는 애플리케이션 처리를 위한 대기열이며 소비자가 폴링한 다음 사람에게 알려야 합니다. 또한 SensitiveData:S3Object/Personal을 구체적으로 필터링하는 것은 PHI 사용 사례에 너무 좁을 수 있습니다. 광범위하게 SensitiveData 결과가 더 적절합니다.

오답입니다. 이 옵션은 이중으로 일치하지 않습니다. Inspector는 S3 객체에서 PHI를 감지하지 않으며 SQS는 규정 준수 팀을 위한 직접적인 알림 메커니즘이 아닙니다. 소비자가 SQS를 읽고 알림을 트리거하는 워크플로를 구축할 수는 있지만 불필요한 구성 요소를 추가하고 민감한 데이터에 대해 S3 콘텐츠를 스캔하는 핵심 요구 사항을 여전히 충족하지 못합니다.

Amazon SageMaker JumpStart는 사전 구축되었거나 foundation-model 기반 솔루션의 배포를 도울 수 있지만, 여전히 inference endpoint를 선택하고, 배포하고, 운영해야 합니다. 이는 이미 기본 제공 managed moderation API로 충족되는 요구 사항에 비해 더 많은 복잡성과 운영 오버헤드를 초래합니다. 문제에서는 custom model 개발이나 training이 필요하지 않다고 명시하고 있으므로, 이는 SageMaker보다 Rekognition을 강하게 선호하게 만듭니다. 기술적으로는 가능하지만, image moderation을 위한 가장 직접적이고, 가장 낮은 지연 시간이며, 가장 AWS-native한 솔루션은 아닙니다.

Amazon CloudFront Functions는 AI 서비스를 호출하거나 무거운 처리를 수행하기 위한 것이 아니라, 단순한 HTTP request 및 response 조작을 위한 매우 가벼운 edge function입니다. 이들은 Amazon Textract를 직접 호출할 수 없으며, Textract 자체도 부적절한 이미지 탐지가 아니라 OCR, form extraction, document text analysis를 위해 설계되었습니다. 이미지에서 텍스트를 추출할 수 있다고 하더라도, 그것만으로 이미지 콘텐츠 자체가 부적절한지 또는 비의료적인지 판단할 수는 없습니다. 이 옵션은 서비스 불일치와 실행 환경의 부적합성이라는 두 가지 이유로 잘못되었습니다.

Amazon Rekognition Video는 web portal을 통해 업로드된 정지 이미지가 아니라 video 파일 또는 stream을 분석하기 위한 서비스입니다. 문제는 구체적으로 업로드된 이미지를 다루고 있으므로, 올바른 Rekognition 기능은 video analysis가 아니라 image moderation입니다. 또한 S3-triggered Lambda는 객체가 이미 업로드된 후에 실행되므로, upload transaction 중 실시간 차단을 본질적으로 제공하지 않습니다. 따라서 이 옵션은 media type과 timing requirement 모두에 적합하지 않습니다.

오답입니다. Multi-AZ는 주로 고가용성 및 자동 failover를 위한 것이며 읽기 확장을 위한 것이 아닙니다. 표준 RDS Multi-AZ에서 standby는 트래픽을 수락할 수 없으므로 쓰기나 읽기에 사용할 수 없습니다. 읽기를 primary로, 쓰기를 standby로 전달하는 것은 지원되지 않으며 지연 시간 증가를 유발하는 읽기 주도 CPU 병목 현상을 해결하지 못합니다.

오답입니다. 이 옵션은 Multi-AZ deployment의 standby가 읽기 트래픽을 처리할 수 있다고 가정합니다. 표준 Amazon RDS Multi-AZ에서 standby는 읽을 수 없으며 failover 목적으로만 유지됩니다. 따라서 분석 읽기를 standby로 오프로드할 수 없으며, primary는 피크 거래 시간 동안 계속해서 CPU 제약을 받게 됩니다.

부분적으로 합리적이지만 '최소한의 인프라 변경'을 고려할 때 최선의 선택은 아닙니다. read replica는 맞지만, primary 크기(8 vCPU/32 GB)와 일치시키는 것은 불필요할 수 있으며 더 작은 복제본이 분석 워크로드를 충족하지 못한다는 증거 없이 비용만 증가시킵니다. 더 나은 접근 방식은 더 작은 복제본으로 시작하여 성능/지연을 모니터링하고 필요한 경우에만 scale up/out하는 것입니다.

오답입니다. NAT 인스턴스는 아웃바운드 액세스를 제공할 수 있지만 패치 적용, 확장 및 신중한 구성(소스/대상 확인 비활성화, 보안 그룹, 장애 조치 스크립트)이 필요한 자체 관리형 EC2 인스턴스입니다. NAT 디바이스는 IGW를 통해 인터넷에 도달할 수 있어야 하며, 이를 위해서는 일반적으로 퍼블릭 IP/EIP가 있는 퍼블릭 서브넷에 있어야 하므로 프라이빗 서브넷에 배치하는 것도 잘못되었습니다.

오답입니다. 인터넷 게이트웨이를 서브넷에 연결할 수 없습니다. IGW는 VPC에 연결됩니다. 또한 프라이빗 서브넷을 IGW로 직접 라우팅하면 (인스턴스에 퍼블릭 IP가 있는 경우) 사실상 퍼블릭 서브넷이 되며 거래 애플리케이션 서버가 인터넷에서 직접 액세스할 수 없어야 한다는 요구 사항을 위반합니다. "보조 IGW"는 이 목적에 유효한 구성 요소가 아닙니다.

오답입니다. 외부 전용 인터넷 게이트웨이는 인바운드 시작 연결을 차단하면서 아웃바운드 전용 인터넷 액세스를 허용하기 위해 IPv6에 사용됩니다. 대부분의 패치 리포지토리, 시장 데이터 피드 및 타사 엔드포인트가 일반적으로 사용하는 IPv4 NAT 기능을 제공하지 않습니다. 또한 외부 전용 IGW는 VPC에 연결되며(서브넷에 배치되지 않음) IPv4용 NAT 게이트웨이를 대체하지 않습니다.

Lambda는 버스트 워크로드에 좋은 컴퓨팅 선택이지만 DynamoDB는 비디오 파일을 저장하는 데 적합하지 않습니다. DynamoDB는 400KB의 항목 크기 제한이 있으며 대용량 바이너리가 아닌 키-값/문서 메타데이터에 최적화되어 있습니다. 비디오를 청크로 나누더라도 비용과 복잡성이 높고 성능을 예측할 수 없습니다. 이 옵션은 대용량 업로드 미디어에 대한 스토리지 요구 사항을 충족하지 못합니다.

Kinesis Data Firehose는 선택적인 경량 변환을 통해 S3, Redshift 또는 OpenSearch와 같은 대상으로 스트리밍 데이터를 수집하고 전송하도록 설계되었습니다. 범용 비디오 처리 서비스가 아니며 임의의 썸네일 생성 워크로드를 실행하지 않습니다. 또한 구성 메타데이터를 기본 데이터베이스로 저장하기 위한 것이 아닙니다. 이 옵션은 워크로드 유형과 일치하지 않습니다.

EC2 instance를 5개로 고정적으로 늘리는 것은 50명에서 2000명 이상의 동시 사용자로의 자동 확장을 제공하지 않습니다. 피크 수요를 충족하지 못할 가능성이 높으며 비수기에는 용량을 낭비합니다. EBS volume은 연결된 스토리지이며 추가 아키텍처 없이는 instance 간 업로드를 위한 확장 가능한 공유 리포지토리가 아닙니다. 이 접근 방식은 관리형/서버리스 옵션에 비해 운영 부담을 증가시키고 복원력을 감소시킵니다.

VPC peering은 두 VPC 간에 프라이빗 IP 연결을 제공하지만 이는 네트워크 수준의 액세스입니다. 라우팅 및 보안 규칙이 허용되면 소비자는 단일 시장 데이터 서비스뿐만 아니라 제공업체 VPC의 많은 리소스에 잠재적으로 도달할 수 있습니다. 이는 특정 서비스로만 연결을 제한해야 한다는 요구 사항을 충족하지 못하며, 더 넓은 영향 범위(blast radius)로 인해 규제 환경에서 종종 허용되지 않습니다.

virtual private gateway(VGW)는 AWS PrivateLink가 아닌 Site-to-Site VPN 또는 Direct Connect에 사용됩니다. PrivateLink는 제공업체 측에 VGW를 요구하지 않으며, NLB가 지원하는 VPC endpoint service가 필요합니다. 이 옵션은 프라이빗 연결 메커니즘(VPN/DX)과 서비스 수준 프라이빗 액세스(PrivateLink) 간의 일반적인 혼동을 반영합니다.

NAT gateway는 private subnet의 인스턴스가 퍼블릭 IP를 통해 인터넷으로 아웃바운드 연결을 시작할 수 있게 해줍니다. 서드파티 VPC 서비스에 대한 프라이빗 연결을 생성하지 않으며, 일반적으로 퍼블릭 인터넷을 통해 트래픽을 라우팅합니다(대상이 AWS에 있더라도). 이는 "완전히 프라이빗" 요구 사항을 위반하며 특정 서비스에만 액세스를 제한하지 않습니다.