모의고사 2

Lake Formation 데이터 필터는 S3 prefix를 데이터 위치로 등록하지 않습니다. 등록과 필터링은 서로 다른 Lake Formation 단계입니다. 주의: 올바른 서비스 용어를 사용하지만 두 가지 Lake Formation 구성을 잘못 결합했습니다.

데이터 필터는 IAM 역할에 연결하지 않습니다. Lake Formation은 데이터 필터를 사용해 principal에 권한을 부여합니다. 주의: 서로 다른 IAM 역할은 중요하지만, 필터는 IAM policy처럼 연결하는 것이 아니라 Lake Formation 권한 부여에서 참조합니다.

별도 버킷을 만들면 새 버킷이나 중복 데이터를 피하라는 요구 사항을 위반하고 운영 부담도 늘어납니다. 주의: 버킷 수준 IAM policy로 객체를 격리할 수는 있지만, 이 시나리오는 하나의 S3 데이터 레이크에 대한 중앙화된 쿼리 시점 거버넌스를 요구합니다.

S3 Glacier Deep Archive는 대시보드가 15분마다 쿼리해야 하는 데이터에 적합하지 않습니다. Athena가 분석하기 전에 객체 복원 워크플로가 필요합니다. 주의: 스토리지 비용은 줄일 수 있지만, 문제는 활성 Athena 쿼리 비용과 SLA를 만족하는 접근성입니다.

Athena query result reuse는 동일한 SQL이 이전 결과를 재사용할 수 있을 때만 도움이 되며 최초 스캔 비용을 줄이지 않습니다. 대시보드 쿼리는 시간 범위나 필터가 달라지는 경우가 많습니다. 주의: 캐싱은 노력이 적어 보이지만 모든 쿼리의 스캔량을 줄이는 것보다 적용 범위가 좁습니다.

ElastiCache는 새 인프라, 통합 작업, 캐시 무효화, 운영을 추가합니다. 이는 새 인프라 없음과 최소 부담 요구 사항에 맞지 않습니다. 주의: 애플리케이션 캐싱은 반복 읽기를 줄일 수 있지만 Athena 데이터 레이크의 기본 최적화 방식은 아닙니다.

ALL distribution은 테이블을 모든 노드에 복제하므로 작은 dimension table에 적합합니다. 3 TB까지 커지는 넓은 테이블에는 맞지 않습니다. 주의: 작은 참조 데이터 조인은 빠르게 만들 수 있지만, 대형 fact table에서는 스토리지와 로드 부담이 크게 증가합니다.

EVEN distribution은 나쁜 key 선택은 피하지만 여전히 고정된 수동 선택이며, 유지 관리 최소화 요구를 가장 잘 충족하지는 못합니다. 주의: key가 없을 때 EVEN은 합리적인 대안이지만, Redshift 관리형 최적화가 선택지에 있으면 AUTO가 더 강한 답입니다.

KEY distribution에는 안정적이고 고르게 분포한 조인 key가 필요하지만, 문제에서 적합한 컬럼이 없다고 명시했습니다. 주의: DISTKEY는 일반적인 조인과 잘 맞을 때 강력하지만, 좋지 않은 key는 skew와 향후 재작업을 유발합니다.

별도 S3 버킷은 격리 지점을 저장소로 옮기며, 같은 S3 버킷을 계속 사용하고 데이터를 복제하지 말라는 요구 사항과 충돌합니다. 주의: 버킷 정책은 익숙한 격리 도구이지만 Athena 쿼리 기록, 저장된 쿼리, 실행 비용을 격리하지는 않습니다.

IAM 역할은 권한을 부여할 수 있지만 역할만으로는 Athena 저장된 쿼리, 쿼리 기록, 비용 제어의 별도 경계를 만들지 못합니다. 주의: 팀별 역할은 접근 격리처럼 보이지만, 문제는 리소스 태그 적용과 workgroup 범위 산출물을 요구합니다.

Glue Data Catalog 정책은 테이블 메타데이터 접근을 제어할 수 있지만 Athena 실행 리소스, 저장된 쿼리, 쿼리 기록, 비용은 격리하지 못합니다. 주의: Glue는 Athena 메타데이터에 관여하지만, 요청된 격리는 Athena의 운영 제어 플레인에 있습니다.

MWAA, Lambda, Step Functions 조합은 과도하며 Lambda는 PostgreSQL 로그와 100 GB 티켓 이력을 조인하는 데 적합하지 않습니다. 주의: 각 서비스는 관리형이지만 함께 사용하면 오케스트레이션이 중복되고 사용자 지정 코드가 늘어납니다.

