AWS DEA-C01 각색 문제 Day 01 — VPC·Lake Formation·Lambda 5문제

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

VPC 네트워킹, Lake Formation 거버넌스, Data Exchange, 데이터 메시, Lambda Layer까지 — 5문제로 Domain 1 핵심 개념을 한 번에 정리합니다.

AWS DEA-C01 Domain 1 · 데이터 수집·변환 5문제

📋 목차

• Q1 AWS Glue ETL 작업의 S3 VPC Endpoint 연결 오류 해결
• Q2 지역별 고객 데이터 접근 제한 — 운영 부담 최소화
• Q3 추천 시스템 고도화를 위한 외부 데이터 통합
• Q4 분산 데이터 아키텍처(Data Mesh) 구현 서비스 조합
• Q5 여러 Lambda 함수에서 공유 코드 일괄 관리

Q1 VPC · Networking · Glue ⭐ 자주 출제

AWS Glue를 VPC 환경에서 실행할 때 S3 연결 오류가 나는 원인 중 하나가 VPC Gateway Endpoint 라우팅 테이블 미설정입니다. 네트워크 경로 vs 권한 문제를 구분하는 것이 핵심이며, DEA-C01에서 Glue + VPC 트러블슈팅 유형으로 자주 출제됩니다.

📋 Question

데이터 팀이 VPC 내에서 실행되는 AWS Glue ETL 작업을 통해 Amazon S3의 데이터를 처리하고 있습니다. Glue 연결 설정과 IAM 권한은 이미 구성되어 있지만, 작업 실행 시 S3 VPC 게이트웨이 엔드포인트와 관련된 오류가 발생합니다. 이 연결 문제를 해결하려면 어떻게 해야 할까요?

• AS3 VPC 게이트웨이 엔드포인트로부터의 트래픽을 허용하도록 Glue 작업에 연결된 보안 그룹의 인바운드 규칙을 수정합니다.
  ❌ 보안 그룹(Security Group) — 출입구 경비원. Gateway Endpoint에는 경비원이 없음. 보안 그룹은 Interface Endpoint(전용 직통 전화선)에만 붙는 개념. Gateway는 라우팅 테이블이 담당.
• BGlue 작업이 대상 S3 버킷에 접근할 수 있도록 버킷 리소스 기반 정책에 명시적 허용 구문을 추가합니다.
  ❌ S3 버킷 정책(Bucket Policy) — 창고 출입 명단. IAM 권한은 이미 설정됐다고 전제되어 있음. 권한 문제가 아닌 네트워크 경로 문제. 명단 수정해봤자 길이 없으면 못 감.
• CGlue 연결 설정에서 S3 엔드포인트의 전체 도메인 이름(FQDN)이 올바르게 지정되어 있는지 확인합니다.
  ❌ FQDN(Fully Qualified Domain Name) — 완전 정규화 도메인 이름 (예: s3.ap-northeast-2.amazonaws.com). Gateway Endpoint는 도메인이 아닌 Prefix List(IP 대역 묶음) 기반으로 라우팅. FQDN 수정은 이 오류와 무관.
• DGlue 작업이 실행되는 서브넷의 라우팅 테이블에 S3 VPC 게이트웨이 엔드포인트를 향하는 경로가 등록되어 있는지 확인합니다.
  ✅ 라우팅 테이블(Routing Table) — 내비게이션 경로표. S3 Gateway Endpoint를 만들어도 VPC 서브넷의 라우팅 테이블에 "S3 → 엔드포인트" 경로가 등록되어야 트래픽이 흐름. 경로 없으면 차가 고속도로 무시하고 일반 인터넷으로 나가려다 차단 → 정확히 이 오류.

🎯

정답

D — VPC 라우팅 테이블에 Gateway Endpoint 경로 추가

🔑 핵심 개념 — Gateway Endpoint vs Interface Endpoint

구분	Gateway Endpoint	Interface Endpoint (PrivateLink)
지원 서비스	S3  DynamoDB	그 외 대부분의 AWS 서비스
실생활 비유	🛣️ 전용 고속도로 내비게이션(라우팅 테이블)에 경로 등록 필수	📞 전용 직통 전화선(ENI) 경비원(보안 그룹)이 통제
트래픽 제어	라우팅 테이블	보안 그룹(Security Group)
비용	무료 🎉	시간당 요금 💸
흔한 오류 원인	라우팅 테이블 경로 누락	보안 그룹 인바운드 차단

