AWS Certified Machine Learning Engineer - Associate (MLA-C01)

AWS

AWS Certified Machine Learning Engineer - Associate (MLA-C01)

106+ 무료 연습 문제 (AI 검증 답안 포함)

모든 문제 & 정답 무료

상세 해설

실제 시험과 가장 유사

106+ 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 AWS Certified Machine Learning Engineer - Associate (MLA-C01) 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro

Claude Opus

Gemini Pro

선택지별 상세 해설

심층 문제 분석

3개 모델 합의 정확도

시험 도메인

Data Preparation for Machine Learning (ML)출제율 28%

ML Model Development출제율 26%

Deployment and Orchestration of ML Workflows출제율 22%

ML Solution Monitoring, Maintenance, and Security출제율 24%

실전 문제

문제 1

한 핀테크 스타트업이 42개의 숫자형 feature를 사용하는 gradient-boosted tree 사기 탐지 모델을 Amazon SageMaker real-time endpoint에 ml.m5.large(p95 latency 목표 ≤ 80 ms 및 ~200 RPS)로 배포했으며, 컴플라이언스 담당자는 모델 코드를 변경하지 않고 특정 거래가 왜 플래그되었는지 이해하기 위해 inference마다 feature attribution(예: amount=$1,275, country=DE, device_age_days=14)을 요구한다. 라이브 endpoint의 예측에 대한 설명을 제공할 솔루션은 무엇인가?

문제 분석

핵심 개념: 이 문제는 Amazon SageMaker endpoint에서의 실시간 모델 설명 가능성(explainability)을 테스트한다. 모델 코드를 수정하지 않고 inference마다 feature attribution(로컬 설명)을 제공하도록 목적에 맞게 설계된 AWS 서비스는 Amazon SageMaker Clarify이며, 기존 real-time endpoint에 explainer를 연결할 수 있다. 정답이 맞는 이유: 컴플라이언스 담당자는 각 inference에 대해 “amount=$1,275, country=DE, device_age_days=14”와 같은 거래별 설명을 요구한다. SageMaker Clarify는 모델 endpoint와 함께 explainer(예: SHAP 기반 feature attribution)를 배포하여 온라인 explainability를 지원한다. 이를 통해 원래의 모델 artifact와 inference container를 변경하지 않고도 각 예측 요청/응답 경로에서 feature attribution을 반환할 수 있어, “모델 코드를 변경하지 않고”라는 요구사항에 부합한다. 이는 표 형식(tabular) 모델(gradient-boosted tree 포함)과 숫자형 feature에 적합하며 real-time endpoint와 함께 사용할 수 있다. 주요 AWS 기능: Clarify는 feature attribution 방법(일반적으로 SHAP)을 제공하며, 각 inference에 대해 feature별 기여도 점수를 출력하도록 구성할 수 있다. 실제로는 모델의 입력 스키마, baseline/background dataset(또는 reference), 원하는 출력 형식을 사용해 explainer를 구성한다. 이는 규제 산업(핀테크)에서의 거버넌스 및 감사 가능성(auditability) 요구에 부합하며, 예측과 동시에 동기적으로 설명을 생성해야 하는 운영 사용 사례를 지원한다. 흔한 오해: Model Monitor는 둘 다 거버넌스와 관련이 있어 explainability와 혼동되는 경우가 많다. 하지만 Model Monitor는 시간 경과에 따른 데이터 품질, drift, bias 모니터링 및 알림에 초점을 맞추며, inference별 attribution을 제공하지는 않는다. CloudWatch의 A/B 분포 및 shadow endpoint는 운영 모니터링과 안전한 롤아웃에 도움이 되지만, feature 수준의 설명을 생성하지는 않는다. 시험 팁: “feature attributions”, “왜 이 예측이 나왔는지”, “local explanation”, “SHAP”을 보면 SageMaker Clarify를 떠올려라. “drift”, “data quality”, “bias over time”, “monitoring schedules”를 보면 SageMaker Model Monitor를 떠올려라. 또한 “모델 코드를 변경하지 않고”라는 제약은 모델 container 내부의 커스텀 계측(custom instrumentation)보다는 관리형 explainability 도구를 가리킨다.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

합격 후기(3)

S**********Nov 24, 2025

학습 기간: 2 weeks

Used these questions exclusively to study, passed on first time. The app questions is very similar to the actual exam.

k**********Nov 20, 2025

학습 기간: 2 weeks

Passed Oct 2025 with 905 score.

박

박**Nov 4, 2025

학습 기간: 1 month

문제 좋네요 굿굿!!

모의고사

Practice Test #1

65 문제·170분·합격 720/1000

다른 AWS 자격증

AWS Certified Solutions Architecture - Associate (SAA-C03)

Associate

AWS Certified AI Practitioner (AIF-C01)

Practitioner

AWS Certified Advanced Networking - Specialty (ANS-C01)

Specialty

AWS Certified Cloud Practitioner (CLF-C02)

지금 학습 시작하기

Cloud Pass를 다운로드하여 모든 AWS Certified Machine Learning Engineer - Associate (MLA-C01) 연습 문제를 무료로 이용하세요.

이동 중에도 모든 문제를 풀고 싶으신가요?

무료 앱 받기

Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 2

정유 공장 안전 시스템에서, ML engineer는 센서 스트림에서 메탄 누출을 탐지하는 binary classifier를 선택해야 한다. 실제 누출을 놓치는 경우(false negative)는 평균 사고 비용이 $120,000 발생하는 반면, false alarm은 $300의 현장 점검과 5분의 다운타임을 유발한다. 그렇다면 모델을 선택할 때 어떤 metric 결과를 가장 우선적으로 고려해야 하는가?

문제 분석

핵심 개념: 이 문제는 classification evaluation metrics와 cost-sensitive model selection을 평가한다. 안전이 중요한 탐지(메탄 누출)에서는 오류의 비즈니스 영향이 비대칭이므로, 가장 비용이 큰 오류 유형을 최소화하는 metric을 우선한다. 이는 ML model development의 일부로, 리스크에 맞춰 metrics, thresholds, decision criteria를 선택하는 것이다. 정답이 맞는 이유: false negative는 실제 누출을 놓치는 것으로, 평균 사고 비용이 $120,000이다. false positive는 $300 점검과 5분 다운타임을 유발하는데, 비용 규모가 훨씬 작다. Recall(= sensitivity 또는 true positive rate)은 실제 positive 중에서 올바르게 탐지한 비율을 측정한다: Recall = TP / (TP + FN). Recall을 최대화하면 false negatives(FN)를 직접적으로 줄인다. 따라서 모델 선택 시 high recall을 우선해야 하며(그리고 일반적으로 decision threshold를 조정해 FN을 더 줄임), 그 결과 false alarm이 증가하더라도 감수하는 것이 맞다. 주요 AWS Features / Best Practices: Amazon SageMaker에서 다음을 수행할 수 있다: - 목표를 반영하는 evaluation metrics를 선택(예: recall, 또는 precision보다 recall에 더 큰 가중치를 두는 beta > 1의 F-beta). - 모델 출력(확률)을 사용해 학습 후 classification thresholds를 조정하여 비용에 따라 precision vs recall을 트레이드오프. - SageMaker Automatic Model Tuning에서 training logs를 통해 게시되는 custom metrics(예: 고정 precision에서의 recall, 또는 custom cost function)를 사용. - confusion matrices와 Precision-Recall curves로 평가(imbalanced 또는 safety 컨텍스트에서는 ROC보다 더 유용한 경우가 많음). 이는 AWS Well-Architected 원칙(특히 reliability와 operational excellence)과도 부합한다: 높은 심각도의 실패를 줄이도록 설계한다. 흔한 오해: High precision은 그럴듯하게 들릴 수 있다(“false alarm으로 시간 낭비하지 말자”). 하지만 여기서는 false alarm 비용이 누출을 놓치는 비용에 비해 매우 작다. 또 다른 함정은 “low precision”이 목표라고 생각하는 것인데, 그렇지 않다. 목표는 high recall이며, precision이 떨어질 수는 있지만 그것이 목표는 아니다. 시험 팁: 비용이 비대칭이면 이를 FN vs FP에 매핑하라. FN이 훨씬 더 비싸면(안전, fraud escape, 질병 미탐), recall(또는 beta > 1의 F-beta)을 우선하라. FP가 더 비싸면(예: 정상 결제 차단), precision을 우선하라. base model만 보지 말고 threshold tuning도 항상 고려하라.

문제 3

