AWS DEA-C01 기출 문제풀이 Day 02 — Glue Workflow·Redshift Data API·Athena Workgroup 등 5문제

AWS DEA-C01 문제로 공부하기 — Day 02

Glue 워크플로, Redshift Data API, Athena 작업 그룹, FLEX 실행 클래스, S3 이벤트 알림까지 — 5문제로 Domain 1 심화 개념을 정리합니다.

AWS DEA-C01 Domain 1 · 데이터 수집·변환·오케스트레이션 5문제

📋 목차

• Q6 Glue 파이프라인 오케스트레이션 — 가장 비용 효율적인 방법
• Q7 웹앱에서 Redshift 실시간 쿼리 — 운영 오버헤드 최소화
• Q8 Athena 쿼리·이력 접근 권한 분리
• Q9 Glue 작업 비용 절감 — FLEX 실행 클래스
• Q10 S3 .csv 업로드 시 Lambda 자동 실행

Q6 Glue · 오케스트레이션 · 비용 ⭐ 자주 출제

AWS Glue 워크플로(Workflow)는 Glue 크롤러·ETL 작업·트리거를 하나의 파이프라인으로 묶어 오케스트레이션하는 기능입니다. Step Functions이나 MWAA 없이 Glue 안에서 모든 것을 해결할 수 있어 비용과 운영 부담이 가장 낮습니다. DEA-C01에서 "Glue 파이프라인 오케스트레이션 + 비용 효율" 조합으로 자주 출제됩니다.

📋 Question

한 회사가 AWS Glue에 ETL(추출, 변환, 로드) 데이터 파이프라인을 구축했습니다. 데이터 엔지니어는 Microsoft SQL Server에 있는 테이블을 크롤링해야 합니다. 크롤링 결과를 추출, 변환, 로드하여 Amazon S3 버킷에 저장해야 합니다. 또한 데이터 엔지니어는 데이터 파이프라인을 오케스트레이션해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 AWS 서비스 또는 기능은 무엇일까요?

• AAWS 스텝 함수
  ❌ AWS Step Functions — 상태 머신(State Machine) 기반 워크플로 서비스. 요리 레시피 관리자. Lambda·EMR·Glue 등 다양한 서비스를 연결하는 범용 오케스트레이터. 기능은 강력하지만 Glue 전용이 아니라 추가 비용과 설정 부담 발생. Glue만 쓰는 파이프라인엔 과함.
• BAWS Glue 워크플로
  ✅ AWS Glue 워크플로(Workflow) — Glue 크롤러·ETL 작업·트리거를 하나의 DAG(방향 비순환 그래프)로 묶는 내장 오케스트레이션 기능. 공장 라인 전체를 한 콘솔에서 관리. 별도 서비스 없이 Glue 내에서 완결되므로 추가 비용 없음. 이 문제의 모든 요건(크롤러 → ETL → S3 적재)을 하나로 처리.
• CAWS 글루 스튜디오
  ❌ AWS Glue Studio — 드래그앤드롭 GUI로 ETL 작업을 시각적으로 만드는 작업 편집기. 요리사가 레시피를 그림으로 그리는 도구. ETL 작업을 만들 때 쓰는 것이지, 여러 작업을 순서대로 실행하는 오케스트레이션 도구가 아님.
• D아마존 관리형 워크플로우(Amazon MWAA)를 이용한 아파치 에어플로우
  ❌ Amazon MWAA(Managed Workflows for Apache Airflow) — 완전 관리형 Apache Airflow. 수백 개 복잡한 파이프라인을 Python DAG로 관리하는 현장 소장. 강력하지만 환경 구성 비용 + 시간당 요금이 발생. Glue만 오케스트레이션하는 단순 케이스엔 비용 대비 과도한 선택.

🎯

정답

B — AWS Glue 워크플로로 Glue 파이프라인 내장 오케스트레이션

🔑 핵심 개념 — Glue 오케스트레이션 옵션 비교

