어제는 데이터가 흐르는 파이프라인을 복습했다. 오늘은 그 파이프라인을 안정적으로 운영 하고 안전하게 보호 하는 영역을 묶어 본다. 두 도메인은 한 파이프라인 위에서 이렇게 이어진다.
운영 : MWAA/Step Functions가 파이프라인 조율 → CloudWatch로 지표·로그 감시 → 실패 시 알람·재시도품질 : Glue Data Quality 규칙으로 적재 전 검증, 위반 데이터 격리보안 : IAM 역할 최소 권한 → KMS로 저장 데이터 암호화, TLS 로 전송 구간 암호화거버넌스 : Macie로 민감정보 탐지 → Lake Formation으로 세분화 접근 → CloudTrail로 감사
시험 가이드의 태스크로 펼치면 아래와 같다.
시험 가이드 태스크 묻는 것 되돌아갈 곳 3.1 처리 자동화 MWAA·Step Functions 오케스트레이션, 워크플로 장애 진단, Lambda·EventBridge 자동화, Athena 쿼리 Week 5 Day 3, Week 7 Day 2 3.2 데이터 분석 QuickSight 시각화, Redshift·Athena SQL 과 뷰, 프로비저닝 대 서버리스의 트레이드오프 Week 7 3.3 유지·모니터링 감사용 로그 추출, 알림, 성능 진단, CloudTrail, CloudWatch Logs, 로그 분석 Week 8 Day 1·3 3.4 데이터 품질 처리 중 품질 검사, 규칙 정의, 일관성 조사, 샘플링, 데이터 스큐 Week 4 Day 4, Week 8 Day 2 4.1 인증 보안 그룹, IAM 역할, Secrets Manager 자격 증명 교체, PrivateLink Week 9 Day 1 4.2 인가 사용자 지정 IAM 정책, 자격 증명 저장, Redshift 권한, Lake Formation Week 6 Day 2, Week 9 Day 1 4.3 암호화·마스킹 KMS, 계정 간 암호화, 전송 구간 암호화, 마스킹·익명화 Week 9 Day 2·3 4.4 감사 로그 CloudTrail, CloudTrail Lake, CloudWatch Logs, 로그 분석 Week 8 Day 3, Week 9 Day 4 4.5 프라이버시·거버넌스 Redshift 데이터 공유, PII 식별, 허용되지 않은 리전으로의 복제 차단, AWS Config Week 9 Day 3·4
여러 작업을 순서·의존성에 맞게 묶는 것이 오케스트레이션이다.
요구사항 서비스 특징 데이터 워크플로 스케줄·의존성(Airflow) Amazon MWAA 관리형 Apache Airflow, DAG 기반 서버리스 상태 기계, 시각적 분기·재시도 AWS Step Functions Lambda/Glue/EMR 등 단계 조율 Glue 잡·크롤러 전용 흐름 Glue Workflows Glue 내장 트리거·워크플로 단순 cron 스케줄 트리거 EventBridge Scheduler 시간 기반 이벤트
💡 관련 이론 : "기존 Airflow DAG을 그대로 쓰고 싶다"면 MWAA, "이기종 AWS 서비스(Lambda·ECS·Glue)를 분기·재시도·병렬로 조율"하려면 Step Functions가 정답이다. Glue 잡만 엮는다면 Glue Workflows로 충분하다.
운영 관점에서 한 번 더 갈리는 지점(Week 5 Day 5)이다.
유휴 비용 : MWAA 는 환경이 떠 있는 동안 과금된다. Step Functions Standard 는 상태 전이 수로, Express 는 실행 수·시간·메모리로 과금된다. "하루 한 번 도는 짧은 흐름, 유휴 비용 없음"이면 Step Functions 다.완료 대기 : Glue 잡이나 EMR 스텝이 끝날 때까지 기다리는 통합 패턴(.sync)은 Standard 에서만 된다. Express 는 최대 5분이라 ETL 오케스트레이션의 기본값이 아니다.재시도의 위치 : Step Functions 의 Retry와 Glue 잡 자체 재시도를 겹쳐 두면 곱해진다. 재시도는 한 계층에만 두고 Catch로 알림(SNS)이나 보상 처리로 분기한다.MWAA 장애 진단 : DAG 가 목록에 보이지 않거나 태스크가 시작되지 않으면 S3 의 DAG 경로, 환경 실행 역할의 권한, 요구 패키지 설치 오류를 CloudWatch Logs 에서 확인한다.
CloudWatch Metrics/Alarms : 잡 실패율, 지연, 리소스 사용량 임계치 알람.CloudWatch Logs : Glue·Lambda·EMR 실행 로그 집계와 Logs Insights 쿼리.CloudTrail : API 호출 감사 로그(누가 무엇을 언제). 보안·거버넌스와도 연결.EventBridge : 잡 상태 변화 이벤트로 알림·후속 트리거.
파이프라인 관측 3종: - 지표(Metric) → CloudWatch Alarm으로 "임계치 초과 시 알림" - 로그(Log) → CloudWatch Logs Insights로 "원인 추적" - 감사(Audit) → CloudTrail로 "누가 이 작업을 했는가"
💡 관련 이론 : "왜 실패했는지 원인 추적"은 CloudWatch Logs, "임계치 기반 알림"은 CloudWatch Alarm, "누가 이 API를 호출했는지 추적"은 CloudTrail로 구분한다. 이 셋을 헷갈리지 않는 것이 도메인 3 득점 포인트다.
"기록을 남긴다"는 말은 같아도 도구마다 남기는 것이 다르다.
도구 남기는 것 기본 동작과 한계 CloudWatch Logs 애플리케이션이 찍은 로그(Glue·Lambda·EMR 실행 로그) 지표 필터로 로그 패턴을 지표로 바꿔 알람을 걸 수 있다 CloudWatch Logs Insights 로그 그룹에 대한 대화형 쿼리 저장 도구가 아니라 조회 도구다 CloudTrail 이벤트 기록 최근 90일의 관리 이벤트 별도 설정 없이 콘솔에서 본다. 데이터 이벤트는 없다 CloudTrail 트레일 이벤트를 S3(필요하면 CloudWatch Logs)로 계속 전달 기본은 관리 이벤트만 기록한다. S3 객체 수준 작업 같은 데이터 이벤트는 직접 켜야 한다 CloudTrail Lake 이벤트를 이벤트 데이터 스토어에 모아 SQL 로 조회 트레일 없이도 쓸 수 있고 여러 계정·리전의 이벤트를 수년 단위로 보관한다 AWS Config 리소스 구성이 언제 어떻게 바뀌었는지 의 이력 누가 호출했는지가 아니라 무엇이 어떤 상태였는지를 본다
"누가 S3 객체를 읽었는가"는 관리 이벤트가 아니라 데이터 이벤트 다. 트레일에서 해당 버킷의 데이터 이벤트를 켜 두지 않았다면 기록이 없다. 양이 많아 비용이 붙으므로 기본으로 꺼져 있다.
90일보다 오래된 감사 기록이 필요하면 트레일(S3 보관 후 Athena 로 분석)이나 CloudTrail Lake 다. "중앙에서 SQL 로 감사 로그를 조회"가 단서면 CloudTrail Lake 다.
로그 양이 매우 크면 분석 도구가 달라진다. 수시 탐색은 Logs Insights, S3 에 쌓인 대량 로그는 Athena, 검색·대시보드는 OpenSearch Service, 초대형 로그의 변환·집계는 EMR 이다.
Glue Data Quality : 데이터셋에 규칙(DQDL)을 정의해 완전성·유효성·중복을 검증. 규칙 위반 시 잡 중단 또는 격리.DataBrew : 프로파일링으로 결측·이상치·분포를 시각적으로 파악.멱등성·재시도 : 실패 시 안전한 재처리를 위해 잡을 멱등(idempotent)하게 설계.
# Glue Data Quality 규칙(DQDL) 예시 ruleset = """ Rules = [ IsComplete "order_id", ColumnValues "amount" >= 0, Uniqueness "order_id" > 0.99 ] """ # 규칙 통과 시 적재, 실패 시 격리 버킷으로 라우팅 품질 태스크에는 규칙 정의 말고도 두 가지 개념이 들어 있다.
개념 내용 시험에서의 쓰임 샘플링 전체 대신 일부만 뽑아 검사한다. 무작위 추출, 그룹 비율을 유지하는 층화 추출, 일정 간격으로 뽑는 계통 추출이 있다 대용량 프로파일링의 비용을 줄이는 근거. DataBrew 는 샘플로 Recipe 를 만들고 Job 으로 전체에 적용한다 데이터 스큐 특정 키에 행이 몰려 일부 파티션·태스크만 오래 걸리거나 메모리가 부족해지는 현상 키에 임의 접미사를 붙여 흩는 솔팅, 재파티셔닝, 쏠린 키만 따로 처리하는 방식으로 완화한다 두 진입점 Data Catalog 테이블 대상 평가(저장된 데이터 점검)와 ETL 잡 안의 평가(적재 전 차단) "적재 전에 막는다"면 잡 안의 평가다
스키마가 맞는지(형태)와 값이 맞는지(내용)는 다른 문제다. 음수 금액·중복 키·NULL 은 Schema Registry 가 아니라 Data Quality 가 잡는다(Week 4 Day 4).
분석 태스크는 서비스 이름보다 "언제 상시 용량을 두고 언제 쓴 만큼 내는가"를 묻는다.
축 프로비저닝(Redshift 프로비저닝 클러스터, EMR on EC2, MWAA) 서버리스(Athena, Glue, Redshift Serverless, EMR Serverless) 과금 띄워 둔 시간 쓴 만큼(스캔량, DPU·RPU 시간 등) 유리한 워크로드 종일 일정하게 쓰는 부하, 예측 가능한 성능 간헐적·예측 불가한 부하 조절 손잡이 노드 타입·수, 스팟, 세부 설정 거의 없다. 데이터 쪽(포맷·파티션)을 고친다 운영 부담 사이징·패치·스케일링 낮다
Athena 의 비용 통제는 워크그룹 에서 한다. 쿼리당 스캔 한도를 넘는 쿼리는 취소된다. 워크그룹 전체 사용량 한도는 임계치를 넘으면 SNS 로 알릴 뿐 실행 중인 쿼리를 자동으로 취소하지는 않는다.
시각화는 QuickSight 다. 대시보드가 원본을 매번 조회해 느리거나 비싸다면 인메모리 엔진(SPICE)으로 가져와 두는 방식이 답이 된다.
IAM 역할(Role) : 서비스(Glue/EMR/Lambda)에 최소 권한을 부여. 사람 자격증명을 코드에 두지 않음.최소 권한 원칙 : 필요한 액션·리소스만 허용. * 남발 금지.리소스 기반 정책 : S3 버킷 정책, KMS 키 정책 등 리소스 쪽에서 접근 허용.Lake Formation 권한 과 IAM의 관계: 데이터 레이크 데이터 접근은 LF가, 서비스 운영 권한은 IAM이 담당.
"Glue 잡이 S3와 KMS에 접근해야 한다"면 잡 실행 역할(IAM Role)에 해당 권한을 부여한다. 액세스 키를 잡 스크립트에 하드코딩하는 보기는 오답이다.
정책 평가에서 명시적 거부는 어떤 허용보다 우선 한다. 계정이 다른 주체가 접근하려면 양쪽(요청자의 IAM 정책과 리소스 쪽 정책)이 모두 허용해야 한다.
데이터베이스 암호 같은 자격 증명은 코드가 아니라 저장소에 둔다.
구분 AWS Secrets Manager Systems Manager Parameter Store 주 용도 DB 자격 증명·API 키 등 비밀 설정값과 비밀(SecureString) 자동 교체 지원(교체 일정 설정) 내장 기능 없음 단서 "자격 증명을 주기적으로 교체" "설정값을 계층 구조로 보관", 비용 최소
Redshift 안의 권한은 IAM 이 아니라 데이터베이스의 사용자·그룹·역할에 GRANT로 준다. 계정·클러스터 사이에 복사 없이 데이터를 읽게 하려면 Redshift 데이터 공유 다.
네트워크 층도 인증의 일부다. 데이터 원천에 붙지 못하면 보안 그룹의 인바운드 규칙을, 인터넷을 거치지 않고 AWS 서비스에 붙어야 하면 VPC 엔드포인트(PrivateLink)를 본다.
저장 시 암호화(at rest) : S3(SSE-S3/SSE-KMS), Redshift, RDS, EBS, Kinesis 모두 서버 측 암호화를 지원하고, 키 통제가 필요하면 KMS 키를 지정한다.전송 중 암호화(in transit) : TLS/HTTPS.SSE-KMS vs SSE-S3 : 키를 직접 관리·감사·회전하고 키별 접근 통제가 필요하면 SSE-KMS, 단순 관리형이면 SSE-S3.고객 관리 키(CMK) : 키 정책으로 누가 암복호화할 수 있는지 세밀 제어, CloudTrail로 키 사용 감사.
키워드 정답 키 회전·키별 접근 통제·감사 필요 SSE-KMS (고객 관리 키) 가장 단순한 관리형 암호화 SSE-S3 클라이언트가 직접 암호화 후 업로드 클라이언트 측 암호화
KMS 키는 누가 관리하느냐에 따라 할 수 있는 일이 다르다.
키 종류 키 정책 수정 자동 교체 계정 간 사용 AWS 소유 키 불가(보이지 않는다) 서비스가 정한다 해당 없음 AWS 관리형 키(aws/s3 등) 불가 매년 자동. 끄거나 주기를 바꿀 수 없다 불가 고객 관리 키 가능 선택 사항. 켜면 기본 365일 주기이고 주기를 직접 지정할 수 있다 키 정책에 상대 계정을 허용하면 가능
AWS 관리형 키의 교체 주기는 2022년 5월에 3년에서 1년으로 바뀌었다. 시험 자료에는 3년으로 나올 수 있다.
키를 교체해도 키 ID 와 ARN 은 그대로 다. 예전 키 재료는 보관되어 과거 암호문을 그대로 복호화하고, 기존 데이터를 다시 암호화하지 않는다. 애플리케이션 코드를 바꿀 필요가 없다.
자동 교체는 KMS 가 만든 키 재료를 쓰는 대칭 암호화 키에서만 된다. 비대칭 키·HMAC 키·사용자 지정 키 스토어의 키는 새 키를 만들고 별칭을 옮기는 수동 교체를 한다.
S3 는 2023년 1월 5일부터 새 객체를 모두 SSE-S3 로 기본 암호화한다. "암호화되지 않은 버킷"을 고치는 문제가 아니라 "키를 누가 통제하는가"를 묻는 문제로 읽는다.
SSE-KMS 로 객체를 대량으로 읽고 쓰면 KMS 요청 비용과 초당 요청 한도가 문제가 된다. S3 버킷 키 를 켜면 버킷 수준 키로 데이터 키를 만들어 KMS 요청을 크게 줄인다(DSSE-KMS 에서는 쓸 수 없다).
계정 간 공유의 함정: 버킷 정책을 열어 줘도 객체가 AWS 관리형 키(aws/s3)로 암호화돼 있으면 상대 계정은 복호화하지 못한다. 고객 관리 키로 암호화하고 키 정책에 상대 계정을 넣어야 한다.
전송 구간은 설정으로 강제한다. S3 는 버킷 정책에서 aws:SecureTransport가 거짓인 요청을 거부하고, Redshift 는 파라미터 그룹의 require_ssl로 TLS 연결만 받는다.
Amazon Macie : 머신러닝과 패턴 매칭으로 S3 내 PII(개인식별정보) ·신용카드 번호 등 민감 데이터를 자동 발견·분류. "어디에 민감정보가 있는지 모름"을 해결.마스킹/토큰화 : Glue·Athena·Redshift Dynamic Data Masking으로 출력 시 민감 컬럼을 가림.데이터 분류 : 발견(Macie) → 분류 → 권한(Lake Formation) → 암호화(KMS)로 이어지는 보호 사슬.
"S3 버킷 곳곳에 민감정보(PII)가 흩어져 있는데 위치를 자동으로 찾아 분류하고 싶다"는 시나리오의 정답은 Amazon Macie다. Macie는 "탐지/분류"이고, 접근 통제는 Lake Formation/IAM, 보호는 KMS·마스킹이 담당하는 역할 분담이다.
"민감정보를 다룬다"는 보기가 여럿 나올 때는 어디에서, 언제 작용하는지로 가른다.
도구 작용 위치 하는 일 원본 데이터 Amazon Macie S3 버킷 객체를 분석해 민감 데이터 위치를 결과(finding)로 보고. 버킷의 공개·공유 상태도 평가한다 바꾸지 않는다 Glue 의 민감 데이터 탐지 변환 ETL 잡 실행 중 PII 를 찾아 가리거나(전체·부분) 해시로 바꾼 결과를 쓴다 가공된 사본이 생긴다 Lake Formation 데이터 필터 쿼리 시점(Athena·Redshift Spectrum·EMR 등) 주체별로 컬럼·행·셀을 보여 주지 않는다 바꾸지 않는다 Redshift 동적 데이터 마스킹 Redshift 쿼리 시점 마스킹 정책을 사용자·역할에 붙여 같은 컬럼을 사람마다 다르게 보여 준다 바꾸지 않는다
Macie 의 탐지는 두 방식이다. 자동 민감 데이터 탐지 는 버킷에서 대표 객체를 표본으로 뽑아 넓게 훑고, 탐지 작업(job) 은 지정한 버킷을 깊게 분석한다. 기본 제공 식별자(관리형)로 잡히지 않는 사내 형식은 정규식 기반 사용자 지정 식별자로 잡는다.
Macie 는 결과를 EventBridge 로 내보낸다. "PII 가 발견되면 자동으로 격리·알림"은 Macie → EventBridge → Lambda/SNS 조합이다.
데이터 주권 요구("허용되지 않은 리전으로 백업·복제되면 안 된다")는 탐지가 아니라 차단 의 문제다. 리전 조건(aws:RequestedRegion)으로 해당 리전의 작업을 거부하는 정책을 건다.
보안 문제에서 헷갈리기 쉬운 유형은 "권한을 줬는데도 AccessDenied가 난다"다. Athena 로 Lake Formation 관리 테이블을 읽는 한 번의 쿼리는 세 층을 차례로 통과한다.
① IAM 쿼리 실행·카탈로그 조회 권한 + lakeformation:GetDataAccess ↓ ② Lake Formation 그 주체에게 테이블·컬럼·행에 대한 SELECT 가 부여됐는가 ↓ (통과하면 등록된 S3 위치에 대한 임시 자격 증명을 내준다) ③ KMS 객체가 SSE-KMS 라면 그 키로 복호화할 수 있는가(키 정책)
Lake Formation 에 등록된 위치의 데이터는 사용자 역할에 S3 읽기 권한을 직접 주지 않는다. 그 대신 lakeformation:GetDataAccess가 IAM 에 있어야 한다. 쿼리 결과를 쓰는 버킷은 별개라서 그쪽 S3 권한은 여전히 필요하다.
등록되지 않은 위치는 예전 방식 그대로 IAM 과 버킷 정책만으로 통제된다. 하이브리드 액세스 모드 는 같은 테이블에 대해 옵트인한 주체에게만 Lake Formation 권한을 강제하고 나머지는 IAM 권한으로 계속 접근하게 해, 기존 워크로드를 깨지 않고 점진적으로 옮기게 해 준다.
어느 관문에서 막혔는지는 CloudTrail 의 거부 이벤트(오류 코드와 호출 API)로 가린다.
증상 원인 조치 Glue 잡이 S3 를 읽다 AccessDenied 버킷 권한은 있는데 KMS 키 사용 권한이 없다 잡 실행 역할에 kms:Decrypt(쓰기는 kms:GenerateDataKey)를, 키 정책에 그 역할을 허용 Athena 에서 "Lake Formation 권한 부족" IAM 은 충분하지만 LF 에서 SELECT 를 부여하지 않았다 LF 에서 테이블·컬럼 권한 부여 다른 계정이 공유 버킷의 객체를 열지 못한다 객체가 AWS 관리형 키로 암호화됐다 고객 관리 키로 암호화하고 키 정책에 상대 계정 허용 S3 객체를 누가 지웠는지 CloudTrail 에 없다 데이터 이벤트를 켜지 않았다 트레일에서 해당 버킷의 데이터 이벤트 기록 넉 달 전의 API 호출 기록을 찾을 수 없다 이벤트 기록은 90일만 본다 트레일로 S3 에 보관하거나 CloudTrail Lake 사용 잡은 성공인데 대시보드 숫자가 틀리다 값의 유효성을 검사하지 않았다 적재 전 Glue Data Quality 게이트 알람이 울리지 않고 장애를 사후에 알았다 실패가 지표가 아니라 로그에만 남았다 지표 필터로 로그 패턴을 지표화하거나 잡 상태 변화 이벤트를 EventBridge → SNS 로 Spark 태스크 몇 개만 끝나지 않는다 데이터 스큐 솔팅·재파티셔닝 SSE-KMS 버킷에서 KMS 스로틀과 요청 비용이 크다 객체마다 KMS 를 호출한다 S3 버킷 키 활성화 민감 컬럼이 분석가 전원에게 보인다 버킷 단위 권한만 있다 LF 컬럼 권한·데이터 필터, Redshift 는 동적 데이터 마스킹
시나리오 결정적 단서 정답 지난달 특정 역할이 호출한 Glue API 목록을 뽑는다 누가·언제·어떤 API CloudTrail 여러 계정의 감사 이벤트를 한곳에 모아 SQL 로 조회한다 중앙 집중, SQL CloudTrail Lake 보안 그룹 규칙이 언제 어떻게 바뀌었는지 본다 구성 변경 이력 AWS Config 실패한 Glue 잡의 스택 트레이스를 찾는다 실행 로그, 원인 CloudWatch Logs(Logs Insights) 잡이 실패하면 담당자에게 즉시 알린다 상태 변화, 알림 EventBridge 규칙 → SNS DB 암호를 30일마다 자동으로 바꾼다 자격 증명 교체 Secrets Manager 팀마다 볼 수 있는 행이 다르다(지역별) 행 수준 Lake Formation 데이터 필터 수백 개 테이블의 권한을 분류 기준으로 한꺼번에 준다 태그 기반, 확장성 LF-Tag 기반 접근 제어 콜센터 직원에게는 카드번호 끝 네 자리만 보인다(Redshift) 조회 시 역할별 가리기 동적 데이터 마스킹 레이크에 적재하기 전에 이메일 컬럼을 해시로 바꾼다 ETL 중 가공 Glue 민감 데이터 탐지 변환 키 사용 내역을 감사하고 특정 역할만 복호화하게 한다 키 정책, 감사 SSE-KMS 고객 관리 키 운영 클러스터의 데이터를 다른 계정이 복사 없이 조회한다(Redshift) 실시간 공유, 복사 없음 Redshift 데이터 공유
내일은 네 도메인을 섞은 종합 시나리오로 실제 시험 페이스를 맞춰 본다.
관리 이벤트 / 데이터 이벤트 : 리소스를 만들고 바꾸는 호출과, 리소스 안의 데이터를 읽고 쓰는 호출. CloudTrail 은 기본으로 앞의 것만 기록한다.지표 필터 : 로그에서 특정 패턴이 나온 횟수를 CloudWatch 지표로 바꿔 주는 설정. 로그에 알람을 거는 통로다.데이터 스큐 : 특정 키에 데이터가 몰려 일부 태스크만 느려지거나 실패하는 현상.솔팅(salting) : 쏠린 키에 임의 값을 덧붙여 여러 파티션으로 흩는 기법.키 정책 : KMS 키에 붙는 리소스 기반 정책. 누가 그 키로 암복호화할 수 있는지를 정한다.봉투 암호화 : 데이터는 데이터 키로, 데이터 키는 KMS 키로 암호화하는 방식. SSE-KMS 가 이렇게 동작한다.S3 버킷 키 : SSE-KMS 에서 객체마다 KMS 를 부르지 않도록 버킷 수준에서 잠시 쓰는 키. KMS 요청 비용을 줄인다.데이터 필터 : Lake Formation 에서 주체에게 보여 줄 행과 컬럼을 정의한 것. 행·컬럼·셀 수준 보안의 단위다.동적 데이터 마스킹 : 저장된 값은 그대로 두고 조회하는 사람에 따라 결과를 가려서 보여 주는 방식.하이브리드 액세스 모드 : 같은 카탈로그 리소스에 Lake Formation 권한과 IAM 권한 경로를 함께 두는 Lake Formation 설정. 📝 연습 문제 선택지를 클릭하면 정답·해설이 펼쳐집니다.
한 팀이 기존에 사용하던 Apache Airflow DAG을 거의 수정 없이 AWS에서 관리형으로 운영하고자 한다. 가장 적합한 서비스는?
A AWS Step Functions B Amazon EventBridge Scheduler C AWS Batch D Amazon MWAA 보안 감사 결과 "특정 IAM 사용자가 언제 어떤 Glue API를 호출했는지" 추적할 수 있어야 한다는 요구가 나왔다. 가장 적합한 서비스는?
A Amazon CloudWatch Alarm B AWS CloudTrail C AWS X-Ray D Amazon Macie S3에 저장하는 데이터를 암호화하되 키 회전, 키별 접근 통제, 키 사용 내역 감사가 모두 필요하다. 가장 적합한 방식은?
A 암호화하지 않고 버킷을 프라이빗으로만 둔다 B SSE-S3(S3 관리형 키) C SSE-KMS(고객 관리 KMS 키) D 클라이언트가 평문으로 업로드 후 IAM으로만 보호 여러 S3 버킷에 고객 PII가 어디에 얼마나 있는지 파악되지 않아 컴플라이언스 위험이 있다. 민감 데이터를 자동으로 발견·분류하려 한다. 가장 적합한 서비스는?
A Amazon Macie B AWS Config C Amazon GuardDuty D AWS Trusted Advisor Glue ETL 잡이 적재 전에 "order_id가 비어 있지 않고 amount가 0 이상이며 order_id가 거의 고유한지"를 자동 검증하고, 규칙 위반 데이터는 격리하려 한다. 가장 적합한 기능은?
A CloudWatch Logs Insights B S3 수명주기 정책 C Redshift VACUUM D Glue Data Quality 규칙(DQDL)