한 미디어 분석 회사는 12개의 AWS 계정에 걸쳐 200개 이상의 ML 모델을 운영하고 있으며, 각 모델은 계정 로컬 Amazon ECR 리포지토리에 semantic version 태그로 저장된 Docker image로 패키징되어 있습니다. 컴플라이언스 요구사항은 별도의 governance account에 단일 cross-account 중앙 catalog를 두어 versioned entry, approval status(Approved/Pending/Rejected), lineage metadata, audit log를 지원하고, 공유 data science account에 read-only discovery를 제공하며, producer account가 CI/CD를 통해 새 버전을 등록할 수 있게 하고, 계정 간 container image를 복제하거나 마이그레이션하지 않도록 하는 것입니다. 회사는 어떤 솔루션을 구현해야 합니까?

문제 분석

핵심 개념: 이 문제는 아티팩트를 이동하지 않으면서 여러 AWS account 전반에서 ML 모델 거버넌스를 중앙화하는 것을 테스트합니다. 가장 적합한 서비스는 Amazon SageMaker Model Registry(SageMaker MLOps의 일부)로, versioned catalog(Model Package Groups), approval workflow, lineage/metadata, 그리고 AWS CloudTrail을 통한 감사 가능성을 제공합니다. 정답인 이유: 옵션 C는 모든 요구사항을 충족합니다: governance account의 단일 중앙 catalog, versioned entry, approval status(Approved/Pending/Rejected), lineage metadata, audit log. SageMaker Model Registry는 모델 패키지 metadata를 중앙에 저장하면서 모델 아티팩트를 URI(예: ECR image URI 및 선택적으로 S3의 model data)로 참조할 수 있게 합니다. 결정적으로, governance account로 container image를 복제할 필요가 없습니다. producer account는 CI/CD를 통해 cross-account로 SageMaker API를 호출하여 새 model package version을 등록할 수 있고, 공유 data science account에는 model package group 및 버전을 list/describe할 수 있는 read-only discovery 권한을 부여할 수 있습니다. 주요 AWS 기능: - Model Package Groups: 하나의 모델에 대한 논리적 그룹화로, semantic versioning은 연속적인 model package version으로 처리됩니다. - Model approval workflow: ModelPackageApprovalStatus는 규제 환경에서 사용되는 PendingManualApproval/Approved/Rejected 패턴을 지원합니다. - Cross-account access: SageMaker resource-based policy(및/또는 governance account로 sts:AssumeRole 하는 IAM role)를 사용하여 producer account가 model package를 생성하고 consumer account가 이를 list/describe할 수 있도록 허용합니다. 필요 시, producer account의 ECR repository policy와 함께 사용하여 권한이 있는 deployment account가 image pull을 할 수 있게 합니다. - Audit logs: SageMaker API 호출은 governance account의 CloudTrail에 캡처되어 컴플라이언스 및 추적 가능성을 지원합니다. - Lineage/metadata: model package description, tag에 custom metadata를 저장하고, 해당되는 경우 SageMaker lineage tracking과 통합합니다. 흔한 오해: ECR replication(A/B)은 “중앙화”처럼 보이지만, image를 명시적으로 복제하므로 “container image를 복제/마이그레이션하지 않기” 제약을 위반하며, approval workflow나 lineage를 제공하지 않습니다. AWS Glue Data Catalog(D)는 데이터 metadata용이며 container/model 거버넌스용이 아니고, model approval state 및 MLOps lifecycle control을 기본적으로 표현할 수 없습니다. 시험 팁: “model catalog”, “approval status”, “versioned entry”, “audit/compliance”가 보이면 SageMaker Model Registry를 떠올리십시오. 문제가 아티팩트 이동을 금지한다면, replication 기반 접근보다 cross-account reference와 resource policy/assume-role 패턴을 사용하는 metadata catalog를 선호하십시오.

문제 4

220명의 data scientist가 있는 한 온라인 여행 플랫폼은 Amazon SageMaker Model Registry를 사용하여 이미 95개의 model group으로 구성된 1,200개가 넘는 model package version을 추적하고 있습니다. 또한 이 과학자들은 pricing optimization, search relevance, fraud detection의 세 가지 business domain에 맞춰져 있으므로, ML platform engineer는 model artifact, model package version, approval status 또는 현재 model group membership을 수정하지 않고도 기존 자산을 이러한 domain별로 구성하여 대규모에서 discoverability를 향상시키는 솔루션을 구현해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 5

스마트 농업 스타트업은 과수원 열의 4K 드론 이미지(3840x2160)가 주어졌을 때, 각 익은 과일을 자동으로 찾아 각 탐지 결과마다 클래스 레이블과 바운딩 박스 좌표(x_min, y_min, x_max, y_max)를 신뢰도 >= 0.85인 경우에만 반환하는 ML 모델을 Amazon SageMaker에서 구축해야 합니다. 어떤 SageMaker 알고리즘을 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 컴퓨터 비전 문제에 대해 올바른 Amazon SageMaker 내장 알고리즘(또는 작업 유형)을 선택하는지를 평가합니다. 핵심은 요구되는 출력 형태를 인지하는 것입니다: 이미지당 여러 개의 탐지 결과, 클래스 레이블, 바운딩 박스 좌표(x_min, y_min, x_max, y_max), 그리고 신뢰도 임계값 적용. 정답이 맞는 이유: 요구사항은 4K 드론 이미지에서 “각 익은 과일을 찾고” 신뢰도 >= 0.85인 모든 탐지에 대해 바운딩 박스와 클래스 레이블을 반환하는 것입니다. 이는 object detection(여러 인스턴스를 위치 추정 + 분류)의 정의에 해당합니다. SageMaker의 Object Detection 알고리즘(SSD 기반)은 이미지 내 객체에 대한 바운딩 박스와 클래스 확률을 예측하도록 설계되었습니다. 추론 후에는 신뢰도 점수로 예측을 필터링(예: >= 0.85만 유지)하여 비즈니스 규칙을 충족할 수 있습니다. 주요 AWS 기능: SageMaker Object Detection은 라벨링된 바운딩 박스(일반적으로 RecordIO 형식)를 사용한 학습을 지원하며, 특징 추출과 위치 추정을 위해 convolutional neural networks를 사용합니다. 고해상도 이미지에도 적합하지만, 실제로는 GPU 메모리에 맞추고 작은 객체 탐지를 개선하기 위해 전처리 단계에서 4K 이미지를 리사이즈하거나 타일링한 뒤, 바운딩 박스를 원본 좌표로 다시 매핑할 수 있습니다. 학습된 모델은 저지연 추론을 위한 real-time endpoint로 배포하거나, 대규모 오프라인 드론 이미지 처리를 위해 batch transform을 사용할 수 있습니다. 신뢰도 임계값은 보통 후처리에서 적용하며, non-maximum suppression (NMS)은 중복으로 겹치는 박스를 제거하는 데 도움이 됩니다. 흔한 오해: Image classification은 “이미지 + 레이블”이므로 자주 선택되지만, classification은 전체 이미지에 대해 단일 레이블(또는 레이블 집합)만 출력하며 바운딩 박스를 제공하지 않습니다. XGBoost와 k-NN은 표/벡터 데이터용 범용 ML 알고리즘으로, 원시 이미지에서 바운딩 박스를 직접 출력하도록 설계되지 않았습니다. 시험 팁: “bounding boxes”, “(x_min, y_min, x_max, y_max)”, “localize”, “이미지당 여러 객체”, “신뢰도가 있는 detections” 같은 표현이 보이면 올바른 작업은 object detection입니다. 반대로 질문이 “이 이미지에 익은 과일이 있나요?”처럼 존재 여부만 묻는다면 Image classification입니다. 항상 먼저 요구되는 출력 형식을 ML 작업 유형에 매핑한 다음, 그에 맞는 SageMaker 알고리즘/서비스를 선택하세요.

문제 6