AppFlow와 Glue는 데이터 소스에 적합하지만, MWAA는 매일 밤 한 번 실행되는 단순 워크플로에 관리해야 할 Airflow 환경을 추가합니다. 주의: Airflow는 유효한 오케스트레이터이지만 문제는 최소 운영 부담을 묻고 있습니다.

Kinesis Data Streams와 Managed Service for Apache Flink는 스트리밍 서비스지만 요구 사항은 야간 배치 프로세스입니다. 주의: 스트리밍 상호 연관은 강력해 보이지만 하루 한 번 실행에는 불필요한 비용과 운영을 추가합니다.

AWS Glue는 서버리스 Spark ETL에 유용하지만, 특히 HBase와 Oozie를 포함한 전체 Hadoop 생태계를 제공하지 않습니다. 주의: 가능한 경우 서버리스라는 표현은 Glue를 떠올리게 하지만, 명시된 프레임워크 때문에 Glue만으로는 부족합니다.

Lambda는 Spark, Flink, HBase, Oozie를 분산 처리 플랫폼으로 실행할 수 없으며, 멀티 페타바이트 ETL 실행에도 적합하지 않습니다. 주의: 운영 부담은 낮지만 Hadoop 런타임이 아니라 이벤트 기반 함수 컴퓨팅입니다.

Amazon Redshift는 SQL 분석과 ELT를 위한 데이터 웨어하우스이지 Spark, Flink, HBase 또는 Oozie 워크플로의 관리형 런타임이 아닙니다. 주의: Redshift는 SQL로 데이터를 변환할 수 있지만 기존 프레임워크를 계속 사용해야 한다는 요구 사항을 충족하지 않습니다.

Athena 결과 위치와 암호화를 변경하는 것은 SQL 쿼리 출력 저장소에만 영향을 주며, PySpark notebook이나 Spark 실행을 활성화하지 않습니다. 주의: 결과 설정은 실제 Athena 설정이지만, 요청된 컴퓨트 엔진과는 관련이 없습니다.

Athena data 소스 connector는 외부 시스템을 federated 쿼리하기 위한 것이며, S3 데이터에 Apache Spark 실행 시간 지원을 추가하는 기능이 아닙니다. 주의: Glue Data Catalog는 Athena 메타데이터의 일부이지만, 거기에 connector를 등록한다고 Spark notebook이 생기지는 않습니다.

Spark 실행은 SQL editor의 쿼리별 토글이 아닙니다. Athena는 workgroup으로 Spark 워크로드를 구성하고 관리합니다. 주의: UI에서 여러 경험을 제공할 수는 있지만 운영 경계는 여전히 workgroup입니다.

sort key는 predicate에 대해 스캔되는 블록을 줄일 수 있지만, 어떤 노드가 행을 소유하는지는 바꾸지 않습니다. 주의: WHERE 절 튜닝은 많은 Redshift 쿼리에 도움이 되지만, 여기의 증상은 distribution skew로 인한 노드 불균형입니다.

더 큰 RA3 노드는 용량을 추가하지만 불균등한 데이터 배치를 해결하지 않으며 워크로드를 고르게 분산하려는 의도에도 맞지 않습니다. 주의: CPU를 더 추가하면 과열 노드를 잠시 가릴 수 있지만, 나머지 다섯 노드는 계속 낮게 사용됩니다.

primary key를 변경해도 Redshift에서 데이터가 재분산되지 않습니다. primary key는 OLTP 데이터베이스 제약 조건처럼 강제되지 않습니다. 주의: 테이블 설계 수정처럼 들리지만, Redshift의 물리적 배치는 distribution style과 key가 제어합니다.

Aurora를 publicly accessible로 만들면 private 연결 요구 사항을 위반하며, 인터넷 게이트웨이 라우트가 없는 private subnet 조건에도 맞지 않습니다. 주의: Public accessibility가 일부 외부 연결 문제를 해결할 수는 있지만, 이 시나리오는 공용 인터넷 통과를 명시적으로 금지합니다.

Security group에는 Lambda function invocations라는 원본 type이 없습니다. 네트워크 접근은 CIDR, prefix list 또는 보안 그룹 참조로 허용합니다. 주의: Lambda invocation 권한은 별도의 리소스 정책 개념이며 VPC 네트워크 트래픽을 열어 주지 않습니다.

network ACL self-reference는 보안 그룹 방식의 유효한 제어가 아니며, 상태 비저장 subnet 규칙 복잡성만 늘립니다. 핵심 문제는 Lambda VPC 배치와 보안 그룹 접근입니다. 주의: NACL은 네트워크 제어이지만 Lambda ENI가 Aurora에 접근하게 하는 가장 운영 부담이 적은 도구는 아닙니다.