💡 이것만 기억하자

Gateway Endpoint (S3 · DynamoDB) → 라우팅 테이블 (내비게이션 경로)
Interface Endpoint (그 외 서비스) → 보안 그룹 (출입구 경비원)

"VPC 게이트웨이 엔드포인트 오류" = 라우팅 테이블 먼저 확인!

---

Q2 Lake Formation · 거버넌스 · 보안 ⭐ 자주 출제

AWS Lake Formation의 행 수준 보안(Row-Level Security)은 데이터 레이크에서 국가·부서별 접근 제어를 운영 부담 없이 구현하는 핵심 기능입니다. 테이블을 나누거나 리전을 분리하지 않고도 단일 데이터셋에서 정책 기반으로 접근을 제한할 수 있어 DEA-C01 거버넌스·보안 도메인에서 자주 출제됩니다.

📋 Question

한 이커머스 기업이 여러 국가의 고객 데이터를 Amazon S3에 통합 저장하여 분석에 활용하고 있습니다. 데이터 거버넌스 팀은 각 국가 담당 분석가가 자신이 담당하는 국가의 고객 데이터에만 접근하도록 제한해야 하며, 국가가 추가되어도 관리 작업을 최소화할 수 있는 솔루션이 필요합니다. 가장 적합한 방법은 무엇일까요?

• A국가별로 별도의 테이블을 생성하고, 각 분석가에게 담당 국가의 테이블에 대한 접근 권한만 개별 부여합니다.
  ❌ 🗂️ 국가별 서류함 따로 만들기. 국가가 늘어날 때마다 테이블 생성 → 권한 부여 작업이 반복됨. 운영 최소화와 반대 방향.
• BS3 버킷을 AWS Lake Formation의 데이터 레이크 위치로 등록하고, Lake Formation의 행 수준 보안(Row-Level Security) 기능으로 접근 정책을 적용합니다.
  ✅ AWS Lake Formation — 데이터 레이크 중앙 거버넌스 서비스. 행 수준 보안(Row-Level Security, RLS) — 도서관 사서가 "이 직원은 한국 섹션만 열람 가능"이라고 출입증에 등록해두면 어느 책장을 열어도 자동 필터링되는 것. 데이터를 나누지 않고 정책 하나로 모든 접근을 제어. 국가 추가 시 조건값만 추가하면 끝.
• C고객 데이터를 해당 국가와 가장 가까운 AWS 리전으로 이동하고, 각 분석가에게 해당 리전 데이터에 대한 접근 권한을 부여합니다.
  ❌ 🌏 국가마다 창고 따로 짓기. 리전(Region) — AWS 물리 데이터센터 지역 단위. 리전별 데이터 이동 시 복제 비용 + 동기화 운영 발생. 접근 제어 문제를 인프라 분리로 해결하는 과도한 방법.
• D데이터를 Amazon Redshift로 이관하고, 국가별 뷰(View)를 생성한 뒤 국가마다 IAM 역할을 만들어 분석가에게 할당합니다.
  ❌ Amazon Redshift — 완전 관리형 클라우드 데이터 웨어하우스. 기술적으로 작동하지만 국가 추가 시마다 뷰 생성 → IAM(Identity and Access Management) 역할 생성 → 역할 매핑 3단계 반복. 운영 최소화 기준 미달.

🎯

정답

B — Lake Formation 행 수준 보안으로 정책 일괄 적용

🔑 핵심 개념 — 각 선택지 운영 부담 비교

방법	실생활 비유	국가 추가 시	운영 부담
A. 국가별 테이블 분리	🗂️ 국가별 서류함 따로	테이블 + 권한 매번 신규 생성	높음
B. Lake Formation RLS	🏢 출입증에 층별 권한 내장	정책 조건값만 추가	낮음 ✓
C. 리전별 데이터 이동	🌏 국가마다 창고 따로 짓기	리전 인프라 전체 복제	매우 높음
D. Redshift 뷰 + IAM 역할	📋 열람신청서 + 직원증 따로 발급	뷰 + IAM 역할 + 매핑 반복	중간~높음

💡 이것만 기억하자

"국가·부서별 행 단위 접근 제어 + 운영 최소화" → Lake Formation RLS