한 ML 엔지니어가 Amazon SageMaker XGBoost 알고리즘을 사용하여 뉴스 추천 시스템을 위한 클릭률 예측 모델을 구축하고 있습니다. 이때 이진 분류기는 노출(impression)을 클릭 또는 비클릭으로 라벨링하며, 500만 행과 180개 feature(원-핫 인코딩된 publisher_id 및 time bucket feature 포함)로 학습됩니다. 현재 hyperparameter가 max_depth=10, eta=0.1, subsample=1.0일 때 모델은 학습 세트에서 0.99 AUC와 95% precision을 달성하지만, 홀드아웃된 1주 트래픽과 새로 유입되는 노출에서는 0.68 AUC와 35% precision만 보여 심각한 overfitting을 시사합니다. 알고리즘이나 feature space를 변경하지 않고 새로운 노출에 대한 일반화를 개선하려면 엔지니어는 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 gradient-boosted decision tree(Amazon SageMaker XGBoost)에서의 ML 모델 개발과 regularization을 평가합니다. 증상(학습 지표는 매우 우수하지만 홀드아웃/신규 트래픽 지표는 저조함)은 높은 분산(high variance)/overfitting을 의미합니다. tree boosting에서는 모델 용량(model capacity)이 tree depth 및 관련 복잡도 파라미터에 의해 크게 제어됩니다. 정답이 맞는 이유: max_depth=10이면 tree가 상당히 깊어, 모델이 학습 주(week)의 특이한 패턴을 외우기 쉽습니다. 특히 sparse한 one-hot publisher_id 및 time-bucket feature는 거의 고유한 분할을 많이 만들 수 있습니다. 그 결과 학습 AUC/precision은 거의 완벽하지만, 다른 주(week)와 신규 노출에 대한 일반화는 약해집니다. max_depth를 낮추면 가설 공간(hypothesis space)이 줄어들어(더 얕은 tree), 노이즈나 특정 주(week)에만 해당하는 상관관계를 맞추기보다 더 넓고 안정적인 패턴을 학습하도록 강제합니다. 이는 알고리즘이나 feature space를 바꾸지 않고 overfitting을 줄이는 가장 직접적인 레버입니다. 주요 AWS 기능 / Best Practice: SageMaker XGBoost에서 max_depth는 각 boosted tree의 최대 깊이를 제어하며, 일반적으로 더 작은 값이 일반화에 도움이 됩니다. 이는 ML에서 성능 효율성과 신뢰성을 위해 더 잘 일반화되는 단순한 모델을 선호한다는 AWS Well-Architected 원칙과도 부합합니다. 실무에서는 SageMaker Automatic Model Tuning을 사용해 max_depth(그리고 종종 min_child_weight, gamma, reg_alpha/reg_lambda, subsample/colsample_bytree, early stopping도 함께)를 튜닝하고, 프로덕션 drift에 맞추기 위해 시간 기반 validation split으로 평가합니다. 흔한 오해: eta를 올려 “더 빠르게 학습”하거나 max_depth를 올려 “복잡도를 추가”하고 싶을 수 있지만, 모델이 이미 학습 데이터를 매우 잘 맞추는 상황에서는 둘 다 보통 overfitting을 악화시킵니다. 또 다른 흔한 생각은 feature를 제거하는 것이지만, 문제에서 feature space를 변경하지 말라고 명시하고 있으며, feature 제거는 순수한 hyperparameter 기반 일반화 개선이 아니라 데이터/feature-engineering 변경입니다. 시험 팁: 학습 성능과 validation/test 성능 간 격차가 크면 overfitting/high variance를 의심하십시오. tree-based boosting의 1차 대응은 max_depth를 줄이고, subsampling/column sampling을 추가하며, regularization을 늘리고, early stopping을 사용하는 것입니다. 문제에서 알고리즘과 feature를 제한한다면 모델 복잡도를 줄이는 hyperparameter 변경을 선택해야 하며, 여기서는 max_depth 감소가 해당됩니다.

문제 7

미디어 모니터링 팀이 주당 다국어 팟캐스트 오디오(MP3) 900시간, 주당 컨퍼런스 녹화(MP4 비디오) 300시간, 블로그 게시물 35,000개를 수집하며, 이 중 이탈리아어 항목에 대해서만 24시간 이내에 독일어 요약을 제공해야 합니다. 또한 엔지니어링 노력을 최소화하고 어떤 모델 학습도 피해야 합니다. 어떤 솔루션이 가장 짧은 시간 내에 요구 사항을 충족하나요?

문제 분석

핵심 개념: 이 문제는 audio, video, text 전반에 걸친 multilingual content processing에 대해, 어떤 model training도 피하면서 가장 빠른 fully managed AWS AI solution을 선택하는지를 평가합니다. 필요한 pipeline은 podcasts, conference recordings, blog posts를 처리하고, Italian-language 항목만 식별한 뒤, managed services를 사용하여 24시간 이내에 German summaries를 생성해야 합니다. 정답인 이유: 어떤 선택지도 완벽하게 설계되지는 않았지만, option B가 가장 요구 사항에 가깝습니다. 왜냐하면 MP3 및 MP4 입력에 대해 speech-to-text를 위해 Amazon Transcribe를 올바르게 사용하고, training 없이 summarization을 위해 Anthropic Claude가 포함된 Amazon Bedrock을 사용하기 때문입니다. 하지만 German summaries를 생성하는 데 Amazon Translate로 English로 번역하는 단계는 불필요하며, 더 중요한 점은 이 선택지가 35,000개의 blog posts를 명시적으로 다루지 않는다는 것입니다. 그럼에도 불구하고 다른 선택지들은 AWS services를 잘못 사용하거나 custom model training을 요구하므로 분명히 덜 적합합니다. 따라서 B는 선택지들 중에서 여전히 가장 적절한 정답입니다. 주요 AWS 기능: - Amazon Transcribe batch는 대규모 audio 및 video speech content에 대해 asynchronous transcription을 지원합니다. - Amazon Bedrock은 infrastructure management나 training 없이 multilingual summarization을 위한 Claude와 같은 managed foundation models를 제공합니다. - Amazon Translate는 text를 언어 간에 번역할 수 있지만, model이 직접 summarize할 수 있다면 German summaries를 생성하기 전에 Italian을 English로 번역할 필요는 없습니다. - text blog posts의 경우, 실제 설계에서는 language filtering 이후 원본 text를 직접 Bedrock으로 보내는 방식이 실용적이지만, 그 단계는 어떤 선택지에도 명시적으로 포함되어 있지 않습니다. 흔한 오해: A는 custom model training이 필요하므로 적절하지 않습니다. 문제에서 이를 명시적으로 금지하고 있기 때문입니다. C는 Rekognition이 podcasts와 conference recordings에 대한 speech transcription을 수행하지 않으므로 틀렸습니다. D는 Comprehend가 audio/video를 text로 변환하지 않으며, Stable Diffusion은 text summarization model이 아니므로 틀렸습니다. 시험 팁: AWS AI 시험에서는 먼저 각 modality를 올바른 managed service에 매핑하세요: speech에는 Transcribe, language conversion에는 Translate, text analytics에는 Comprehend, generative text tasks에는 Bedrock입니다. 완벽한 선택지가 없다면, 핵심 요구 사항을 가장 잘 충족하면서 technical mismatches가 가장 적은 것을 고르세요. services를 잘못 사용하거나 불필요한 translation/training 단계를 추가하는 distractors를 주의하세요.

문제 8

