정답 · 해설

해설

【핵심 용어】 ▸ Microsoft Defender for Cloud Apps — CASB 솔루션, SaaS 앱 보안 태세 관리(SSPM) 제공 ▸ SSPM (SaaS Security Posture Management) — SaaS 앱 구성/보안 태세 점검 ▸ CSPM/CWPP — Defender for Cloud의 클라우드 인프라 보안 기능(별도 제품) 【정답 포인트】 ▸ "Defender for Cloud Apps의 기능" → SaaS 앱 보안 태세 관리(SSPM) ▸ C: Cloud Apps(CASB)는 SaaS 앱 대상 SSPM 기능 제공 【오답 체크】 (A) CWPP는 Defender for Cloud(워크로드 보호)의 기능. (B) AIR(자동 조사·대응)는 Defender for Endpoint/XDR 계열 기능. (D) CSPM은 Defender for Cloud의 클라우드 인프라 태세 관리 기능. 【시험 포인트】 Defender for Cloud Apps(CASB) = SaaS 앱 보안 태세 관리(SSPM).

해설

【핵심 용어】 ▸ SageMaker Clarify — 편향 탐지·설명가능성, 인구통계 등 민감 속성 기준 편향 리포트 생성 ▸ Bias Report — 학습 전/후 편향 지표를 문서화하여 감사·설명에 활용 【정답 포인트】 ▸ "모델 편향을 감사인에게 설명" + "고객 인구통계 데이터 초점" → SageMaker Clarify의 편향 리포트 ▸ A: Clarify가 인구통계 기준 편향 지표를 리포트로 산출, 감사 제출에 적합 【오답 체크】 (B) Glue DataBrew의 데이터 품질/드리프트 탐지는 편향 설명 도구가 아님. (C) QuickSight(Quick Suite)는 시각화 도구로 편향 리포트 생성 전문이 아님. (D) CloudWatch 지표 대시보드는 운영 모니터링용, 편향 설명에 부적합. 【시험 포인트】 모델 편향 탐지·설명 리포트 → SageMaker Clarify.

해설

【핵심 용어】 ▸ Amazon Rekognition — 이미지/비디오 콘텐츠 모더레이션(부적절 콘텐츠 탐지) 관리형 서비스 ▸ AWS Lambda — 서버리스 이벤트 처리, 프레임 추출·호출 오케스트레이션 ▸ 실시간 콘텐츠 모더레이션 — Rekognition의 콘텐츠 모더레이션 API로 최소 운영 부담 【정답 포인트】 ▸ "실시간 영상 콘텐츠 모더레이션" + "최소 운영 오버헤드" → Rekognition(관리형 모더레이션) + Lambda(서버리스 처리) ▸ A: 프레임을 Rekognition으로 분석하는 관리형 조합이 운영 부담 최소 【오답 체크】 (B) LLM(Bedrock) 추가는 불필요한 복잡도·비용, 모더레이션에 과함. (C) SageMaker 자체 모델 구축은 학습/운영 부담이 큼. (D) Transcribe/Comprehend는 음성·텍스트 분석용으로 영상 콘텐츠 모더레이션에 부적합. 【시험 포인트】 이미지/영상 콘텐츠 모더레이션 관리형 → Rekognition(+Lambda 서버리스).

해설

【핵심 용어】 ▸ AWS Glue DataBrew — 코드 없이 데이터 정제·변환, impute missing values(결측치 대치) 변환 내장 ▸ Impute Missing Values — 평균/중앙값 등으로 결측값 자동 대체 ▸ 자동 파이프라인 — DataBrew 레시피/작업으로 반복 실행 가능 【정답 포인트】 ▸ "결측값을 평균으로 대체" + "자동 데이터 준비 파이프라인" → DataBrew의 impute missing values 변환 ▸ B: DataBrew 결측치 대치 변환으로 평균 대체를 파이프라인화 【오답 체크】 (A) Athena UPDATE는 S3 데이터에 대한 표준 지원이 제한적이고 파이프라인화 번거로움. (C) QuickSight Calculated Field는 시각화용 계산 필드로 원본 데이터 정제가 아님. (D) Glue DropColumns는 컬럼 삭제 변환으로 결측값 대체와 무관. 【시험 포인트】 노코드 결측치 평균/중앙값 대치 → Glue DataBrew impute 변환.

해설