데이터를 쪼개지 말고, 정책으로 필터링하자.
테이블 / 리전 / IAM 역할을 국가별로 늘리면 = 운영 부담 증가 = 오답

---

Q3 Data Exchange · 데이터 수집 ⭐ 자주 출제

AWS Data Exchange는 타사(3rd-party) 데이터셋을 AWS 환경에 직접 구독·통합할 수 있는 데이터 마켓플레이스입니다. 별도 파이프라인 구축 없이 구독 즉시 S3로 전달되기 때문에 운영 오버헤드가 가장 낮으며, DEA-C01에서 "타사 데이터 + 운영 최소화" 조합으로 자주 출제됩니다.

📋 Question

한 스트리밍 플랫폼 회사가 콘텐츠 추천 엔진의 정확도를 높이기 위해 외부 데이터 제공업체의 사용자 행동 인사이트를 기존 분석 플랫폼에 추가로 통합하려 합니다. 통합에 필요한 엔지니어링 작업과 시간을 최소화할 수 있는 솔루션은 무엇일까요?

• AAWS Data Exchange를 통해 외부 데이터 제공업체의 데이터셋을 구독하고, API 호출로 분석 플랫폼에 통합합니다.
  ✅ AWS Data Exchange — 타사 데이터 마켓플레이스. 마트에서 완제품을 사는 것처럼, 수백 개 데이터 공급자의 데이터셋을 구독 즉시 S3로 자동 전달받는 서비스. 파이프라인 구축·계약 협상·전송 인프라 관리 불필요. 타사 데이터 통합에 특화된 유일한 AWS 서비스.
• BAWS DataSync를 사용하여 외부 제공업체 데이터를 API로 가져와 분석 플랫폼과 연동합니다.
  ❌ AWS DataSync — 온프레미스 ↔ AWS 스토리지 간 대용량 파일 자동 동기화 트럭. NAS·NFS·SMB 같은 내부 파일 시스템을 S3/EFS로 이전·동기화하는 서비스. 외부 타사 데이터 마켓플레이스 접근 기능 없음.
• CAmazon Kinesis Data Streams를 활용해 AWS CodeCommit 저장소에 있는 외부 데이터셋을 실시간으로 수집합니다.
  ❌ AWS CodeCommit — 소스 코드 저장소(Git 서버). Amazon Kinesis Data Streams — 실시간 스트리밍 데이터 컨베이어 벨트. 코드 저장소에 타사 데이터셋이 있을 이유가 없고, Kinesis는 실시간 이벤트 스트림 전용. 둘 다 이 시나리오와 무관.
• DAmazon Kinesis Data Streams와 Amazon ECR을 연동하여 외부 데이터를 수집하고 분석 플랫폼에 통합합니다.
  ❌ Amazon ECR(Elastic Container Registry) — 도커 컨테이너 이미지 창고. 컨테이너 이미지(앱 실행 패키지)를 저장하는 곳이지 데이터셋 저장소가 아님. 타사 데이터 통합과 전혀 관련 없음.

🎯

정답

A — AWS Data Exchange로 타사 데이터 구독·통합

🔑 핵심 개념 — 헷갈리는 데이터 이동 서비스 비교

서비스	실생활 비유	주 용도	타사 데이터?
AWS Data Exchange	🛒 외부 데이터 마트	타사 데이터셋 구독 → S3 자동 전달	✓ 전용
AWS DataSync	🚛 사내 창고 이사 트럭	온프레미스 파일시스템 → S3/EFS 동기화	✗ 무관
Amazon AppFlow	🤝 SaaS 앱 자동 동기화 파이프	Salesforce·Slack 등 SaaS ↔ S3 연동	✗ SaaS 전용
Kinesis Data Streams	🏭 실시간 컨베이어 벨트	클릭·로그·센서 실시간 스트림 수집	✗ 무관

💡 이것만 기억하자

"타사(3rd-party) 데이터셋 + 운영 최소화" → AWS Data Exchange

DataSync = 사내 파일 이사 트럭 (온프레미스 → AWS)
AppFlow = SaaS 앱 동기화 (Salesforce, Slack 등)
Kinesis = 실시간 이벤트 스트림 (클릭, 로그, 센서)

---

Q4 Data Mesh · Lake Formation · 거버넌스 ✌️ 복수 정답

