모의고사 2

IAM Identity Center 방향은 맞지만, 이 선택지는 단방향 트러스트를 지정합니다. 이 시험 패턴에서 자체 관리 Microsoft AD와의 기대 통합 방식은 AWS Managed Microsoft AD를 통한 양방향 포리스트 트러스트입니다. 함정: IAM Identity Center와 기존 AD 통합을 포함하므로 매력적으로 보이지만, 트러스트 모델이 맞지 않습니다.

AWS Directory Service만으로는 15개 AWS 계정 전반에 필요한 중앙 집중식 AWS 계정 SSO 경험을 제공하지 않습니다. 계정 할당과 통합 로그인을 담당하는 IAM Identity Center가 빠져 있습니다. 함정: 기존 AD와의 트러스트를 언급하므로 충분해 보일 수 있지만, 디렉터리 트러스트는 다중 계정 AWS SSO와 같지 않습니다.

온프레미스 IdP로 AWS에 페더레이션할 수는 있지만, 이미 AWS Organizations로 관리되는 많은 AWS 계정에 대한 중앙 접근에는 가장 효과적인 AWS 네이티브 솔루션이 아닙니다. 함정: SSO와 페더레이션이 관련되어 있어 그럴듯하지만, IAM Identity Center와 AD 통합 방식보다 운영 오버헤드가 더 큽니다.

FSx for Lustre로 직접 전송하는 DataSync 태스크는 이 선택지에 설명된 유효한 전송 경로가 아닙니다. DataSync가 지원되는 소스와 대상 조합에서는 파일을 인식하더라도, 대상 서비스 지원 여부가 중요합니다. 주의: DataSync가 POSIX 메타데이터를 보존한다는 점 때문에 맞아 보이지만, 대상에 대한 서비스 지원이 핵심입니다.

rsync로 S3에 넣으면 파일이 객체가 되어 관리형 전송이 시작되기 전에 네이티브 POSIX 의미가 손실될 수 있습니다. 이는 명시된 메타데이터 및 심볼릭 링크 요구 사항과 충돌합니다. 주의: S3 스테이징은 확장성 있어 보이지만, 첫 복사 단계가 규정 준수 가능한 파일 시스템 인식 마이그레이션이 아닙니다.

Snowmobile은 대규모 다중 PB 또는 엑사바이트 마이그레이션을 위한 서비스이므로 500TB에는 과도합니다. 또한 POSIX 보존 요구 사항을 개선하지 못한 채 S3 스테이징을 추가합니다. 주의: 오프라인 전송 서비스이긴 하지만, 규모상 Snowball Edge가 맞습니다.

CloudFormation과 Systems Manager Automation은 프로비저닝을 표준화할 수 있지만, 별도 가드레일이 없으면 팀이 템플릿 밖에서 리소스를 생성하는 것을 막지 못합니다. 주의: 템플릿은 통제처럼 보이지만, 문제는 계정 전반의 중앙 집중식 예방을 요구합니다.

EventBridge와 Lambda는 고가 리소스가 시작된 후에 반응하므로 비용이 이미 발생할 수 있고, 사용자 지정 정리 로직을 계속 유지해야 합니다. 주의: 자동 종료는 보호처럼 보이지만 예방 제어가 아니라 탐지 후 조치입니다.

Service Catalog는 승인된 제품을 제공할 수 있지만, 다른 모든 프로비저닝 경로를 막으려면 추가 IAM 또는 SCP 제어와 더 많은 관리가 필요합니다. 주의: 셀프서비스 표준화에는 유용하지만 가장 단순한 계정 전체 거부 가드레일은 아닙니다.

읽기 전용 마운트 옵션은 운영 체제 설정이므로 인스턴스마다 달라질 수 있고 권한 있는 사용자가 변경할 수도 있습니다. 주의: 읽기 전용처럼 들리지만, 문제는 IAM 기반 적용을 요구합니다.

ID 기반 거부도 특정 역할을 차단할 수 있지만, 각 역할을 올바르게 관리해야 하며 새 역할이 누락될 수 있습니다. 공유 파일 시스템에는 리소스 정책이 더 중앙 집중적이고 운영 효율적인 제어입니다. 주의: IAM을 사용하지만 제어 지점을 공유 EFS 리소스가 아니라 각 ID에 둡니다.

액세스 포인트와 POSIX 권한은 디렉터리 액세스를 제한할 수 있지만, 모든 EFS 클라이언트 쓰기를 차단하라는 IAM 기반 보장을 직접 충족하지 않습니다. 주의: POSIX 권한은 유용하지만, 요구 사항이 IAM 액세스 제어를 명시할 때 가장 강한 답은 아닙니다.