온라인 마켓플레이스의 한 ML engineer가 200,000건의 과거 거래 데이터를 사용하여 중고 스마트폰의 재판매 가격(USD)을 예측하는 모델을 구축하고 있습니다. 여기서 타깃은 $50에서 $1,500까지 범위의 연속값이며, 이해관계자들은 동일한 단위(USD)로 평균 절대 예측 오차를 보고하는 평가 지표를 요구합니다. 모델의 성능을 평가하기 위해 어떤 지표를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 지도 학습 문제에 적절한 평가 지표를 선택하는지를 테스트합니다. 타깃 변수가 USD로 표현되는 연속적인 재판매 가격이므로, 이는 (분류가 아닌) 회귀(regression) 작업입니다. 또한 지표는 타깃과 동일한 단위로 평균 절대 예측 오차를 표현해야 합니다. 정답이 맞는 이유: Mean Absolute Error (MAE)는 예측값과 실제값 간 오차의 평균 크기를 직접 측정합니다: MAE = average(|y - ŷ|). 절대 차이를 사용하므로 결과는 타깃과 동일한 단위(USD)로 표현됩니다. 이해관계자들이 “USD로 평균 절대 예측 오차”를 원한다면 MAE가 가장 직접적으로 부합합니다. 또한 해석이 쉽습니다. 예를 들어 MAE가 75라면 모델이 평균적으로 $75만큼 빗나간다는 의미로, 가격 책정에 대한 비즈니스 기대와 잘 맞습니다. 주요 AWS 기능 / 모범 사례: AWS ML 워크플로(예: Amazon SageMaker training jobs 및 모델 평가)에서 회귀 지표로는 일반적으로 MAE, MSE/RMSE, R2 등이 사용됩니다. 비즈니스 단위로의 해석 가능성이 중요할 때는 MAE가 자주 선호됩니다. 또한 MSE/RMSE처럼 오차를 제곱하지 않기 때문에 이상치(outliers)에 더 강건합니다(다만 이상치의 영향이 선형적으로는 반영됩니다). SageMaker에서는 학습 중에 MAE를 계산(사용 가능한 경우 custom metric definitions, built-in algorithm metrics)하거나, 학습 후 평가 단계(SageMaker Processing, Pipelines)에서 계산하여 Amazon CloudWatch 또는 SageMaker Experiments에서 추적할 수 있습니다. 흔한 오해: 응시자들은 인기 있는 지표라는 이유로 “Accuracy” 또는 “F1”을 고르는 경우가 많지만, 이는 출력이 이산 레이블인 분류 문제에 적용됩니다. AUC 역시 분류 전용이며 임계값 전반에서의 순위 품질을 측정하는 것으로, USD 단위의 오차를 제공하지 않습니다. 또 다른 흔한 혼동은 MAE와 RMSE 사이에서 발생합니다. RMSE도 USD 단위이지만 큰 오차를 더 크게 강조합니다. 문제는 명시적으로 “average absolute” 오차를 요구하므로 MAE가 정답입니다. 시험 팁: 먼저 ML 문제 유형을 식별하세요: 연속 타깃은 회귀를 의미합니다. 그다음 이해관계자 요구사항을 지표 특성과 매칭하세요: “absolute”와 “same units”는 MAE를 강하게 시사합니다. Accuracy/F1/AUC는 분류 지표이고, MAE/RMSE/R2는 회귀 지표라는 점을 기억하세요. 비즈니스 사용자가 해석 가능한 “평균적으로 몇 달러 차이”를 원할 때는 보통 MAE가 최선의 답입니다.

문제 9

2.5백만 건의 과거 신청 데이터와 18개 feature( age_group 및 income_bracket 포함)를 보유한 온라인 대출 플랫폼이 Amazon SageMaker에서 이진 default-risk 모델을 학습하고 있으며, 보호 대상 그룹 전반에서 성능을 왜곡할 수 있는 패턴(예: 18–25세 신청자 vs 60+ 신청자 간 demographic parity difference > 0.1)을 탐지하고 정량화하기 위해 학습 데이터와 batch prediction 출력 모두를 검토해야 합니다. 어떤 솔루션이 이러한 수준의 분석을 제공합니까?

문제 분석

핵심 개념: 이 문제는 Amazon SageMaker에서 학습 데이터와 모델 prediction 모두에 대해 bias를 탐지하고 정량화하는 것을 테스트합니다. 이를 위해 목적에 맞게 설계된 AWS 서비스는 Amazon SageMaker Clarify이며, Clarify는 bias metric(학습 전 및 학습 후)과 explainability(feature attribution)를 제공합니다. 정답이 맞는 이유: 플랫폼은 (1) 학습 dataset과 (2) batch prediction 출력 모두를 검토하여 보호 대상 그룹 간 demographic parity difference가 임계값을 초과하는 것과 같은 패턴을 탐지하고 정량화해야 합니다(예: 18–25세 vs 60+). SageMaker Clarify는 지정된 sensitive attribute(예: age_group)와 label/outcome(예: default vs no default)을 사용하여 입력 dataset에 대한 bias metric(학습 전 bias)과 inference 결과에 대한 bias metric(학습 후 bias)을 계산함으로써 이 워크플로를 직접 지원합니다. Clarify는 processing job으로 실행될 수 있고 SageMaker batch transform 출력과 통합되며, demographic parity, disparate impact 및 기타 group fairness measure 같은 metric을 포함하는 bias report를 생성합니다. 주요 AWS 기능: Clarify는 다음을 지원합니다: - 학습 전 bias 분석: 그룹 간 label 및 feature의 불균형을 탐지. - 학습 후 bias 분석: 그룹 간 prediction outcome을 평가( batch inference 포함). - 구성 가능한 facet( age_group/income_bracket 같은 sensitive feature) 및 그룹(예: 18–25 vs 60+). - 보고서 및 시각화( SageMaker Studio를 통해)와 auditability를 위해 Amazon S3에 저장되는 artifact. - SHAP 기반 feature attribution을 통한 explainability로 prediction의 driver를 이해하며, 이는 bias metric을 보완. 흔한 오해: bias는 데이터를 변환하여 완화할 수 있으므로 data-prep 도구(Glue DataBrew)나 자동화(Lambda)를 선택하고 싶을 수 있습니다. 그러나 요구사항은 단순히 데이터를 정리하거나 변환하는 것이 아니라, 데이터와 prediction 모두에 대해 공식적인 fairness metric으로 bias 패턴을 탐지하고 정량화하는 것입니다. CloudWatch는 운영 모니터링이며 fairness 분석이 아닙니다. 시험 팁: “bias”, “protected groups”, “demographic parity”, “disparate impact”, “explainability”, “training data + predictions” 같은 키워드를 보면 시험은 SageMaker Clarify를 가리키고 있습니다. Clarify( fairness/explainability)를 Model Monitor( data/model drift 및 품질) 및 기본적으로 fairness metric을 계산하지 않는 일반 ETL 도구(DataBrew/Glue)와 구분하십시오.

문제 10

비디오 스트리밍 플랫폼이 Amazon SageMaker real-time endpoint에서 실시간 콘텐츠 모더레이션 모델을 실행하고 있으며, 분당 약 1,500개의 요청을 처리하고 p95 latency SLO는 120 ms입니다. 더 큰 다국어 데이터셋으로 학습된 새 모델 버전이 준비되었고, 팀은 24시간 동안 동일한 라이브 프로덕션 요청을 사용해 정확도와 latency를 평가하면서 오프라인 비교를 위해 해당 추론 결과를 저장해야 합니다. 또한 어떤 프로덕션 사용자 의사결정이나 latency에도 영향을 주면 안 됩니다. 어떤 솔루션이 이러한 요구 사항을 충족하나요?

문제 분석

핵심 개념: 이 문제는 Amazon SageMaker real-time endpoints를 사용해 사용자에게 노출되는 의사결정이나 latency에 영향을 주지 않으면서, 프로덕션에서 새 모델을 안전하게 평가하는 방법을 테스트합니다. 핵심은 동일한 라이브 요청을 추가 모델 variant로도 실행(정확도/latency 측정)하되, 애플리케이션에 반환되는 응답은 프로덕션 variant만 제공하도록 하는 것입니다. 정답이 맞는 이유: shadow variant를 사용하는 shadow testing(D)은 정확히 이 요구 사항을 위해 설계되었습니다. 프로덕션 트래픽을 복제하여 고정된 평가 기간(24시간) 동안 새 모델 버전으로도 보내되, 프로덕션 응답 경로는 변경되지 않도록 보장합니다. 이를 통해 실제 프로덕션 부하와 데이터 분포에서의 정확도와 latency를 측정하고, shadow 모델의 추론 결과를 저장하여 오프라인 비교를 수행할 수 있으며, 프로덕션 사용자 의사결정에는 영향을 주지 않습니다. 프로덕션 variant가 계속해서 응답의 100%를 제공하므로 사용자에게 보이는 동작과 의사결정이 변경되지 않습니다. 주요 AWS 기능: SageMaker에서는 하나의 endpoint 뒤에 여러 production variants를 배포할 수 있으며, 요청이 shadow variant로 미러링되도록 shadow variant를 구성할 수 있습니다(클라이언트에는 응답을 반환하지 않음). SageMaker Data Capture를 사용해 shadow variant의 출력(입력/출력 payload 캡처)을 캡처하고 Amazon S3에 저장하여 오프라인 분석을 수행할 수 있습니다. 또한 CloudWatch metrics를 사용해 variant별 latency와 invocation count를 비교할 수 있고, 필요 시 shadow variant가 미러링된 부하를 throttling 없이 처리하도록 autoscaling을 활성화할 수도 있습니다. 흔한 오해: canary 또는 blue/green shifting(B/C)은 점진적 롤아웃에 자주 사용되지만, 실제 사용자 트래픽의 일부를 새 모델로 라우팅하여 그 응답을 사용자에게 반환합니다. 이는 프로덕션 사용자 의사결정에 영향을 주지 말아야 한다는 요구 사항을 위반합니다. Debugger(A)는 tensors를 디버깅/학습/모니터링하고 문제를 감지하기 위한 것이지, 추론 출력에 대한 병렬 “무영향(no-impact)” 라이브 A/B 평가를 수행하기 위한 것이 아닙니다. 시험 팁: 문제에서 “동일한 라이브 프로덕션 요청을 사용”하면서 “프로덕션 의사결정에 영향을 주지 말 것”이라고 하면 “shadow testing”, “traffic mirroring”, “shadow variant”를 찾으세요. 실제 응답을 위해 트래픽을 전환하는 옵션(1%라도)은 사용자 결과를 바꾸므로 허용되지 않습니다. shadow testing을 Data Capture와 함께 사용해 오프라인 비교를 위한 추론 결과를 영속화하세요.