데이터 메시(Data Mesh)는 도메인별로 데이터를 분산 소유하면서 중앙에서 거버넌스를 통제하는 아키텍처입니다. AWS에서 구현할 때는 S3 + Athena(분산 저장·쿼리)와 Lake Formation(중앙 거버넌스·접근 제어) 조합이 핵심입니다.

📋 Question — 두 가지를 선택하세요

한 금융 기관이 각 사업 부서가 자체 데이터를 독립적으로 소유하면서도 전사적으로 통합된 거버넌스와 접근 제어를 유지하는 분산 데이터 아키텍처를 도입하려 합니다. 데이터 카탈로그와 ETL 처리에는 AWS Glue를 이미 활용하기로 결정했습니다. 이 아키텍처를 완성하기 위해 함께 사용해야 할 두 가지 서비스는 무엇일까요?

• A데이터 저장에는 Amazon Aurora를, 분석에는 Amazon Redshift 프로비저닝 클러스터를 사용합니다.
  ❌ Amazon Aurora — 완전 관리형 관계형 DB(트랜잭션 처리용). Redshift 프로비저닝 클러스터 — 중앙 집중식 데이터 웨어하우스. 둘 다 중앙 집중식 구조라 데이터 메시의 "도메인별 분산 소유" 철학과 맞지 않음.
• B데이터 저장에는 Amazon S3를, 분석에는 Amazon Athena를 사용합니다.
  ✅ Amazon S3(Simple Storage Service) — 무한 확장 객체 저장소. 각 도메인팀이 자기 버킷을 독립 소유 가능. Amazon Athena — S3 위에서 SQL을 바로 실행하는 서버리스 쿼리 엔진. Glue Data Catalog와 네이티브 연동. 데이터를 옮기지 않고 제자리에서 분석 → 데이터 메시의 분산 소유 + 중앙 쿼리 구조에 최적.
• C중앙 집중식 데이터 관리와 접근 제어에 AWS Glue DataBrew를 활용합니다.
  ❌ AWS Glue DataBrew — 노코드(No-Code) 시각적 데이터 정제 도구. 요리사가 레시피 보며 재료 손질하는 것. 데이터 프로파일링·클렌징·변환을 GUI로 하는 도구이지, 거버넌스·접근 제어 서비스가 아님. 이름에 Glue가 들어가서 헷갈리기 쉬운 함정 보기.
• D데이터 저장에는 Amazon RDS를, 대규모 처리에는 Amazon EMR을 사용합니다.
  ❌ Amazon RDS(Relational Database Service) — 관계형 DB 관리 서비스. Amazon EMR(Elastic MapReduce) — EC2 기반 Spark/Hadoop 클러스터. RDS는 트랜잭션 DB라 데이터 메시 스토리지에 부적합. EMR은 클러스터 관리 부담이 크고 Glue Catalog와의 통합이 Athena보다 복잡.
• E중앙 집중식 데이터 거버넌스와 접근 제어에 AWS Lake Formation을 활용합니다.
  ✅ AWS Lake Formation — 데이터 레이크 중앙 거버넌스 서비스. 건물 전체 출입 관리 시스템. Glue Data Catalog 위에서 테이블·컬럼·행 단위 접근 제어를 한곳에서 관리. 각 도메인팀은 데이터를 분산 소유하면서 거버넌스는 Lake Formation이 중앙 통제 → 데이터 메시 핵심 요건 충족.

🎯

정답

B + E — S3/Athena(분산 저장·분석) + Lake Formation(중앙 거버넌스)

🔑 핵심 개념 — 데이터 메시 AWS 아키텍처

역할	서비스	비유	데이터 메시 적합?
분산 저장	Amazon S3	🗄️ 도메인별 독립 창고	✓ 최적
서버리스 분석	Amazon Athena	🔍 창고에서 직접 검색	✓ 최적
중앙 거버넌스	AWS Lake Formation	🏢 건물 출입 관리 시스템	✓ 최적
중앙 웨어하우스	Redshift	🏛️ 단일 대형 도서관	✗ 중앙집중식
데이터 정제 GUI	Glue DataBrew	🧑‍🍳 노코드 재료 손질 도구	✗ 거버넌스 아님

💡 이것만 기억하자

데이터 메시 = 분산 소유 + 중앙 거버넌스