【핵심 용어】 ▸ AWS KMS — 고객 관리형 키(CMK)로 암호화 제어권 보유, SageMaker 데이터 암호화에 사용 ▸ IAM Roles/Policies — 리소스·데이터 접근 권한 제어(인가된 직원만 접근) ▸ PrivateLink — 프라이빗 네트워크 연결(접근 경로), 암호화 제어 수단은 아님 【정답 포인트】 ▸ "암호화 + 회사가 암호화 제어" → KMS(키 관리 제어) ▸ "인가된 직원만 데이터 접근" → IAM 역할/정책으로 접근 제어 ▸ A: IAM으로 접근 통제 + KMS로 암호화·키 제어 【오답 체크】 (B) PrivateLink는 네트워크 접근 경로일 뿐 세밀한 접근 제어의 핵심이 아님. (C) 'VPC only mode'는 암호화 방식이 아님(네트워크 격리). (D) CloudTrail은 API 감사 로깅 도구이지 암호화 수단이 아님. 【시험 포인트】 암호화 제어 = KMS, 데이터 접근 제어 = IAM 역할/정책.

해설

【핵심 용어】 ▸ SageMaker Real-time Inference Endpoint — 관리형 저지연 실시간 추론, 인프라 관리 최소·자동 확장 ▸ 저지연 + 최소 운영 + 비용 절감 — 관리형 엔드포인트가 인프라 부담을 대신 관리 【정답 포인트】 ▸ "저지연" + "인프라 관리 역량 부족" + "비용 최소화" → SageMaker 실시간 추론 엔드포인트(관리형) ▸ B: 관리형 엔드포인트로 저지연 추론을 인프라 부담 없이 제공 【오답 체크】 (A) EC2 + ALB 직접 구성은 인프라 관리 부담이 큼. (C) ECS on Fargate도 컨테이너/스케일링 구성 관리가 필요, 상대적으로 부담. (D) EKS(Kubernetes)는 운영 복잡도가 가장 높음. 【시험 포인트】 저지연 실시간 추론 + 최소 운영 → SageMaker 실시간 추론 엔드포인트.

해설

【핵심 용어】 ▸ SageMaker 엔드포인트 CloudWatch 지표 — Invocations(호출량), ModelLatency, HTTP 4xx/5xx 등 시스템 지표 기본 발행 ▸ CloudWatch — 지표/대시보드 기본 제공, 추가 구성 최소 【정답 포인트】 ▸ "지연/호출량/HTTP 상태 코드 모니터링" + "최소 운영 오버헤드" → SageMaker가 기본 발행하는 CloudWatch 지표로 대시보드 구성 ▸ B: CloudWatch 대시보드로 엔드포인트 시스템 지표를 최소 구성으로 시각화 【오답 체크】 (A) X-Ray는 분산 트레이싱용으로 시스템 지표 모니터링에 과함/부적합. (C) IAM Access Analyzer는 권한 분석 도구로 지표와 무관. (D) Trusted Advisor는 모범 사례 점검 도구로 엔드포인트 지표 수집이 아님. 【시험 포인트】 SageMaker 엔드포인트 시스템 지표(지연·호출·상태코드) → CloudWatch 기본 지표/대시보드.

해설

【핵심 용어】 ▸ Class Imbalance(사기 탐지) — 사기 거래가 극소수라 소수 클래스 성능 저하 ▸ SMOTE (Synthetic Minority Oversampling Technique) — 소수 클래스의 합성 샘플을 생성, 단순 복제보다 일반화 우수 ▸ SageMaker Data Wrangler — SMOTE·오버/언더샘플링 균형 조정 지원 【정답 포인트】 ▸ "사기 거래 극소수" + "성능 저하" → 소수 클래스 합성 생성(SMOTE)으로 균형 확보 ▸ C: SMOTE로 합성 소수 샘플을 만들어 재학습, 단순 복제보다 과적합 위험 낮음 【오답 체크】 (A) 알고리즘 교체는 불균형이라는 근본 원인을 해결하지 못함. (B) 다수 클래스 언더샘플링은 데이터 손실 크고 성능 개선 제한적. (D) random oversampling(단순 복제)은 가능하나 SMOTE 대비 과적합 위험이 커 열위. 【시험 포인트】 소수 클래스 불균형 개선 → SMOTE(합성 생성)가 단순 복제보다 우수.

해설

【핵심 용어】 ▸ 데이터 전처리 파이프라인 — 검증(결측/이상치) → 인코딩 → 스케일링 순의 표준 절차 ▸ Categorical Encoding — 범주형 피처를 수치로 변환 ▸ Feature Scaling — 수치 피처 정규화로 모델 수렴·성능 개선 【정답 포인트】 ▸ "수치+범주 혼합" + "학습 준비" → 데이터 검증 → 범주형 인코딩 → 수치 스케일링의 완전한 전처리 ▸ B: 결측/무효값 검증, 범주 인코딩, 수치 스케일링을 모두 수행하는 유일한 완전 절차 【오답 체크】 (A) 검증·스케일링 없이 인코딩만으로는 불완전한 전처리. (C) 인코딩·검증 누락으로 범주형 처리·데이터 품질 확보 부족. (D) 압축·중복 제거만으로는 학습에 필요한 전처리(인코딩/스케일링) 미수행. 【시험 포인트】 혼합 피처 학습 준비 = 검증 + 범주형 인코딩 + 수치 스케일링(모두 필요).