문제 11

(2개 선택)

한 데이터 과학자가 Amazon SageMaker 외부에서 scikit-learn 이탈(churn) 모델을 내보내고, SSE-S3로 암호화된 버킷(s3://retail-ml-artifacts-prod/models/churn/2025-07-01/)에 7.8-GB model.tar.gz 아티팩트를 저장했습니다. 그리고 동일한 SageMaker domain에서 SageMaker Canvas를 사용하는 비즈니스 분석가가 노코드 평가 및 반복 튜닝을 할 수 있도록 이 모델을 검색 가능(discoverable)하게 만들어야 합니다. Canvas 사용자와 모델을 공유하려면 어떤 요구 사항 조합을 충족해야 합니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 SageMaker Canvas가 Canvas 외부에서 생성된 모델을 어떻게 검색하고 사용하는지, 그리고 SageMaker Studio domain 내에서 페르소나 간 모델을 공유하기 위한 거버넌스/권한 경로를 테스트합니다. 핵심 서비스는 Amazon S3(모델 아티팩트), SageMaker Model Registry(model packages/versions), IAM/SageMaker domain execution role입니다. 정답이 맞는 이유: 외부에서 빌드된 scikit-learn 모델을 Canvas에서 “검색 가능(discoverable)”하게 만들려면, 모델이 SageMaker의 모델 거버넌스 계층을 통해 노출되어야 합니다. 동일한 domain/account/region 컨텍스트에서 SageMaker Model Registry에 모델을 model package/version으로 등록하는 것이, Studio/Canvas가 임의의 S3 객체가 아니라 승인/등록된 모델을 나열하고 소비할 수 있게 하는 표준 메커니즘입니다. 또한 모델이 등록되어 있더라도, Canvas(정확히는 Canvas 사용자의 execution role)는 S3에 있는 기본 model.tar.gz를 읽을 수 있어야 합니다. SSE-S3 암호화의 경우 관리해야 할 KMS key policy는 없지만, S3 권한 부여는 여전히 적용됩니다. 따라서 role에는 bucket/key에 대한 s3:GetObject(그리고 일반적으로 해당 prefix에 대한 s3:ListBucket)가 필요합니다. 주요 AWS 기능: - SageMaker Model Registry: model packages, versions, 승인 상태, lineage, 그리고 다운스트림 도구로의 통제된 공유. - IAM 및 S3 access control: 아티팩트 prefix에 대한 s3:GetObject를 위한 bucket policy 및 role 권한. - SSE-S3: SSE-KMS 대비 암호화 관리가 단순하지만, S3 권한 필요성을 제거하지는 않음. 흔한 오해: Canvas에 real-time endpoint 배포가 필요하다고 생각하기 쉽지만, 검색 가능성/공유는 호스팅이 아니라 거버넌스와 액세스에 관한 것입니다. 또한 AWS Marketplace는 내부 모델 공유와 무관합니다. domain 분리도 틀렸습니다. Canvas와 데이터 과학자는 해당 domain 컨텍스트에서 리소스를 공유하려면 동일한 SageMaker domain에 있어야 합니다. 시험 팁: “Canvas/Studio에서 검색 가능(discoverable)”이라는 표현을 보면 “Model Registry + permissions”를 떠올리세요. “S3에 있는 모델 아티팩트”가 보이면, 소비자 페르소나의 IAM role이 정확한 S3 prefix/object를 읽을 수 있는지 항상 검증하세요(암호화 유형에 따라 KMS 권한도 필요할 수 있음).

문제 12

한 방사선 영상 분석 스타트업은 현재 독자적인 12 TB DICOM 데이터와 도메인 특화 전처리를 사용하며, 커스텀 TensorFlow 2.12 Python 3.10 스크립트로 프라이빗 서버에서 이미지 세그멘테이션 모델을 학습하고 서빙하고 있습니다. 이 스타트업은 기존 코드를 보존하면서 2주 이내에 학습과 추론을 모두 AWS로 마이그레이션해야 하며, 단일 GPU 인스턴스(예: 1×V100이 있는 ml.p3.2xlarge)에서 실행해야 합니다. 최소한의 노력으로 이를 달성할 수 있는 접근 방식은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon SageMaker가 SageMaker Script Mode와 TensorFlow용 AWS Deep Learning Containers(DLCs)를 통해 GPU 인스턴스에서 관리형 학습 및 호스팅을 제공하면서, 최소한의 리팩터링으로 기존 ML 코드를 실행할 수 있는지를 평가합니다. 정답이 맞는 이유: 스타트업은 2주 이내에 마이그레이션해야 하고, 기존 TensorFlow 2.12 / Python 3.10 스크립트를 보존해야 하며, 단일 GPU 인스턴스(예: ml.p3.2xlarge)에서 실행해야 합니다. 사전 구축된 TensorFlow container를 사용하는 SageMaker Script Mode는 이를 위해 설계되었습니다. 즉, 기존 엔트리 포인트 스크립트(학습 및 추론)를 제공하면 SageMaker가 프로비저닝, container 내 GPU drivers/CUDA 호환성, S3에서의 data channel 마운트, 로깅, 메트릭, 모델 아티팩트 관리를 처리합니다. built-in algorithms에 맞추기 위해 코드를 다시 작성할 필요가 없고, 커스텀 container를 빌드/패치하는 운영 오버헤드도 피할 수 있으므로 가장 적은 노력으로 가능한 경로입니다. 주요 AWS 기능: - TensorFlow DLC image( TF 2.12 및 Python 3.10에 매칭되거나 가장 근접한 지원 tag)를 사용하는 SageMaker Training jobs, 그리고 ml.p3.2xlarge에서의 GPU 지원. - Script Mode: hyperparameters를 전달하고 entry_point/source_dir를 지정하며, SageMaker environment variables(예: SM_CHANNEL_TRAIN, SM_MODEL_DIR)를 사용해 데이터를 찾고 모델 아티팩트를 기록. - SageMaker Hosting: 동일한 framework container와 inference script(model_fn/predict_fn/input_fn/output_fn)를 사용해 결과 모델을 real-time endpoint로 배포하여 전처리를 보존. - 데이터 처리: 12 TB DICOM 데이터셋을 S3에 저장하고 S3 input channels로 스트리밍/샤딩; 로컬 디스크 요구를 줄이기 위해 지원되는 경우 Pipe mode를 선택적으로 사용. 흔한 오해: built-in algorithms(옵션 A)는 “빠르다”라고 들릴 수 있지만, AWS 제공 모델 구현과 데이터 포맷을 채택해야 하므로 독자적 전처리와 기존 TensorFlow 스크립트 요구사항과 충돌합니다. BYOC(옵션 C)는 유연하지만, container 엔지니어링, 보안 패치, 의존성 관리에 시간이 많이 들며 2주 마감에서는 위험합니다. Marketplace 모델(옵션 D)은 독자적 학습 코드를 보존하지 못하고, 특화된 의료 세그멘테이션 요구사항과 일치하는 경우가 드뭅니다. 시험 팁: 문장에서 “preserve existing code”, “least effort”, 그리고 표준 framework(TensorFlow/PyTorch)가 강조되면 SageMaker framework containers + Script Mode를 우선 선택하십시오. BYOC는 DLCs로 충족되지 않는 미지원 framework, 커스텀 시스템 라이브러리, 또는 매우 특정한 런타임 제약이 필요할 때만 선택합니다. built-in algorithms는 기대 입력에 맞출 수 있고 커스텀 학습 로직이 필요 없을 때 가장 적합합니다.

문제 13

한 피트니스 앱 회사는 가속 인스턴스 타입(g5.xlarge)의 8개 Reserved Instances를 사용하여 Amazon SageMaker real-time endpoint에서 추천 모델의 현재 버전을 제공하고 있으며, 배포 프로세스 전용으로 동일한 타입의 Reserved Instance가 정확히 1개 추가로 제공됩니다. 전환 과정 동안 솔루션은 다운타임이나 서비스 중단 없이 기존 8개 인스턴스를 재사용하여 이전 모델 버전과 새 모델 버전을 모두 호스팅해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 14

미디어 분석 팀이 4시간마다 job queue에서 AWS Batch array 전처리 job을 실행하고 때때로 수동으로도 실행합니다. 이 팀은 데이터 처리 단계에서 해당 job들의 S3 출력물을 소비할 Amazon SageMaker Pipelines를 구축하고 있으며, state machine이나 장시간 실행되는 서비스를 도입하지 않으면서 job이 성공한 후 2분 이내에 pipeline이 시작되어야 합니다. 운영 오버헤드가 가장 적으면서 AWS Batch job을 pipeline과 통합하는 접근 방식은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 최소한의 운영으로 ML 워크플로를 이벤트 기반으로 오케스트레이션하는지를 테스트합니다. 핵심 서비스는 Amazon EventBridge(AWS Batch job 상태 변경에 반응)와 Amazon SageMaker Pipelines(ML 워크플로 실행)입니다. 요구 사항에서 state machine과 장시간 실행되는 서비스를 명시적으로 피하라고 하므로, 관리형 서버리스 이벤트 라우팅으로 유도됩니다. 정답이 맞는 이유: Amazon EventBridge는 AWS Batch Job State Change 이벤트(예: SUCCEEDED)를 네이티브로 수신하고 거의 실시간으로 대상(target)으로 라우팅할 수 있습니다. 특정 Batch job/queue( array job 포함)의 성공 완료를 매칭하는 EventBridge rule을 만들고 대상을 SageMaker(StartPipelineExecution)로 설정하면, Batch job이 성공한 후 2분 SLA 내에 pipeline을 시작할 수 있습니다. 또한 트리거가 job 제출 방식이 아니라 job 성공 이벤트이므로, job이 스케줄(4시간마다)로 실행되든 수동으로 실행되든 모두 동작합니다. 주요 AWS 기능: 1) AWS Batch job 상태 변경에 대한 event pattern을 가진 EventBridge rule(detail.status = "SUCCEEDED", jobQueue/jobName 필터). 2) SageMaker Pipelines(StartPipelineExecution)에 대한 EventBridge target 및 동적 값(예: S3 output prefix, jobId)을 pipeline parameter로 전달하기 위한 optional input transformation. 3) 복원력을 위한 EventBridge target의 optional dead-letter queue(SQS) 및 retry policy. 4) IAM: EventBridge에는 sagemaker:StartPipelineExecution 호출 권한이 필요하고, SageMaker step에는 Batch 출력물에 대한 S3 read 권한이 필요합니다. 흔한 오해: Step Functions는 흔한 오케스트레이션 답이지만, 문제에서 명시적으로 금지(“state machine을 도입하지 말 것”)하므로 제외됩니다. Pipelines의 Callback step은 외부 작업을 “대기”할 수 있을 것처럼 보이지만, 여전히 외부 액터가 callback을 호출해야 하며 기존 Batch job과의 가장 단순한 통합이 아닙니다. 또한 Batch job ARN을 pipeline 입력으로 참조하는 것은 SageMaker Processing 입력 방식이 아니며, Processing은 job 메타데이터가 아니라 데이터 위치(예: S3)를 소비합니다. 시험 팁: “어떤 이벤트 이후 X분 내 시작”과 “최소 운영 오버헤드”가 보이면 EventBridge를 떠올리십시오. 문제가 state machine/서버를 금지하면 Step Functions나 커스텀 poller보다 관리형 이벤트 라우팅(EventBridge)을 우선합니다. 또한 SageMaker Pipelines는 API로 트리거할 수 있고, EventBridge는 Batch job 상태 변경 같은 AWS 서비스 이벤트에 반응하는 표준 방식임을 기억하십시오.