서비스	비유	Glue 전용?	추가 비용	적합도
Glue Workflow	🏭 공장 내장 라인 컨트롤러	✓ 전용	없음	✓ 최적
Step Functions	📋 범용 레시피 관리자	범용	상태 전환당 요금	과함
MWAA (Airflow)	🏗️ 대형 현장 소장	범용	시간당 환경 요금	비용 과다
Glue Studio	🎨 ETL 작업 편집기	편집 도구	없음(오케스트레이션 아님)	용도 다름

💡 이것만 기억하자

Glue 파이프라인만 오케스트레이션 → Glue Workflow (무료, 내장)
멀티 서비스 복잡한 워크플로 → Step Functions
대규모 Python DAG 관리 → MWAA (Airflow)

Glue Studio = 작업 만드는 편집기 ≠ 오케스트레이션

---

Q7 Redshift · Data API · 웹 앱 연동 ⭐ 자주 출제

Amazon Redshift Data API는 JDBC/ODBC 드라이버 없이 HTTP 요청만으로 Redshift에 쿼리를 실행할 수 있는 서비스입니다. 웹·모바일 앱처럼 비동기·단기 연결이 필요한 환경에서 운영 부담 없이 Redshift와 연동할 수 있어 DEA-C01에서 자주 출제됩니다.

📋 Question

금융 서비스 회사가 아마존 레드시프트에 금융 데이터를 저장합니다. 데이터 엔지니어는 웹 기반 거래 애플리케이션을 지원하기 위해 금융 데이터에 대한 실시간 쿼리를 실행하려고 합니다. 데이터 엔지니어는 거래 애플리케이션 내에서 쿼리를 실행하기를 원합니다. 이러한 요구 사항을 충족하면서 운영 오버헤드를 최소화하는 솔루션은 무엇일까요?

• AAmazon Redshift에 WebSocket 연결을 설정합니다.
  ❌ WebSocket — 클라이언트-서버 간 양방향 실시간 통신 프로토콜. Redshift는 WebSocket 연결을 네이티브로 지원하지 않음. 별도 중간 서버(예: API Gateway + Lambda)가 필요해 운영 오버헤드가 증가.
• B아마존 레드시프트 데이터 API를 사용합니다.
  ✅ Amazon Redshift Data API — HTTP 기반 비동기 쿼리 실행 API. 카페 무인 주문기처럼 앱에서 버튼 누르면 주문(쿼리)이 접수되고 결과를 나중에 가져오는 방식. JDBC 드라이버·영구 DB 연결·VPC 설정 없이 AWS SDK/HTTP 호출만으로 Redshift 쿼리 가능. 웹앱 연동에 최적.
• CAmazon Redshift에 대한 Java Database Connectivity(JDBC) 연결을 설정합니다.
  ❌ JDBC(Java Database Connectivity) — Java 애플리케이션이 DB에 연결하는 표준 드라이버 인터페이스. 영구적인 DB 커넥션이 필요해 웹앱에서 연결 관리·풀링·VPC 설정 등 운영 오버헤드가 높음. 전통적인 백엔드 서버에 적합하지 웹앱 직접 연동엔 부적합.
• D자주 액세스하는 데이터는 Amazon S3에 저장하고, Amazon S3 Select를 사용하여 쿼리를 실행합니다.
  ❌ Amazon S3 Select — S3 객체 내에서 SQL로 원하는 데이터만 필터링해 가져오는 기능. 데이터를 Redshift에서 S3로 복사해야 하고, 복잡한 SQL 분석보다 단순 필터링에만 적합. 실시간성이 낮고 데이터 이중화 문제 발생.

🎯

정답

B — Amazon Redshift Data API로 HTTP 기반 쿼리 실행

🔑 핵심 개념 — Redshift 연결 방식 비교

방식	비유	연결 방식	웹앱 적합?
Redshift Data API	☕ 무인 주문기	HTTP 비동기, 드라이버 불필요	✓ 최적
JDBC	🔌 유선 직통 전화	영구 TCP 연결, 드라이버 필요	✗ 오버헤드 큼
ODBC	🔌 유선 직통 전화(범용)	영구 TCP 연결, 드라이버 필요	✗ 오버헤드 큼
WebSocket	📡 양방향 무전기	Redshift 미지원, 중간 서버 필요	✗ 지원 안 함

💡 이것만 기억하자

"웹앱 + Redshift + 운영 최소화" → Redshift Data API