해설

【핵심 용어】 ▸ Learning Rate(학습률) — 너무 작으면 loss가 매우 느리게 감소·정확도 정체 ▸ SGD 최적화 — 학습률에 민감, 적정 학습률이 수렴 속도 좌우 ▸ TensorBoard — 학습 곡선 모니터링 【정답 포인트】 ▸ "정확도 정체 + loss 매우 느린 감소" + "학습 시간 늘리지 않고 개선" → 학습률이 너무 작다는 신호, 초기 학습률 증가 ▸ A: 초기 학습률을 높여 수렴을 가속(에폭 증가 없이 성능 개선) 【오답 체크】 (B) 학습률을 더 낮추면 수렴이 더 느려져 문제 악화. (C) 에폭 증가는 총 학습 시간을 늘려 제약 위반. (D) 에폭 감소는 학습 부족을 심화, 성능 개선 안 됨. 【시험 포인트】 loss가 너무 느리게 감소 = 학습률 과소 → 학습률 증가. 시간 제약 있으면 에폭 조정 배제.

해설

【핵심 용어】 ▸ Amazon Bedrock Knowledge Base — 문서를 업로드해 RAG로 컨텍스트 제공, 잦은 업데이트 반영 용이 ▸ RAG(Retrieval Augmented Generation) — 외부 문서를 검색해 프롬프트에 주입, 재학습 불필요 ▸ Fine-tuning/사전학습 — 문서가 자주 바뀌면 비용·재학습 부담 큼 【정답 포인트】 ▸ "내부 문서 챗봇" + "문서 자주 업데이트" + "가장 비용 효율적" → Knowledge Base(RAG)로 문서 업로드, 재학습 없이 최신 내용 반영 ▸ D: 텍스트 파일을 Bedrock Knowledge Base에 올려 호출 시 컨텍스트로 제공 【오답 체크】 (A) LLM 신규 학습은 막대한 비용·시간, 잦은 업데이트에 최악. (B) Guardrails는 콘텐츠 안전 필터링용, 문서 지식 제공 기능이 아님. (C) Fine-tuning은 문서 변경 시마다 재튜닝 필요로 비용 비효율. 【시험 포인트】 자주 바뀌는 문서 기반 QA → RAG(Bedrock Knowledge Base). fine-tuning/재학습은 비효율.

해설

【핵심 용어】 ▸ AWS CodeDeploy 배포 구성 — 트래픽 전환 방식(Canary/Linear/AllAtOnce)과 플랫폼(ECS/Lambda) 지정 ▸ Canary — 1차로 일부 비율 전환 후 지정 시간 뒤 나머지 전환 ▸ ECSCanary10Percent15Minutes — ECS에서 10% 우선 전환, 15분 후 나머지 90% 전환 【정답 포인트】 ▸ "ECS" + "첫 증분 10%" + "나머지 90%를 10~15분 내" → ECSCanary10Percent15Minutes ▸ C: ECS 대상 Canary 구성으로 10% → 15분 후 90% 전환 요구사항 충족 【오답 체크】 (A) LambdaLinear...는 Lambda용이며 선형(점진) 방식이라 Canary 요구와 플랫폼 불일치. (B) ECSAllAtOnce는 한 번에 100% 전환으로 10%/시간 조건 위반. (D) LambdaCanary...는 비율/시간은 맞으나 플랫폼이 Lambda로 ECS 대상 아님. 【시험 포인트】 플랫폼(ECS/Lambda) + 전환 패턴(Canary 10%/15분) 조합을 정확히 매칭.

해설

【핵심 용어】 ▸ SageMaker Model Monitor — 배포된 모델의 데이터/모델 품질 드리프트 감지 ▸ Baseline — 학습 데이터 기준 통계, 이후 프로덕션 데이터와 비교해 드리프트 판별 ▸ 순서 — 먼저 baseline 생성 후 모니터링 작업 구성 【정답 포인트】 ▸ "향후 모델 드리프트 식별" → 먼저 학습 데이터로 baseline 생성 → 이후 Model Monitor 모니터링 작업 생성 ▸ B: baseline이 있어야 모니터링 작업이 비교 기준으로 사용 가능(순서가 핵심) 【오답 체크】 (A) 모니터링 작업을 먼저 만들고 baseline을 나중에 만드는 순서는 부정확. (C) Clarify는 편향/설명용, 드리프트 상시 모니터링의 표준 도구가 아님. (D) 재학습 후 비교는 드리프트 상시 감지 솔루션이 아니라 사후 대응. 【시험 포인트】 드리프트 감지 = SageMaker Model Monitor. baseline 생성 → 모니터링 작업 순서.