문제 15

로보틱스 R&D 회사가 두 개의 VPC subnet에 걸쳐 9명의 ML engineer를 위해 6개의 Amazon SageMaker notebook instance를 운영하고 있습니다. 각 instance는 자체 execution IAM role로 생성되었고, 분기별 audit 동안 engineer들이 두 개의 S3 bucket(s3://cv-raw-2025 및 s3://cv-curated-2025)에 대한 추가 read-only access가 필요할 때마다 security team이 6개의 role을 각각 별도로 업데이트해야 합니다. 회사는 광범위한 administrator privilege를 부여하지 않으면서 단일 업데이트가 모든 notebook instance에 적용되도록 permission 변경을 중앙화하려고 합니다. 어떤 솔루션이 이 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 Amazon SageMaker notebook instance를 위한 IAM role 설계, 특히 execution role과 least privilege를 사용하여 permission을 중앙화하고 거버넌스하는 방법을 평가합니다. SageMaker notebook instance는 long-term credential을 포함하지 않고 AWS resource(S3 등)에 접근하기 위해 IAM execution role을 assume합니다. 정답이 맞는 이유: Option A는 모든 notebook instance를 단일 execution IAM role로 표준화하여 permission을 중앙화합니다. 분기별 audit에서 s3://cv-raw-2025 및 s3://cv-curated-2025에 대한 추가 read-only access가 필요할 때, security team은 해당 단일 role에 연결된 하나의 policy(inline 또는 attached managed policy)를 업데이트하면 변경 사항이 6개의 notebook instance 모두에 즉시 적용됩니다(IAM policy propagation을 고려). 이는 “단일 업데이트가 모든 notebook instance에 적용” 요구 사항을 충족하며, S3 read permission(예: bucket에 대한 s3:ListBucket, bucket prefix/object에 대한 s3:GetObject)과 notebook에 필요한 최소 SageMaker permission만 부여함으로써 광범위한 administrator privilege를 피합니다. 주요 AWS 기능: - SageMaker notebook execution role: notebook instance가 AWS API를 호출하기 위해 assume하는 role - IAM managed policy: 공유 role에 customer-managed policy(예: “AuditS3ReadOnly”)를 attach하여 분기별 변경을 하나의 policy document 수정으로 처리 - Least privilege: S3 permission을 두 bucket과 필요한 action으로만 범위 제한; wildcard resource/action 회피 - 운영 거버넌스: 단일 role은 notebook 간 drift 및 불일치 permission을 줄임 흔한 오해: 자주 빠지는 함정은 IAM group을 AWS service에 “attach”할 수 있다고 생각하는 것입니다. Group은 IAM user에게 permission을 부여하는 용도이며 SageMaker notebook instance에 직접 적용되지 않습니다. 또 다른 오해는 단순화를 위해 notebook에서 IAM user access key를 사용하는 것인데, 이는 best practice를 위반하고 credential 유출 위험을 증가시킵니다. 시험 팁: 코드를 실행하는 AWS service(SageMaker, EC2, Lambda)에서는 IAM user와 access key보다 IAM role을 우선 사용하십시오. “permission 변경을 중앙화”하라는 요구가 나오면 shared role 및/또는 shared managed policy를 찾으십시오. 또한 AdministratorAccess를 도입하는 선택지는 대부분 exam 시나리오의 least-privilege 요구 사항과 맞지 않습니다.

문제 16

한 공공 의료 네트워크가 Amazon Q Business에 대한 API 호출을 통해 하루 약 2,000건의 질의를 처리하는 내부 법률 보조 챗봇을 배포하고 있습니다. 컴플라이언스 정책에 따라 모델의 응답에는 기밀 코드명 "Project Raven"(정확한 문구 일치)이 절대로 포함되면 안 되며, 해당 문자열이 인덱싱된 소스 문서에 존재하더라도 마찬가지입니다. 또한 기존 인덱스를 수정하지 않고 응답 시점에 제어가 강제되어야 합니다. 이 요구 사항을 충족하기 위해 팀은 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 기존 인덱싱된 콘텐츠에 무엇이 저장되어 있든 관계없이 민감한 용어가 노출되지 않도록 응답 시점(출력 가드레일)에서 동작하는 Amazon Q Business 보안 및 거버넌스 제어를 테스트합니다. 이는 AWS Well-Architected Framework의 “Security” 및 “Data protection” 원칙과 정렬됩니다. 정답이 맞는 이유: 요구 사항은 명확합니다. 인덱싱된 문서에 존재하더라도 챗봇의 응답에는 정확한 문구 “Project Raven”이 절대로 포함되면 안 되며, 기존 인덱스를 수정하지 않고 응답 시점에 제어가 강제되어야 합니다. Amazon Q Business는 생성된 응답에 특정 단어/문구가 나타나지 않도록 차단하는 관리 제어를 제공합니다. “Project Raven”을 차단 문구로 구성하면 검색 결과와 무관하게 API가 반환하는 최종 응답에서 해당 용어가 필터링/마스킹/차단되도록 출력 시점 정책이 적용됩니다. 주요 AWS 기능: Amazon Q Business의 차단 문구(때로는 차단 단어/문구로 설명됨)는 특정 문자열이 응답으로 출력되는 것을 방지하여 컴플라이언스와 안전을 지원하도록 설계되었습니다. 이는 출력 제어(응답 시점 강제)로서 정책이 요구하는 바와 정확히 일치합니다. 액세스 제어 통합 및 콘텐츠 필터링 같은 다른 제어를 보완하지만, 재인덱싱 없이 “이 정확한 문구는 절대 포함되면 안 됨” 제약을 유일하게 충족합니다. 흔한 오해: 흔한 함정은 검색 시점 필터링(문서 또는 결과 제외)에 집중하는 것입니다. 검색에서 일부 항목을 제외하더라도, 모델은 다른 검색된 콘텐츠, 사용자 프롬프트 인젝션, 또는 모델 동작으로 인해 해당 문구를 여전히 생성할 수 있습니다. 또 다른 오해는 콘텐츠를 “우선순위 낮춤”(부스팅)하면 위험이 줄어든다는 것인데, 이는 비노출을 보장하지 않습니다. 시험 팁: “응답에 절대 나타나면 안 됨”과 “응답 시점에 강제”라는 문구가 보이면, 검색 튜닝/랭킹/재인덱싱이 아니라 차단 문구/용어 같은 출력 가드레일을 찾으십시오. 또한 “기존 인덱스를 수정하지 않고” 같은 제약은 재구축/재수집 솔루션을 배제합니다. 의료/컴플라이언스 시나리오에서는 확률적 관련성 튜닝보다 결정론적 제어(명시적 차단)를 선호하십시오.

문제 17

핀테크 스타트업의 데이터 사이언스 팀이 프라이빗 서브넷 내에서 6개의 ml.p3.8xlarge 인스턴스를 사용해 분산 Amazon SageMaker training job을 실행하려고 합니다. 또한 학습 실행 중 SageMaker 프로세스가 사용하는 전송 중 데이터(노드 간 트래픽 및 프레임워크 조정 메시지 포함)가 저장 시(at-rest) 암호화 설정을 변경하지 않고도 엔드 투 엔드로 암호화되도록 보장해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 Amazon SageMaker 분산 학습의 네트워크 보안—특히 저장 시(at-rest) 암호화를 수정하지 않고도 training cluster 내부에서 발생하는 트래픽(노드 간 통신, 조정/제어 메시지, 컨테이너 간 트래픽)의 전송 중(in transit) 암호화—를 테스트합니다. 정답이 맞는 이유: 여러 인스턴스(6개의 ml.p3.8xlarge)에서 분산 학습을 수행할 때 SageMaker는 그래디언트/파라미터 및 조정 메시지(예: MPI/NCCL/Horovod 또는 프레임워크별 collective)를 교환하는 training container cluster를 사용합니다. SageMaker의 inter-container traffic encryption을 활성화하면 cluster 내 training 인스턴스/컨테이너 간 모든 트래픽이 전송 중에 엔드 투 엔드로 암호화됩니다. 이는 학습 실행 중 노드 간 트래픽과 프레임워크 조정 메시지를 암호화해야 한다는 요구 사항을 직접 충족하며, 저장 시(at-rest) 암호화 설정을 변경하지 않고도 이를 달성합니다. 주요 AWS 기능: SageMaker training job은 “inter-container traffic encryption”(때로는 분산 training job에서 노드 간 통신을 암호화하는 것으로 설명됨)을 지원합니다. 이를 활성화하면 SageMaker가 job에 참여하는 인스턴스들 간 네트워크 트래픽이 암호화되도록 training cluster를 구성합니다. 이는 S3/EBS의 저장 시 암호화 또는 model artifact 암호화와는 별개로, 분산 학습 패브릭 내부의 전송 중 암호화에 관한 기능입니다. 프라이빗 서브넷에서 실행하는 것은 호환되며 종종 VPC-only 액세스와 함께 사용되지만, 프라이빗 서브넷만으로는 east-west 트래픽의 암호화를 보장하지 않습니다. 흔한 오해: 자주 빠지는 함정은 KMS key( training job 또는 Studio domain용)를 지정하면 “모든 것”이 암호화된다고 가정하는 것입니다. SageMaker에서 KMS key는 주로 저장 시(at-rest) 암호화(예: training 인스턴스에 연결된 EBS 볼륨, S3의 model artifact, 또는 Studio 스토리지)를 제어합니다. 이는 분산 학습 노드 간 런타임 네트워크 트래픽을 자동으로 암호화하지 않습니다. 또 다른 오해는 Batch Transform 설정을 training job과 혼동하는 것입니다. Batch Transform은 inference/배치 스코어링 기능이지 분산 학습이 아닙니다. 시험 팁: “inter-node traffic”, “framework coordination messages”, 또는 “cluster 내부 east-west traffic” 같은 요구 사항이 보이면, 분산 학습을 위한 전송 중 암호화( inter-container/inter-node traffic encryption)에 명시적으로 해당하는 기능을 찾으세요. 요구 사항에 “at-rest encryption을 변경하지 않고”가 포함되어 있다면, 문제가 스토리지 암호화에 관한 것이 아닌 한 KMS-only 답변은 제외하세요. 또한 training, Batch Transform, Studio domain 구성은 각각 보안 제어가 다르므로 구분해야 합니다.

문제 18

한 의료 분석 스타트업은 HIPAA에 부합하는 환경에서 비식별화된 환자 데이터를 분석하기 위해 Amazon SageMaker notebook instances를 사용하여 향후 14일 내에 8개의 AWS accounts 전반에 걸쳐 60명의 data scientists를 온보딩할 계획입니다. 보안 팀은 notebook instances가 AWS Management Console, AWS CLI/SDK, AWS Service Catalog, AWS CloudFormation 중 어떤 방식으로 시작되더라도 root access enabled 상태로는 절대 생성되어서는 안 되며, 사후에 비준수 리소스를 삭제하는 것이 아니라 이러한 생성을 사전에 차단하는 통제가 필요하다고 요구합니다. 모든 accounts 및 Regions에서 이를 강제할 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 IAM policy evaluation과 AWS Organizations Service Control Policies (SCPs)를 사용하여 Amazon SageMaker에 대한 사전 예방적 거버넌스 통제를 테스트합니다. 요구 사항은 (Console, CLI/SDK, Service Catalog, CloudFormation 등) 프로비저닝 경로와 무관하게 여러 accounts 및 Regions 전반에서 비준수 notebook instances(루트 액세스 활성화)의 생성을 사전에 차단하는 것입니다. 정답이 맞는 이유: SageMaker notebook instances는 RootAccess 파라미터(일반적으로 Enabled/Disabled로 표현됨)를 노출합니다. IAM은 서비스별 condition keys(예: sagemaker:RootAccess)를 지원하며, RootAccess가 Disabled가 아닐 때 CreateNotebookInstance 및 UpdateNotebookInstance에 대해 Deny statement로 사용할 수 있습니다. SCP를 통해 강제되는 explicit Deny는 member accounts의 모든 principals(관리자 포함)에 적용되며, 리소스가 어떤 방식으로 시작되든 모든 API call에 대해 평가됩니다. 이는 “절대 생성되면 안 됨”과 “사전 차단”을 충족하며, SCP는 조직 전체에 적용되고 IAM 평가는 요청 시점에 수행되므로 Regions 전반에서 일관되게 동작합니다. 주요 AWS 기능: 1) AWS Organizations SCPs: account 수준 IAM permissions로 우회할 수 없는 permissions guardrail을 설정합니다. 2) IAM condition keys: API를 호출할 수 있는 주체뿐 아니라 어떤 파라미터로 호출할 수 있는지까지 구성 수준 제약을 강제합니다. 3) 여러 프로비저닝 메커니즘 커버리지: Console, CloudFormation, Service Catalog는 궁극적으로 SageMaker APIs를 호출하므로 동일한 Deny가 적용됩니다. 4) Defense-in-depth: SCP를 identity policies와 함께 사용할 수 있지만, 핵심적인 cross-account 통제는 SCP입니다. 흔한 오해: Event-driven remediation(EventBridge/Lambda) 및 CloudFormation hooks는 “강제”처럼 보일 수 있지만, 이는 사후 대응이며 비준수 상태가 존재하는 시간 창을 허용하므로 여기서는 명시적으로 허용되지 않습니다. KMS encryption은 root access와 무관하며, 이는 at rest 데이터 보호를 제공할 뿐 notebook OS privilege 구성은 제어하지 않습니다. 시험 팁: “절대 생성되면 안 됨”과 “모든 accounts 전반”을 보면 사전 예방적 통제(SCPs, permission boundaries, condition keys를 포함한 explicit Deny)를 떠올리십시오. 사후 대응 통제(Config rules, EventBridge remediation, stack event cleanup)는 탐지 및 수정용이지 강력한 사전 예방용이 아닙니다. 또한 Service Catalog와 CloudFormation은 별도의 control plane이 아니라 기본 서비스 APIs를 호출하므로, IAM/SCP guardrails가 가장 보편적인 강제 지점임을 기억하십시오.