JDBC / ODBC = 드라이버·영구연결 필요 → 서버 백엔드에 적합
Data API = HTTP 비동기, 드라이버 없음 → 웹앱·Lambda·서버리스에 적합

---

Q8 Athena · 작업 그룹 · 접근 제어 ⭐ 자주 출제

Amazon Athena 작업 그룹(Workgroup)은 사용자·팀·애플리케이션별로 쿼리 실행과 쿼리 이력을 격리하는 기능입니다. IAM 정책과 태그를 조합해 쿼리 프로세스와 이력 접근 권한을 세밀하게 분리할 수 있어 DEA-C01 거버넌스·보안 도메인에서 자주 출제됩니다.

📋 Question

한 회사가 Amazon S3에 저장된 데이터에 대한 일회성 쿼리를 위해 Amazon Athena를 사용하고 있습니다. 이 회사는 여러 가지 사용 사례를 가지고 있으며, 동일한 AWS 계정 내의 사용자, 팀 및 애플리케이션 간에 쿼리 프로세스와 쿼리 기록에 대한 접근 권한을 분리하기 위한 권한 제어를 구현해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇일까요?

• A각 사용 사례별로 S3 버킷을 생성합니다. 적절한 개별 IAM 사용자에게 권한을 부여하는 S3 버킷 정책을 생성합니다. 생성된 S3 버킷 정책을 S3 버킷에 적용합니다.
  ❌ S3 버킷 정책은 데이터 파일 접근을 제어하는 것. 쿼리 프로세스 분리나 쿼리 이력(Query History) 격리는 불가능. 문제 요건의 절반만 해결함.
• B각 사용 사례별로 Athena 작업 그룹을 생성합니다. 작업 그룹에 태그를 적용합니다. 해당 태그를 사용하여 작업 그룹에 적절한 권한을 적용하는 IAM 정책을 생성합니다.
  ✅ Athena 작업 그룹(Workgroup) — 도서관의 개별 열람실. 팀마다 열람실이 달라 서로의 대출 이력(쿼리 이력)을 못 봄. 작업 그룹별로 쿼리 실행 격리 + 쿼리 이력 분리 + 결과 저장 위치 분리 + 비용 추적이 모두 가능. 태그 기반 IAM 정책으로 그룹별 접근 권한 세밀하게 제어.
• C각 사용 사례에 대한 IAM 역할을 생성합니다. 각 사용 사례에 적합한 권한을 역할에 할당합니다. 해당 역할을 Athena와 연결합니다.
  ❌ IAM 역할로 데이터 접근 권한은 제어 가능하지만 쿼리 이력 격리는 불가능. 같은 Athena 환경에서 실행하면 이력이 공유됨. 작업 그룹 없이는 완전한 분리가 안 됨.
• D각 사용 사례에 대해 적절한 개별 IAM 사용자에게 권한을 부여하는 AWS Glue 데이터 카탈로그 리소스 정책을 생성합니다. 해당 리소스 정책을 Athena에서 사용하는 특정 테이블에 적용합니다.
  ❌ Glue Data Catalog 리소스 정책 — 메타데이터 카탈로그(테이블·데이터베이스 정의)에 대한 접근 제어. 데이터 카탈로그 접근은 제한 가능하지만 Athena 쿼리 프로세스와 이력 분리는 해결 안 됨.

🎯

정답

B — Athena 작업 그룹 + 태그 기반 IAM 정책

🔑 핵심 개념 — Athena Workgroup이 격리하는 것

격리 대상	Workgroup으로 가능?	S3 버킷 정책으로?	IAM 역할만으로?
데이터 파일 접근	✓	✓	✓
쿼리 실행 격리	✓	✗	✗
쿼리 이력 분리	✓ 핵심	✗	✗
결과 저장 위치 분리	✓	부분	✗
팀별 비용 추적	✓	✗	✗

💡 이것만 기억하자

"Athena 쿼리 프로세스 + 이력 격리" → Athena Workgroup

S3 버킷 정책 = 데이터 파일 접근만 제어
IAM 역할 = 권한 제어, 이력 격리 안 됨
Workgroup = 쿼리 실행 + 이력 + 결과 위치 + 비용 모두 격리