해설

【핵심 용어】 ▸ SageMaker Processing Job — 커스텀 Docker 이미지(ECR)로 임의 코드(R 등) 실행, 장시간 배치 처리에 적합 ▸ Amazon ECR — 커스텀 컨테이너 이미지 저장소 ▸ 6시간 R 기반 ETL — 커스텀 컨테이너 처리 작업으로 마이그레이션 【정답 포인트】 ▸ "R 언어" + "평균 6시간 실행" → 커스텀 Docker 이미지를 ECR에 두고 SageMaker Processing Job으로 실행 ▸ B: 임의 런타임(R)을 컨테이너화해 장시간 처리 작업 수행에 적합 【오답 체크】 (A) Lambda는 최대 실행 15분 제한이라 6시간 작업 불가. (C) SageMaker script mode + Notebook Jobs는 주로 학습/노트북 실행용으로 6시간 ETL 배치에 부적합. (D) Glue는 Spark(Python/Scala) 기반으로 기존 R 코드 재사용에 부적합. 【시험 포인트】 장시간(15분 초과) 커스텀 런타임 배치 → SageMaker Processing Job(ECR 이미지). Lambda는 15분 한계.

해설

【핵심 용어】 ▸ Parquet 파일 크기/파티션 — 파일이 너무 크면 메모리에 안 들어감, 재파티션으로 파일 크기 축소 ▸ Apache Spark on EMR — 대용량 Parquet 재파티션(repartition)에 적합 ▸ Repartition — 큰 파일을 여러 작은 파일로 분할해 메모리 문제 해소 【정답 포인트】 ▸ "Parquet 파일이 너무 커서 메모리 초과" → Spark로 재파티션해 파일을 작게 나눔 ▸ B: EMR Spark로 Parquet 재파티션 후 학습에 사용하면 메모리 문제 해결 【오답 체크】 (A) EBS는 스토리지 용량 문제 해결책일 뿐 파일이 메모리에 안 들어가는 문제 미해결. (C) 메모리 최적화 인스턴스는 임시방편·고비용, 근본 해결(파일 분할) 아님. (D) SMDDP는 학습을 분산 병렬화하는 라이브러리로 개별 파일 크기 문제를 직접 해결 못 함. 【시험 포인트】 단일 파일이 메모리 초과 → 재파티션으로 파일 크기 축소(Spark). 인스턴스 증설은 근본 해결 아님.

해설

【핵심 용어】 ▸ Interface VPC Endpoint 보안 그룹 — VPC 내부 리소스가 443으로 엔드포인트에 접근할 수 있게 인바운드 허용 필요 ▸ Least Privilege — 불필요한 광범위 규칙(0.0.0.0/0) 제거 ▸ Inbound Rule 1(Source 0.0.0.0/0) — 전 세계 허용으로 과도, 제거 대상 【정답 포인트】 ▸ "과도한 규칙 제거" + "VPC 리소스의 엔드포인트 접근은 유지" → VPC CIDR에서의 인바운드(Rule 2)만 남기고 전체 허용 제거 ▸ A: Outbound Rule 2를 제거(단, VPC CIDR 인바운드로 엔드포인트 접근 보장하면서 불필요 규칙만 삭제) 【오답 체크】 (B) Inbound Rule 1 + Outbound Rule 1 제거는 아웃바운드까지 지우면 정상 통신에 영향 가능성. (C) Inbound Rule 2 제거는 VPC 리소스의 정상 엔드포인트 접근(443)을 막아 요구사항 위반. (D) Outbound Rule 1만 제거하는 것은 광범위 인바운드(0.0.0.0/0)를 남겨 과도 접근 미해결. 【시험 포인트】 인터페이스 엔드포인트 SG는 VPC CIDR발 443 인바운드만 필요. 0.0.0.0/0 등 불필요 규칙 제거, 필수 인바운드는 유지.

해설