문제 19

온라인 교육 플랫폼은 단일 AWS 계정을 운영하며, 라벨링된 5 TB의 학습 데이터를 하나의 Amazon S3 bucket(s3://edu-ml-data)에 부서별 prefix(s3://edu-ml-data/math/, /physics/, /cs/, /biology/) 아래에 저장합니다. 50명의 ML engineer가 Amazon SageMaker에서 Studio notebook과 SageMaker training job을 사용해 모든 모델 학습을 수행하며, 각 engineer는 자신의 부서 prefix 아래의 데이터만 읽고 쓸 수 있어야 하고, interactive notebook과 training job 모두에서 다른 부서 데이터에 대한 접근은 차단되어야 합니다. 어떤 솔루션이 engineer에게 적절한 access control을 제공합니까?

문제 분석

핵심 개념: 이 문제는 ML workflow에서 데이터 보안을 위한 AWS identity and access management를 테스트합니다. 즉, IAM policy(및 SageMaker execution role)를 사용하여 Amazon S3 prefix에 대해 least-privilege access를 강제하는 것입니다. SageMaker에서는 Studio notebook과 training job 모두 IAM role(Studio의 user profile role 및 training job execution role)을 사용해 S3에 접근하므로, 해당 role을 제어하면 데이터 접근을 제어할 수 있습니다. 정답이 맞는 이유: Option D가 정답인 이유는 요구사항이 50명의 engineer에 대해 부서 prefix(math/, physics/, cs/, biology/) 단위로 세밀한 read/write 격리를 제공해야 하며, 이것이 interactive notebook과 training job에 일관되게 적용되어야 하기 때문입니다. 올바른 접근 방식은 s3:ListBucket을 prefix condition과 함께 허용하고, 특정 prefix ARN(예: arn:aws:s3:::edu-ml-data/math/*)에 대해서만 s3:GetObject/s3:PutObject(그리고 필요 시 s3:DeleteObject)를 허용하는 IAM policy를 만드는 것입니다. 그리고 이 policy를 실제로 사용되는 IAM principal에 연결해야 합니다. 즉, IAM user( SageMaker에서는 덜 일반적) 또는 best practice로 부서별(또는 사용자별) SageMaker execution role에 연결하여 Studio와 training job이 동일한 제한을 상속받도록 합니다. 주요 AWS 기능: S3 object ARN에 대한 resource-level permission과 s3:prefix(및 선택적으로 s3:delimiter)로 제한된 bucket-level ListBucket permission을 사용합니다. 부서별로 별도의 SageMaker execution role을 구현하고, Studio user profile을 적절한 role에 매핑합니다. 이는 AWS Well-Architected Security pillar의 least privilege, separation of duties, centralized policy management와 일치합니다. 선택적으로 explicit Deny statement를 추가하여 다른 prefix에 대한 접근을 방지하고, 확장 가능한 사용자 관리를 위해 permission boundary 또는 IAM Identity Center를 고려할 수 있습니다. 흔한 오해: Versioning과 Object Lock은 데이터 보존 및 불변성과 관련이 있으며, authorization과는 관련이 없습니다. CORS는 browser 기반 cross-origin request를 제어하는 것이지 SageMaker에 대한 IAM authorization을 제어하는 것이 아닙니다. 이러한 기능들은 “보안 관련”처럼 들릴 수 있지만, AWS service role에 대해 prefix별 접근을 강제하지는 못합니다. 시험 팁: “S3에서 이 folder/prefix만” 그리고 “SageMaker training job에서 동작해야 함”을 보면, SageMaker execution role에 연결된 S3 prefix 기반 IAM policy를 떠올리면 됩니다. 일반적으로 (1) prefix condition이 있는 bucket에 대한 s3:ListBucket과 (2) arn:aws:s3:::bucket/prefix/*에 대한 object action의 두 가지가 모두 필요하다는 점을 기억하세요.

문제 20

한 데이터 과학 팀이 이미지 태깅 기능을 위한 Amazon SageMaker 모델을 프로덕션에서 serverless inference endpoint(2 vCPU equivalent, 4 GiB memory)에 배포했으며, InvokeEndpoint API를 통해 호출하고 있습니다. endpoint가 10분 이상 유휴 상태로 있다가 호출되는 오프피크 기간 동안, 프로덕션의 p95 latency가 스테이징에서 측정된 120 ms 기준선에서 480–520 ms로 상승합니다. ML engineer는 추가 latency가 inference 로직이 아니라 모델 시작(cold start) 시간 때문이라고 의심합니다. 이 가설을 확인하거나 반박하기 위해 ML engineer는 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 단계를 기준으로 endpoint latency를 나누어 보여주는 기본 제공 Amazon CloudWatch metrics를 사용하여 Amazon SageMaker serverless inference endpoint의 latency 급증을 진단하는 것에 관한 것입니다. 유휴 상태 기간 이후에만 latency가 증가한다면, 가능한 원인은 모델의 inference logic보다는 cold-start overhead입니다. 정답인 이유: cold-start 가설을 확인하거나 반박하는 가장 좋은 방법은 model setup 및 initialization 시간을 구체적으로 측정하는 CloudWatch metric을 확인하는 것입니다. SageMaker endpoints의 경우, AWS/SageMaker namespace의 ModelSetupTime은 inference가 시작되기 전에 model container를 준비하고 model을 로드하는 데 소요된 시간을 캡처합니다. 유휴 기간 이후 첫 번째 invocation에서 p95 latency 급증과 일치하는 높은 ModelSetupTime이 나타난다면 cold-start 설명을 뒷받침하며, 그렇지 않다면 latency는 inference 실행 또는 다른 downstream 요인에서 발생할 가능성이 높습니다. 주요 AWS 기능: SageMaker는 endpoint metrics를 AWS/SageMaker namespace의 Amazon CloudWatch에 게시하므로, application code를 수정하지 않고도 latency 관련 metrics를 분석할 수 있습니다. ModelSetupTime과 같은 metrics는 initialization overhead를 steady-state inference 동작과 분리하는 데 도움이 되며, 이는 특히 유휴 기간 동안 scale-down이 cold starts로 이어질 수 있는 serverless inference에서 유용합니다. 따라서 CloudWatch는 production에서 startup 관련 latency 문제를 검증하기 위한 기본 운영 도구입니다. 일반적인 오해: SageMaker Model Monitor는 request-path latency 또는 cold starts를 진단하기 위한 것이 아니라 data quality, model quality, bias, drift를 모니터링하기 위해 설계되었습니다. 또 다른 흔한 실수는 setup 시간을 직접 측정하는 metric 대신 일반적인 waiting 또는 queueing metrics에 집중하는 것입니다. 이 시나리오에서 문제는 startup overhead를 어떻게 검증할지 구체적으로 묻고 있으므로, setup metric이 가장 관련성이 높습니다. 시험 팁: endpoint가 지속적인 load에서는 빠르지만 유휴 상태 이후에는 더 느리다면, cold starts를 떠올리고 CloudWatch에서 setup 또는 initialization metrics를 확인하세요. AWS 시험에서는 model quality를 위한 governance 또는 monitoring 기능보다, 의심되는 bottleneck을 직접 측정하는 서비스 고유의 운영 metric을 우선 선택하세요. 또한 SageMaker endpoint performance metrics는 AWS/SageMaker namespace의 CloudWatch를 통해 사용할 수 있다는 점도 기억하세요.