---

Q9 Glue · 비용 최적화 · FLEX ⭐ 자주 출제

AWS Glue FLEX 실행 클래스는 유휴 AWS 인프라를 활용해 표준 요금보다 저렴하게 Glue 작업을 실행하는 옵션입니다. 특정 완료 시각이 중요하지 않은 비긴급 배치 작업에 적합하며, DEA-C01에서 "Glue 비용 절감" 키워드와 함께 자주 출제됩니다.

📋 Question

데이터 엔지니어는 AWS Glue 작업 세트를 매일 실행하는 워크플로우를 예약해야 합니다. Glue 작업이 특정 시간에 실행되거나 완료될 필요는 없습니다. 어떤 솔루션이 가장 비용 효율적인 방식으로 Glue 작업을 실행할까요?

• AGlue 작업 속성에서 FLEX 실행 클래스를 선택합니다.
  ✅ FLEX 실행 클래스(FLEX Execution Class) — AWS의 여유 컴퓨팅 자원(스팟처럼)을 활용해 실행되는 Glue 전용 절약 옵션. 심야 할인 택시처럼 언제 배차될지 정확하지 않지만 요금이 저렴. STANDARD 대비 약 34% 저렴. "특정 시간에 완료될 필요 없다"는 조건과 완벽하게 부합.
• BGlue 작업 속성에서 스팟 인스턴스 유형을 사용하십시오.
  ❌ 스팟 인스턴스(Spot Instance) — EC2 유휴 용량을 저렴하게 사용하는 옵션. Glue 작업 속성에 스팟 인스턴스 유형 선택 항목은 없음. 스팟 인스턴스는 EMR 클러스터 구성에서 선택하는 것. 존재하지 않는 옵션을 고르는 함정 보기.
• CGlue 작업 속성에서 STANDARD 실행 클래스를 선택합니다.
  ❌ STANDARD 실행 클래스 — Glue의 기본(정가) 실행 옵션. 예측 가능한 실행 시간과 성능이 보장되지만 가장 비쌈. "비용 효율적"이라는 조건과 반대.
• D접착 작업 속성의 GlueVersion 필드에서 최신 버전을 선택하십시오.
  ❌ GlueVersion — Glue 런타임 버전(예: 4.0). 최신 버전을 쓰면 성능이 향상될 수 있지만 비용을 직접 절감하는 옵션이 아님. 버전 선택은 비용 최적화와 무관.

🎯

정답

A — FLEX 실행 클래스로 비긴급 작업 비용 절감

🔑 핵심 개념 — Glue 실행 클래스 비교

실행 클래스	비유	비용	실행 시간 보장	적합 워크로드
FLEX	🌙 심야 할인 택시	저렴 (~34%↓)	보장 안 됨	비긴급 배치, 야간 처리
STANDARD	🚕 일반 택시	정가	보장됨	시간 민감한 작업

💡 이것만 기억하자

"Glue 비용 절감 + 완료 시각 무관" → FLEX 실행 클래스

FLEX = 심야 할인 택시 (저렴, 언제 올지 모름)
STANDARD = 일반 택시 (정가, 예측 가능)

Glue에 스팟 인스턴스 옵션은 없음 → EMR에서 쓰는 개념!

---

Q10 S3 이벤트 알림 · Lambda · 트리거 ⭐ 자주 출제

S3 이벤트 알림(Event Notification)은 객체 업로드·삭제 등 이벤트 발생 시 Lambda·SNS·SQS를 자동으로 실행하는 기능입니다. 이벤트 유형과 접미사 필터를 조합하면 .csv 파일 업로드 시에만 Lambda를 직접 트리거할 수 있으며, DEA-C01 이벤트 기반 처리 유형에서 자주 출제됩니다.

📋 Question

데이터 엔지니어가 .csv 파일 형식을 Apache Parquet 형식으로 변환하는 AWS Lambda 함수를 생성해야 합니다. 이 Lambda 함수는 사용자가 Amazon S3 버킷에 .csv 파일을 업로드한 경우에만 실행되어야 합니다. 이러한 요구 사항을 충족하면서 운영 오버헤드를 최소화하는 솔루션은 무엇일까요?