저장·분석 → S3 + Athena (분산, 서버리스, Glue Catalog 연동)
거버넌스 → Lake Formation (중앙 접근 제어, 행·컬럼 단위 보안)

Glue DataBrew ≠ 거버넌스 (노코드 데이터 정제 도구일 뿐)

---

Q5 Lambda · 코드 관리 ⭐ 자주 출제

AWS Lambda 레이어(Layer)는 여러 Lambda 함수가 공유하는 코드·라이브러리를 한 곳에서 관리하는 기능입니다. 공통 스크립트를 레이어로 패키징하면 레이어 한 번 수정으로 연결된 모든 함수에 즉시 반영되어, DEA-C01에서 Lambda 코드 중복 제거 및 유지보수 효율화 문제로 자주 출제됩니다.

📋 Question

데이터 엔지니어링 팀은 데이터 포맷 변환 기능을 담당하는 Python 유틸리티 코드를 여러 AWS Lambda 함수에 각각 복사하여 사용하고 있습니다. 이 코드가 변경될 때마다 모든 Lambda 함수를 일일이 수정해야 하는 문제가 있습니다. 하나의 변경으로 모든 함수에 즉시 반영할 수 있는 가장 효율적인 방법은 무엇일까요?

• APython 스크립트의 S3 경로를 각 Lambda 함수의 실행 컨텍스트 객체에 포인터로 저장합니다.
  ❌ 실행 컨텍스트(Execution Context) — Lambda 함수가 실행될 때 생성되는 임시 런타임 환경. 호출 간 재사용될 수 있지만 영구 저장소가 아님. 함수마다 컨텍스트가 분리되어 공유가 안 됨.
• BPython 유틸리티 코드를 Lambda 레이어로 패키징하여 각 Lambda 함수에 연결합니다.
  ✅ Lambda 레이어(Lambda Layer) — 여러 Lambda 함수가 공유하는 공통 코드 패키지. 건물 공용 화장실처럼 한 번 설치하면 모든 층(함수)이 사용. Python 스크립트를 레이어로 올리고 각 함수에 연결하면 레이어만 새 버전으로 업데이트하면 끝. 함수 코드는 손댈 필요 없음.
• C공유 S3 버킷에 저장된 Python 스크립트 경로를 각 Lambda 함수의 환경 변수로 설정합니다.
  ❌ 환경 변수(Environment Variable) — Lambda 함수 설정에 key-value로 저장하는 구성값. 환경 변수는 각 Lambda 함수에 개별 설정되는 값. 스크립트 경로를 변수로 저장해도 함수마다 일일이 수정해야 해서 문제가 그대로.
• D모든 Lambda 함수에 동일한 별칭(Alias)을 부여하고, 별칭을 통해 함수를 호출합니다.
  ❌ Lambda 별칭(Alias) — 특정 함수 버전을 가리키는 포인터 이름표. "prod", "dev" 같은 별칭으로 버전 전환에 사용. 배포 버전 관리·트래픽 분산용 기능이지, 공통 코드를 여러 함수에 공유하는 기능이 아님.

🎯

정답

B — Python 스크립트를 Lambda 레이어로 패키징

🔑 핵심 개념 — Lambda 관련 기능 비교

기능	실생활 비유	주 용도	코드 공유?
Lambda Layer	🏢 건물 공용 시설	공통 코드·라이브러리 여러 함수에 공유	✓ 전용
Lambda Alias	🏷️ 버전 이름표	prod/dev 버전 전환, 트래픽 분산	✗ 무관
환경 변수	📝 함수별 메모장	함수별 설정값(API 키, 경로 등) 저장	✗ 함수별 개별
실행 컨텍스트	⚡ 임시 작업 공간	호출 간 DB 연결 등 재사용 최적화	✗ 임시·함수별

💡 이것만 기억하자

"여러 Lambda 함수에서 공통 코드 공유" → Lambda Layer

Layer = 건물 공용 시설 (한 번 설치, 모든 함수 사용)
Alias = 버전 이름표 (prod ↔ dev 전환용)
환경변수 = 함수별 메모장 (공유 안 됨, 각자 설정)

레이어 업데이트 → 연결된 함수 전체에 즉시 반영!

AWS DEA-C01 VPC Gateway Endpoint Lake Formation AWS Data Exchange Data Mesh Lambda Layer 데이터 엔지니어 자격증 AWS 자격증