피어링된 VPC로 용량을 늘릴 수는 있지만, 다른 VPC, 라우팅 테이블 업데이트, 피어링 관리, 교차 VPC 보안 규칙이 필요합니다. 주의: 기술적으로는 가능하지만, 시나리오는 가장 적은 운영 오버헤드를 요구합니다.

Transit Gateway는 여러 VPC의 허브 앤 스포크 네트워크에 유용하지만, 단일 VPC에 IP만 더 필요한 상황에는 불필요하게 복잡합니다. 주의: TGW는 확장성 있게 들리지만 연결성 문제를 해결하는 서비스이지 가장 단순한 주소 확장 방법은 아닙니다.

VPN 인스턴스와 게이트웨이는 관리 부담이 가장 크며, AWS 내부 VPC 주소 고갈 문제에는 필요하지 않습니다. 주의: VPN은 네트워크를 연결할 수 있지만 이 문제에는 배포가 느리고 운영 부담이 큽니다.

Storage Gateway Volume Gateway는 iSCSI를 통해 블록 볼륨을 노출합니다. POSIX 병렬 파일 시스템이 아니며 100개 이상의 노드에 Lustre 방식 병렬 I/O를 제공하지 않습니다. 주의: 게이트웨이라는 표현 때문에 하이브리드 스토리지에 유용해 보일 수 있지만, 이 워크로드에는 블록 스토리지 표현이 아니라 HPC 파일 의미 체계가 필요합니다.

EBS RAID와 자체 관리 파일 시스템 소프트웨어를 얹은 EC2 인스턴스는 완전 관리형이 아니며 확장성, 메타데이터 처리, 가용성 병목이 생길 수 있습니다. 주의: RAID는 한 서버의 스토리지 성능을 높일 수 있지만, 시나리오는 완전 관리형 병렬 파일 시스템을 요구합니다.

Amazon EFS는 NFS 기반 관리형 POSIX 파일 스토리지를 제공하지만, 밀리초 미만 지연 시간과 Lustre 의미 체계가 필요한 HPC 병렬 I/O 워크로드에는 최적의 선택이 아닙니다. 주의: EFS는 공유형이고 관리형이라 매력적이지만, 병렬 파일 시스템과 HPC 지연 시간 단서는 FSx for Lustre를 가리킵니다.

project-code는 AWS 정의 태그가 아니라 조직의 태깅 정책으로 적용되는 회사 태그입니다. 주의: 관리 계정 부분은 맞지만 태그 유형이 틀렸습니다.

멤버 계정에서 태그를 활성화해도 조직 전체 통합 결제 분석을 중앙에서 사용할 수 있게 되지는 않습니다. 주의: 태그 유형은 맞지만 결제 제어 지점이 틀렸습니다.

고객 비즈니스 태그에 대해 잘못된 계정 범위와 잘못된 태그 유형을 모두 사용합니다. 주의: Cost Explorer를 언급하지만 핵심 거버넌스 세부 사항 두 가지를 놓쳤습니다.

기본 보존 기간만 설정해도 보존 종료 시 객체가 삭제되지는 않습니다. 요구 사항에는 90일 후 자동 삭제가 포함됩니다. 주의: 90일 설정처럼 보이지만 Lifecycle 정리 작업을 제공하지 않습니다.

Lifecycle 정책은 객체를 만료하거나 전환하지만 조기 삭제로부터 보호하는 규정 준수 보존을 제공하지 않습니다. 주의: 삭제에는 Lifecycle이 필요하지만 보존 보호 역할은 아닙니다.

태그는 정책 필터링에 도움을 줄 수 있지만 태그만으로 보존이나 자동 삭제를 강제하지는 않습니다. 주의: 태그는 Lifecycle 규칙에서 사용할 수 있지만 보존 메커니즘 자체는 아닙니다.

Network Access Analyzer는 IAM 사용자 권한이나 정책 권한이 아니라 네트워크 도달 가능성 경로를 확인합니다. 주의: Analyzer라는 단어가 유혹적이지만 영역은 네트워킹입니다.

생성 또는 수정 이벤트에 대한 CloudWatch 경보는 현재의 모든 IAM 권한을 검토하거나 과도한 권한 사용자를 식별하지 못합니다. 주의: 활동 알림은 가능하지만 권한 감사는 아닙니다.

Amazon Inspector는 IAM 정책 분석이 아니라 워크로드의 소프트웨어 취약점과 노출에 초점을 둡니다. 주의: Inspector도 보안 서비스지만 시험에서 묻는 문제 영역이 다릅니다.