• A이벤트 유형이 s3:ObjectCreated:*인 S3 이벤트 알림을 생성합니다. 접미사에 .csv가 포함된 경우에만 알림이 생성되도록 필터 규칙을 사용합니다. 이벤트 알림의 대상으로 Lambda 함수의 ARN(Amazon Resource Name)을 설정합니다.
  ✅ s3:ObjectCreated:* — PUT·POST·COPY·멀티파트 업로드 완료 등 객체 생성 이벤트 전체를 포함. 접미사 필터(.csv) — 확장자로 이벤트를 걸러내는 규칙. ARN(Amazon Resource Name) — AWS 리소스의 고유 식별자. S3 → Lambda 직접 연결로 중간 서비스 없이 운영 오버헤드 최소화. 조건을 정확히 모두 충족.
• B태그가 .csv로 설정된 객체에 대해 이벤트 유형이 s3:ObjectTagging:*인 S3 이벤트 알림을 생성합니다. 이벤트 알림의 대상으로 Lambda 함수의 Amazon 리소스 이름(ARN)을 설정합니다.
  ❌ s3:ObjectTagging:* — 객체에 태그를 붙이는 이벤트. 파일 업로드(ObjectCreated)와 완전히 다른 이벤트. 사용자가 .csv를 업로드해도 자동으로 태그가 붙지 않으면 Lambda가 실행되지 않음. 업로드 감지 자체가 안 됨.
• C이벤트 유형이 s3:*인 S3 이벤트 알림을 생성합니다. 접미사에 .csv가 포함된 경우에만 알림이 생성되도록 필터 규칙을 사용합니다. 이벤트 알림의 대상으로 Lambda 함수의 ARN(Amazon Resource Name)을 설정합니다.
  ❌ s3:* — S3의 모든 이벤트(업로드, 삭제, 복사, 태그 변경 등 전부). 접미사 필터로 .csv는 걸러지지만 삭제·복사 등 불필요한 이벤트에도 Lambda가 실행될 수 있음. 정확한 이벤트 유형(ObjectCreated)을 지정하는 A보다 범위가 너무 넓음.
• D이벤트 유형이 s3:ObjectCreated:*인 S3 이벤트 알림을 생성합니다. 접미사에 .csv가 포함된 경우에만 알림이 생성되도록 필터 규칙을 사용합니다. 이벤트 알림의 대상으로 Amazon Simple Notification Service(Amazon SNS) 토픽을 설정합니다. Lambda 함수를 SNS 토픽에 구독합니다.
  ❌ S3 → SNS → Lambda 경로는 기술적으로 작동하지만, Amazon SNS(Simple Notification Service) — 방송 스피커(Pub/Sub) 서비스 — 를 중간에 끼면 불필요한 레이어 추가 = 운영 오버헤드 증가. Lambda 여러 곳에 동시 팬아웃이 필요할 때 쓰는 패턴. 단일 Lambda 트리거엔 직접 연결(A)이 최적.

🎯

정답

A — ObjectCreated + .csv 필터 → Lambda 직접 연결

🔑 핵심 개념 — S3 이벤트 유형 & 대상 비교

선택지	이벤트 유형	필터	대상	문제점
A (정답)	ObjectCreated:*	.csv 접미사	Lambda 직접	✓ 완벽
B	ObjectTagging:*	태그	Lambda 직접	업로드 감지 안 됨
C	s3:* (전체)	.csv 접미사	Lambda 직접	이벤트 범위 과다
D	ObjectCreated:*	.csv 접미사	SNS → Lambda	불필요한 SNS 레이어

💡 이것만 기억하자

"파일 업로드 감지" → s3:ObjectCreated:*
"확장자 필터" → 접미사(suffix) 필터 .csv
"단일 Lambda 트리거" → S3 → Lambda 직접 연결 (SNS 불필요)

S3 → SNS → Lambda = 여러 곳에 동시 팬아웃(fan-out)할 때만 사용

AWS DEA-C01 Glue Workflow Redshift Data API Athena Workgroup FLEX 실행 클래스 S3 이벤트 알림 Lambda 트리거 데이터 엔지니어 자격증 AWS 자격증