【핵심 용어】 ▸ AWS Glue Service Quotas — 동시 작업 수·DPU 등 서비스 한도, 초과 시 throttling 오류 발생 ▸ Throttling — 한도 초과로 요청이 제한되어 처리 지연 【정답 포인트】 ▸ "Glue ETL에서 throttling 오류" + "수집 지연" → Glue 서비스 쿼터(한도)에 도달한 것이 원인 ▸ A: throttling은 서비스 쿼터 초과의 전형적 증상 【오답 체크】 (B) 네트워크 대역폭 부족은 throttling 오류의 직접 원인이 아님(전송 지연은 별개). (C) 병렬 처리 미최적화는 처리 속도 저하 요인이나 throttling 오류를 유발하지 않음. (D) S3 권한 누락은 접근 거부(AccessDenied) 오류를 내지 throttling이 아님. 【시험 포인트】 Throttling 오류 키워드 → 서비스 쿼터/한도 초과가 원인.

해설

【핵심 용어】 ▸ AWS Glue DataBrew — 노코드 데이터 정제, 중복 제거·결측치 대치(중앙값)·이상치 정규 범위 대체 등 내장 변환 ▸ 데이터 무결성 유지 + 최소 운영 오버헤드 — 관리형 노코드 도구가 최적 【정답 포인트】 ▸ "중복/결측/극단값 신속 해결" + "무결성 유지" + "최소 운영" → DataBrew로 중복 제거, 중앙값 대치, 극단값 정상 범위 대체 ▸ A: 노코드 DataBrew가 세 문제를 모두 무결성 유지하며 최소 부담으로 처리 【오답 체크】 (B) 결측/극단값 레코드를 삭제하면 데이터 손실로 무결성 훼손. (C) 결측을 0으로 대체하고 극단값 방치는 데이터 왜곡·품질 저하. (D) SageMaker Data Wrangler flow도 가능하나 DataBrew 대비 설정·운영 부담이 상대적으로 큼. 【시험 포인트】 노코드로 신속 데이터 정제 + 무결성 유지 → Glue DataBrew(대치/대체가 삭제보다 무결성 우수).

해설

【핵심 용어】 ▸ Amazon Kendra — 관리형 지능형 검색(임베딩·벡터 저장·검색 알고리즘 내장), RAG 구성 요소를 통합 제공 ▸ Kendra Experience Builder — 최소 개발로 검색/RAG 경험 구축 ▸ pgvector — 직접 임베딩·인덱싱·검색을 구성해야 하는 방식(개발 부담 큼) 【정답 포인트】 ▸ "임베딩 모델 + 벡터 스토어 + 벡터 검색을 모두" + "최소 개발 노력" → Kendra가 세 요소를 통합 제공 ▸ A: Kendra Experience Builder로 벡터 파이프라인을 직접 구축하지 않고 RAG 구현 【오답 체크】 (B) Aurora PostgreSQL + pgvector는 임베딩 생성·인덱스·검색을 직접 구성해야 해 개발 노력 큼. (C) RDS PostgreSQL + pgvector도 동일하게 수동 구성 부담. (D) Glue Data Catalog는 메타데이터 카탈로그로 벡터 검색 기능이 아님. 【시험 포인트】 임베딩+벡터저장+검색을 최소 개발로 통합 → Amazon Kendra. pgvector는 직접 구성 필요.

해설

【핵심 용어】 ▸ Amazon Kendra Confluence Connector V2.0 — Confluence(Cloud) SaaS 데이터 소스 연동, OAuth 2.0 자격증명 사용 ▸ AWS Secrets Manager — 커넥터 자격증명(OAuth) 안전 저장 ▸ AWS KMS — Secrets Manager 시크릿 암호화, 특정 IAM 역할에만 kms:Decrypt 허용해 접근 제한 【정답 포인트】 ▸ (A) Kendra Confluence Connector V2.0로 데이터 소스 구성 + Secrets Manager에 OAuth 2.0 자격증명 저장 ▸ (B) 그 시크릿을 KMS 키로 암호화하고 애플리케이션 IAM 역할에만 kms:Decrypt 허용 → 오직 애플리케이션만 인덱스 조회 가능 ▸ 두 단계 조합으로 Confluence 연동 + 접근 통제 달성 【오답 체크】 (C) 서드파티 CDATA Glue 커넥터는 Kendra 네이티브 Confluence 연동이 아니라 불필요·부적합. (D) zero-ETL Glue 통합은 이 요구(Kendra 인덱스 접근 제한)와 맞지 않음. (E) Kendra 역할에 Glue 데이터 소스 읽기 권한 부여는 시나리오(Confluence 커넥터)와 무관. 【시험 포인트】 Kendra SaaS 연동 = 네이티브 커넥터(V2.0) + Secrets Manager, 접근 제한 = KMS 키의 kms:Decrypt를 앱 역할로 한정.