모든 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
문제 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의 예측에 대한 설명을 제공할 솔루션은 무엇인가?
SageMaker Model Monitor는 배포된 모델의 지속적인 모니터링을 위한 것이다. 즉, inference 데이터 캡처, 데이터/feature drift 탐지, 데이터 품질 제약 모니터링, (추가 설정 시) bias 및 explainability 리포트를 주로 배치/오프라인 맥락에서 제공한다. real-time inference 응답과 함께 각 요청별로 동기적인 feature attribution을 기본적으로 제공하지는 않는다. 이는 라이브 inference별 설명이 아니라 모델 운영 및 거버넌스를 다룬다.
SageMaker Clarify는 feature attribution(일반적으로 SHAP)을 통한 모델 explainability를 제공하며, explainer 구성을 추가하여 배포된 endpoint와 함께 사용할 수 있으므로 정답이다. 이를 통해 gradient-boosted tree와 같은 tabular 모델에 대해 모델 코드를 수정하지 않고도 inference별 설명을 제공할 수 있다. 이는 특정 거래가 실시간으로 왜 플래그되었는지 설명해야 한다는 요구사항을 직접 충족한다.
CloudWatch는 메트릭과 분포(latency, 오류율, 커스텀 메트릭, A/B 테스트 트래픽 분할)를 시각화할 수 있지만, feature attribution을 계산하거나 개별 예측을 설명하지는 않는다. 기껏해야 endpoint의 운영 동작을 관찰하는 데 도움이 된다. “amount가 사기 점수에 X만큼 기여했다”와 같은 컴플라이언스 수준의 inference별 설명을 생성할 수 없다.
shadow endpoint는 안전한 테스트(예: 트래픽을 미러링하여 후보 모델과 프로덕션을 비교)와 예측 차이 분석에 유용하다. 그러나 자체적으로 feature attribution을 생성하지는 않는다. inference별 설명을 계산하려면 여전히 explainability 방법/도구가 필요하다. 이 선택지는 배포 검증을 다루며 explainability 요구사항을 충족하지 않는다.
문제 분석
핵심 개념:
이 문제는 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를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
합격 후기(3)
S
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.
Cloud Pass를 다운로드하여 모든 AWS Certified Machine Learning Engineer - Associate (MLA-C01) 연습 문제를 무료로 이용하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
AWS Certified Machine Learning Engineer - Associate (MLA-C01) 무료 시험 문제 & 덤프 | Cloud Pass
2
문제 2
정유 공장 안전 시스템에서, ML engineer는 센서 스트림에서 메탄 누출을 탐지하는 binary classifier를 선택해야 한다. 실제 누출을 놓치는 경우(false negative)는 평균 사고 비용이 $120,000 발생하는 반면, false alarm은 $300의 현장 점검과 5분의 다운타임을 유발한다. 그렇다면 모델을 선택할 때 어떤 metric 결과를 가장 우선적으로 고려해야 하는가?
Low precision은 예측된 누출 중 많은 비율이 false alarm(즉, TP 대비 FP가 높음)임을 의미한다. 이 시나리오가 누출 미탐보다 false alarm을 더 잘 허용하긴 하지만, ‘low precision을 우선한다’를 목표로 삼는 것은 아니다. 이는 high recall을 달성하기 위해 받아들이는 가능한 trade-off일 뿐이다. 목표는 false negatives를 줄이는 것이지, 의도적으로 false positives를 늘리는 것이 아니다.
High precision은 모델이 누출을 예측할 때 대체로 맞도록 하여 false positives를 최소화하는 데 초점을 둔다. 이는 $300 점검과 다운타임을 줄이지만, 그 비용은 실제 누출을 놓쳤을 때의 평균 $120,000 비용에 비해 매우 작다. precision 최적화는 false negatives를 증가시킬 위험이 있어, 안전이 중요한 정유 공장 컨텍스트에서는 용납되기 어렵다.
Low recall은 모델이 많은 실제 누출을 놓친다(즉, false negatives가 높음)는 뜻이다. 이는 false negatives가 지배적인 비용($120,000 사고)을 갖는 이 비즈니스 요구와 정반대다. 누출이 드물다면 low recall 모델이 accuracy는 좋아 보일 수 있지만, 운영 및 경제 측면에서 이 환경에서는 위험하다.
High recall (sensitivity)은 false negatives를 최소화하여 실제 메탄 누출 탐지를 최대화한다. 누출을 놓쳤을 때의 평균 비용이 $120,000이므로, 모델 선택에서는 recall을 우선해야 하며, 그로 인해 false positives가 증가해 더 많은 $300 점검과 짧은 다운타임이 발생하더라도 감수하는 것이 타당하다. 실무에서는 decision threshold를 조정해 recall을 더 높이고, confusion matrix와 PR curve로 검증한다.
문제 분석
핵심 개념:
이 문제는 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
문제 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를 복제하거나 마이그레이션하지 않도록 하는 것입니다. 회사는 어떤 솔루션을 구현해야 합니까?
ECR cross-account replication은 image를 다른 registry/region/account로 복사합니다. 이는 container image를 복제하거나 마이그레이션하지 말라는 요구사항을 위반합니다. 또한 approval state, lineage metadata, 또는 모델 등록 결정에 대한 중앙화된 audit trail을 갖춘 governance catalog를 생성하지 않습니다. replication은 배포(distribution)를 해결할 뿐, 모델 lifecycle 거버넌스를 해결하지 않습니다.
producer account에서 governance account로 replication을 구성한 중앙 ECR 리포지토리는 image를 governance account로 명시적으로 복제하므로, 문제에서 금지한 사항입니다. 저장소를 중앙화하더라도 ECR만으로는(태그를 넘어서는) 모델 버전 거버넌스, approval workflow(Approved/Pending/Rejected), 모델 lineage metadata에 대한 네이티브 구성이 부족합니다. registry를 근사하려면 추가 서비스가 필요합니다.
SageMaker Model Registry는 approval status와 풍부한 metadata를 갖춘 중앙화된 versioned model catalog를 제공합니다. account-local ECR에 저장된 container image를 image URI로 참조할 수 있어 image 복제를 피할 수 있습니다. SageMaker resource policy와 IAM assume-role 패턴으로 cross-account 등록 및 discovery를 활성화할 수 있으며, CloudTrail이 컴플라이언스를 위한 audit log를 제공합니다.
AWS Glue Data Catalog는 crawler를 통한 discovery를 포함해 데이터셋(table, schema, partition)을 위해 설계되었지, container image 및 ML 모델 거버넌스를 위한 것이 아닙니다. ECR을 crawling하는 것은 표준 Glue 패턴이 아니며, Glue는 SageMaker Model Registry처럼 model approval workflow, model package versioning 의미론, 또는 MLOps lineage/audit 요구사항을 네이티브로 지원하지 않습니다.
문제 분석
핵심 개념:
이 문제는 아티팩트를 이동하지 않으면서 여러 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
문제 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를 향상시키는 솔루션을 구현해야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?
model package에 tag를 지정하면 domain metadata를 추가할 수는 있지만, 문제에서 설명하는 방식으로 기존 자산을 대규모로 구성하는 데에는 가장 적합하지 않습니다. 1,200개가 넘는 model package version에 tag를 적용하면 상당한 운영 오버헤드가 발생하고, 새 version이 추가될 때마다 지속적인 유지 관리가 필요합니다. 또한 tag는 model group을 domain별로 명확하게 구조화해서 그룹화하는 대신 metadata를 통해 개별 리소스를 구성합니다. 요구 사항은 현재 group membership을 변경하지 않고 discoverability를 향상시키는 것이므로, collection이 더 직접적이고 확장 가능한 기본 기능입니다.
새로운 model group을 생성하고 기존 model을 그 안으로 이동하는 것은 현재 model group membership을 수정하지 말라는 명시적 요구 사항을 위반합니다. model package version은 해당 model group과 연결되어 있으므로, 이를 이동하면 기존 구성 구조가 변경되고 downstream process를 방해할 수 있습니다. 또한 많은 수의 model에 대해 불필요한 migration 작업과 위험을 초래합니다. 따라서 이 선택지는 명시된 제약 조건을 분명히 충족하지 못합니다.
SageMaker ML Lineage Tracking은 traceability와 reproducibility를 위해 dataset, job, model, deployment 간의 관계를 캡처하는 데 사용됩니다. 이는 pricing optimization, search relevance, fraud detection과 같은 business domain을 자동으로 결정하지 않으며, Model Registry 자산을 위한 domain 기반 organizational layer 역할도 하지 않습니다. lineage metadata가 존재하더라도, discoverability를 위해 model group을 그룹화하는 명시적인 메커니즘을 대체할 수는 없습니다. 따라서 이 선택지는 요구 사항을 충족하지 못합니다.
각 business domain에 대해 Model Registry collection을 생성하는 것이 최선의 솔루션입니다. collection은 기존 Model Registry 자산을 더 높은 수준에서 구성하고 discoverability를 향상시키도록 설계되었기 때문입니다. 이 접근 방식은 engineer가 model package version을 이동하거나 기존 model group 자체를 변경하지 않고도 현재 model group을 domain 기반 collection에 배치할 수 있게 합니다. 또한 요구 사항대로 model artifact, approval status 및 현재 membership을 정확히 그대로 유지합니다. 95개의 model group과 1,200개 이상의 model package version에 대해서도 깔끔하게 확장되므로, 운영 측면에서 가장 효율적이고 목적에 가장 부합하는 선택지입니다.
문제 분석
핵심 개념: 이 문제는 model artifact, model package version, approval status 또는 기존 model group membership을 수정하지 않고 business domain별로 기존 SageMaker Model Registry 자산을 대규모로 구성하는 가장 좋은 방법을 묻고 있습니다. 정답인 이유: SageMaker Model Registry collection은 기존 model group을 pricing optimization, search relevance, fraud detection과 같은 domain 기반 버킷으로 그룹화할 수 있는 상위 수준의 구성 구조를 제공합니다. 주요 기능: collection은 많은 model group 전반에서 discoverability를 향상시키고, model package version을 이동할 필요가 없으며, 현재 registry 구조를 유지합니다. 흔한 오해: tag는 metadata 및 filtering에 도움이 될 수 있지만, 여기서는 가장 목적에 맞는 메커니즘이 아닙니다. 요구 사항은 현재 group membership을 변경하지 않고 기존 자산을 domain별로 구성하는 것이며, 문제는 특히 모든 package version에 tag를 지정하는 것보다 model group을 그룹화하는 방향을 가리키고 있기 때문입니다. 시험 팁: AWS가 version을 재구성하거나 수정하지 않고 기존 registry 자산을 확장 가능하게 구성하는 방법을 물을 때는, 수동 tagging이나 migration보다 collection과 같은 기본 제공 organizational construct를 우선 고려하십시오.
5
문제 5
스마트 농업 스타트업은 과수원 열의 4K 드론 이미지(3840x2160)가 주어졌을 때, 각 익은 과일을 자동으로 찾아 각 탐지 결과마다 클래스 레이블과 바운딩 박스 좌표(x_min, y_min, x_max, y_max)를 신뢰도 >= 0.85인 경우에만 반환하는 ML 모델을 Amazon SageMaker에서 구축해야 합니다. 어떤 SageMaker 알고리즘을 사용해야 합니까?
Image classification은 전체 이미지에 대해 하나의 레이블(또는 레이블에 대한 확률 분포)을 예측합니다. 객체를 위치 추정하거나 바운딩 박스 좌표를 출력하지 않습니다. “이 이미지에 익은 과일이 있나요?” 같은 질문에는 답할 수 있지만, 각 과일 인스턴스에 대해 (x_min, y_min, x_max, y_max)를 반환할 수 없습니다. 따라서 위치 추정 및 다중 인스턴스 탐지 요구사항을 충족하지 못합니다.
SageMaker의 XGBoost는 주로 특성 공학이 적용된 표 형식 데이터에 대해 분류/회귀에 사용되는 gradient-boosted decision tree 알고리즘입니다. 원시 4K 이미지를 직접 처리하여 바운딩 박스를 생성하지는 못합니다. 이론적으로 다른 곳에서 이미지 특징을 추출해 별도 모델을 학습할 수는 있지만, 이는 객체 위치 추정 요구사항을 직접 충족하지 못하며 이 사용 사례에서 의도된 SageMaker 알고리즘도 아닙니다.
Object detection은 이미지 내 객체를 분류(classify)하고 위치를 추정(localize)하도록 명시적으로 설계되어, 탐지된 각 인스턴스별로 바운딩 박스와 신뢰도 점수를 생성합니다. 이는 드론 이미지에서 각 익은 과일을 찾아 클래스 레이블과 (x_min, y_min, x_max, y_max) 좌표를 반환한 뒤 신뢰도 >= 0.85로 결과를 필터링해야 하는 요구사항과 일치합니다. SageMaker의 내장 Object Detection(SSD 기반)이 적절한 선택입니다.
k-NN은 벡터/표 형식 데이터에 대한 분류 또는 회귀에 사용되는 단순한 instance-based 알고리즘입니다. 컴퓨터 비전 위치 추정 모델이 아니며 원시 이미지에서 바운딩 박스를 출력하지 않습니다. 임베딩을 사용하더라도 k-NN은 보통 가장 가까운 레이블을 반환할 뿐, 여러 객체에 대한 공간 좌표를 반환하지 않습니다. 요구되는 탐지 출력 형식과 맞지 않습니다.
문제 분석
핵심 개념:
이 문제는 컴퓨터 비전 문제에 대해 올바른 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
문제 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를 변경하지 않고 새로운 노출에 대한 일반화를 개선하려면 엔지니어는 무엇을 해야 합니까?
learning rate(eta)를 올리면 각 boosting step이 더 커져 보통 학습 데이터를 더 빠르게 맞추는 데 도움이 되며, 일반화를 개선하는 방향은 아닙니다. 모델이 이미 매우 높은 학습 AUC/precision을 달성하는 상황에서는 eta를 높이면 overfitting이 증가하고 validation 성능이 떨어질 수 있습니다. XGBoost에서 일반화를 개선하려면 보통 eta를 낮추고(그리고 round 수를 늘리는) 방향을 사용합니다.
관련 없는 feature를 제거하면 overfitting을 줄일 수 있지만, 이는 feature space를 변경하는 것이며 문제에서 명시적으로 금지하고 있습니다. 또한 설명된 overfitting은 몇 개의 불필요한 feature 때문이라기보다(깊은 tree가 sparse one-hot 패턴을 외우는) 과도한 모델 용량과 더 일치합니다. 시험 관점에서 이 선택지는 hyperparameter만으로 해결하는 조치가 아니라 feature-engineering/데이터 준비 작업입니다.
max_depth를 늘리면 tree 복잡도가 증가하여 모델이 학습 데이터를 외우는 능력이 커집니다. max_depth가 이미 10이고 학습 지표가 거의 완벽한 상황에서 더 깊은 tree는 일반화 격차를 거의 확실히 악화시킵니다. 이는 홀드아웃된 1주 및 신규 노출에서 AUC와 precision이 급락하는 상황에서 원하는 방향과 정반대입니다.
max_depth를 낮추면 각 tree가 만들 수 있는 split 수를 제한하여 모델 용량을 줄입니다. 이는 boosted tree에서의 overfitting을 직접적으로 완화하며, 특히 매우 구체적인 규칙을 만들 수 있는 high-cardinality one-hot feature가 있을 때 효과적입니다. 더 얕은 tree는 주(week)가 바뀌거나 신규 노출이 들어와도 더 잘 전이되는 일반적인 패턴을 학습하는 경향이 있어, 알고리즘이나 feature set을 바꾸지 않고도 validation AUC/precision을 개선합니다.
문제 분석
핵심 개념:
이 문제는 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
문제 7
미디어 모니터링 팀이 주당 다국어 팟캐스트 오디오(MP3) 900시간, 주당 컨퍼런스 녹화(MP4 비디오) 300시간, 블로그 게시물 35,000개를 수집하며, 이 중 이탈리아어 항목에 대해서만 24시간 이내에 독일어 요약을 제공해야 합니다. 또한 엔지니어링 노력을 최소화하고 어떤 모델 학습도 피해야 합니다. 어떤 솔루션이 가장 짧은 시간 내에 요구 사항을 충족하나요?
오답입니다. 이 접근 방식은 전사를 위해 SageMaker에서 커스텀 모델을 학습 및 배포하고, 이후 요약을 위해 LLM을 학습/배포해야 합니다. 이는 모델 학습을 피하라는 요구 사항을 직접 위반하며, 엔지니어링 노력과 제공까지의 시간을 크게 증가시킵니다(데이터 라벨링, 모델 선택, 튜닝, 호스팅, MLOps). SageMaker는 커스텀 모델이나 완전한 제어가 필요할 때 적합하며, 가장 빠른 관리형 요약을 위한 선택은 아닙니다.
Option B는 audio 및 video source에 대해 Amazon Transcribe batch를 사용하므로 가장 적절한 정답입니다. 이는 MP3 및 MP4 파일의 spoken content를 text로 변환하는 데 적합한 managed AWS service입니다. 또한 Anthropic Claude가 포함된 Amazon Bedrock을 사용하므로, 어떤 model training이나 infrastructure management 없이 German summaries를 생성해야 한다는 요구 사항도 충족합니다. Italian transcripts를 German summaries 생성 전에 English로 번역하는 것은 불필요하지만, 전체 architecture는 여전히 다른 선택지들보다 요구 사항에 더 잘 부합합니다. 주요 약점은 blog posts 처리에 대해 명시적으로 언급하지 않는다는 점이지만, 제공된 선택지들 중에서는 여전히 가장 가까운 해답입니다.
오답입니다. Amazon Rekognition은 이미지와 비디오에서 라벨, 얼굴, 이미지 내 텍스트, 모더레이션 등을 분석하는 서비스이며, 오디오 트랙에서 speech-to-text 전사를 수행하는 서비스가 아닙니다. 따라서 팟캐스트와 컨퍼런스 녹화에 대해 “미디어를 영어 텍스트로 변환”을 신뢰성 있게 수행할 수 없습니다. Bedrock + Claude는 요약에 적합하더라도, 수집/전사 구성요소가 잘못되어 파이프라인이 성립하지 않습니다.
오답입니다. Amazon Comprehend는 텍스트에 대한 NLP(엔터티, 핵심 구문, 감성, 분류)를 수행하지만 오디오/비디오를 텍스트로 전사하지 못하므로 MP3/MP4 입력을 처리할 수 없습니다. 또한 Stable Diffusion은 이미지 생성 모델이지 텍스트 요약 모델이 아니므로 텍스트로부터 독일어 요약을 생성할 수 없습니다. 이 옵션은 작업에 대한 서비스 매핑이 맞지 않아 핵심 요구 사항을 충족하지 못합니다.
문제 분석
핵심 개념:
이 문제는 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
문제 8
온라인 마켓플레이스의 한 ML engineer가 200,000건의 과거 거래 데이터를 사용하여 중고 스마트폰의 재판매 가격(USD)을 예측하는 모델을 구축하고 있습니다. 여기서 타깃은 $50에서 $1,500까지 범위의 연속값이며, 이해관계자들은 동일한 단위(USD)로 평균 절대 예측 오차를 보고하는 평가 지표를 요구합니다. 모델의 성능을 평가하기 위해 어떤 지표를 사용해야 합니까?
Accuracy는 정답 예측의 비율을 측정하며, 주로 이산 레이블(예: 스팸/정상)을 갖는 분류 문제에 사용됩니다. 스마트폰 재판매 가격처럼 연속 타깃의 경우, 가격을 인위적으로 구간화하지 않는 한 “정답”의 자연스러운 개념이 없습니다. 또한 Accuracy는 USD 단위의 오차를 보고하지 않으므로 이해관계자 요구사항을 충족하지 못합니다.
Area Under the ROC Curve (AUC)는 이진 분류기가 모든 임계값에서 양성 예제를 음성 예제보다 높게 순위화하는 능력을 평가합니다. 회귀를 위해 설계된 지표가 아니며, 타깃과 동일한 단위로 오차 크기를 출력하지도 않습니다. 설령 문제를 분류(예: 특정 가격 이상/이하)로 변환하더라도, AUC는 순위 품질을 측정할 뿐 평균 절대 달러 오차를 측정하지 않습니다.
F1 score는 분류 작업에서 precision과 recall의 조화 평균이며, 특히 클래스 불균형이 있을 때 유용합니다. 이산 클래스 레이블과 결정 임계값이 필요하지만, 연속 재판매 가격 예측에는 자연스럽게 존재하지 않습니다. F1은 USD 단위의 오차를 제공하지 않으며, 문제를 범주(예: 저/중/고 가격)로 재구성한 경우에만 적용되는데, 문제에서는 이를 시사하지 않습니다.
Mean Absolute Error (MAE)는 예측값과 실제값의 평균 절대 차이를 계산하는 표준 회귀 지표입니다. 절대 차이를 사용하므로 MAE는 타깃 변수(USD)와 동일한 단위로 표현되어 “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
문제 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 CloudWatch는 인프라 및 애플리케이션 observability(CPU, memory, network, log, alarm)에 초점을 둡니다. SageMaker training job의 리소스 사용량을 모니터링하고 성능 병목을 트러블슈팅하는 데는 유용하지만, 보호 대상 그룹 간 demographic parity difference 같은 fairness 또는 bias metric을 계산하지는 않습니다. CloudWatch는 의도된 목적을 벗어난 상당한 custom 구현 없이는 학습 데이터 분포를 분석하거나 sensitive attribute별 prediction outcome을 비교할 수 없습니다.
AWS Glue DataBrew는 시각적 데이터 준비 서비스로, 데이터를 프로파일링하고 recipe를 통해 변환을 적용할 수 있습니다. 데이터 정리, 결측값 처리, 요약 통계 생성에 도움이 되어 이후 bias 완화 노력에 기여할 수 있습니다. 그러나 DataBrew는 학습 데이터와 batch prediction에 대한 공식적인 bias/fairness metric(예: demographic parity difference)을 기본 제공하지 않으며, SageMaker Clarify처럼 ML 거버넌스를 위한 표준화된 bias report를 생성하지도 않습니다.
Amazon SageMaker Clarify는 ML 워크플로에서 bias를 탐지하고 explainability를 제공하도록 설계되었습니다. Clarify는 dataset에서의 학습 전 bias(예: age group 간 label 불균형)와 batch inference의 prediction에서의 학습 후 bias를 평가할 수 있으며, demographic parity 및 관련 group fairness measure 같은 metric을 계산합니다. Clarify는 S3에 저장되는 report를 생성하고 SageMaker pipeline/Studio와 통합되어, 보호 대상 그룹 전반의 skew를 탐지하고 정량화해야 한다는 요구사항을 충족합니다.
AWS Lambda는 preprocessing 단계(검증, 정규화, feature engineering 트리거)를 자동화하고 일관된 입력 품질을 강제할 수 있지만, 보호 대상 그룹 전반의 bias 탐지 또는 fairness metric 계산을 위한 내장 기능은 제공하지 않습니다. Lambda에서 demographic parity difference 계산을 구현하려면 custom code, 신중한 통계적 정의, 거버넌스 artifact가 필요합니다. 이 문제는 이러한 수준의 분석을 직접 제공하는 솔루션을 묻고 있으며, 이는 SageMaker Clarify에 해당합니다.
문제 분석
핵심 개념:
이 문제는 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
문제 10
비디오 스트리밍 플랫폼이 Amazon SageMaker real-time endpoint에서 실시간 콘텐츠 모더레이션 모델을 실행하고 있으며, 분당 약 1,500개의 요청을 처리하고 p95 latency SLO는 120 ms입니다.
더 큰 다국어 데이터셋으로 학습된 새 모델 버전이 준비되었고, 팀은 24시간 동안 동일한 라이브 프로덕션 요청을 사용해 정확도와 latency를 평가하면서 오프라인 비교를 위해 해당 추론 결과를 저장해야 합니다. 또한 어떤 프로덕션 사용자 의사결정이나 latency에도 영향을 주면 안 됩니다.
어떤 솔루션이 이러한 요구 사항을 충족하나요?
SageMaker Debugger는 주로 학습 중(그리고 제한적으로는 추론 모니터링에서) tensors/metrics를 수집하고 overfitting 또는 vanishing gradients 같은 문제를 감지하기 위해 rules를 적용하는 데 도움을 줍니다. 라이브 프로덕션 추론 요청을 별도의 모델 버전으로 미러링하여 출력 결과를 나란히 비교하도록 설계된 기능이 아닙니다. 또한 프로덕션 의사결정에 대한 영향이 0임을 본질적으로 보장하거나, 여기서 요구하는 shadow-evaluation 워크플로를 제공하지도 않습니다.
all-at-once traffic shifting을 사용하는 blue/green은 프로덕션 트래픽의 100%를 즉시 새 모델로 전환합니다. 이는 프로덕션 사용자 의사결정에 직접 영향을 주며, 새 모델이 더 느릴 경우 latency SLO를 위반할 위험이 있습니다. 또한 기존 모델이 유일한 의사결정자로 남아 있는 상태에서 24시간 동안 통제된 평가 기간을 제공하지 못합니다. 이는 배포 전략이지, 무영향 평가 방법이 아닙니다.
canary shifting(예: 24시간 동안 10%)은 점진적 롤아웃과 모니터링에 유용하지만, 실제 사용자 일부가 새 모델의 응답을 받게 됩니다. 이는 프로덕션 사용자 의사결정에 영향을 주지 말아야 한다는 요구 사항을 위반합니다. 또한 작은 비율이라도 사용자에게 보이는 latency 또는 품질 변화를 유발할 수 있습니다. canary는 통제된 릴리스용이지 shadow 평가용이 아닙니다.
shadow variant를 사용하는 shadow testing은 동일한 라이브 프로덕션 요청을 새 모델로 미러링하면서도, 애플리케이션에 반환되는 출력은 프로덕션 variant의 응답만 유지합니다. 이를 통해 24시간 동안 실제 환경에서의 latency와 출력 품질을 정확히 측정할 수 있으며, shadow 출력은(예: SageMaker Data Capture로 S3에 저장) 오프라인 비교를 위해 저장할 수 있습니다. 이 모든 과정에서 사용자 의사결정이나 프로덕션 응답 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
문제 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와의 모델 공유는 동일한 SageMaker domain 내에서 Studio/Canvas 사용자가 해당 domain의 role 및 설정에 의해 거버넌스되는 공유 리소스에 액세스하도록 설계되었습니다. 서로 다른 domain은 일반적으로 별도의 user profile, role, 리소스 경계를 의미하므로 공유를 더 어렵게 만들 뿐, 요구 사항이 아닙니다. 문제에서 명시적으로 동일한 domain이라고 했습니다.
정답. Canvas는 궁극적으로 S3에 저장된 모델 아티팩트에 액세스해야 합니다. SSE-S3 암호화(S3에서 관리)인 경우에도, Canvas 사용자의 execution role은 IAM/bucket policy에 의해 객체를 읽을 수 있도록(s3:GetObject) 권한이 부여되어야 하며, 종종 prefix를 나열하기 위한(s3:ListBucket) 권한도 필요합니다. S3 읽기 권한이 없으면, 모델이 등록되어 있더라도 가져오기/사용이 불가능합니다.
정답. SageMaker/Canvas 외부에서 빌드된 모델이 Canvas에서 검색 가능(discoverable)하려면, SageMaker Model Registry에 model package/version으로 등록되어야 합니다. Registry는 Studio/Canvas가 탐색할 수 있는 거버넌스된 모델 카탈로그(버전, 메타데이터, 승인)를 제공합니다. Canvas를 임의의 S3 URI로만 지정하는 것은 “비즈니스 분석가가 검색 가능” 요구 사항을 충족하지 못합니다.
오답. AWS Marketplace는 상업적 조건 하에 외부 고객/계정에 제품(ML 모델 포함)을 배포하기 위한 것입니다. 동일한 SageMaker domain 내 사용자 간 내부 공유에는 사용되지 않습니다. Marketplace 게시에는 Canvas 검색과 무관한 불필요한 패키징, 법적, 과금 구성이 추가됩니다.
오답. SageMaker real-time endpoint에 배포하는 것은 Canvas와 모델을 공유하기 위한 전제 조건이 아닙니다. Canvas는 관리형 워크플로와 거버넌스된 모델 아티팩트를 통해 모델을 평가하고 작업할 수 있으며, 호스팅은 별도의 라이프사이클 단계입니다. endpoint는 실시간 추론에 관련되며, 노코드 평가/튜닝을 위해 모델을 검색 가능하게 만드는 것과는 무관합니다.
문제 분석
핵심 개념:
이 문제는 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
한 방사선 영상 분석 스타트업은 현재 독자적인 12 TB DICOM 데이터와 도메인 특화 전처리를 사용하며, 커스텀 TensorFlow 2.12 Python 3.10 스크립트로 프라이빗 서버에서 이미지 세그멘테이션 모델을 학습하고 서빙하고 있습니다. 이 스타트업은 기존 코드를 보존하면서 2주 이내에 학습과 추론을 모두 AWS로 마이그레이션해야 하며, 단일 GPU 인스턴스(예: 1×V100이 있는 ml.p3.2xlarge)에서 실행해야 합니다. 최소한의 노력으로 이를 달성할 수 있는 접근 방식은 무엇입니까?
SageMaker built-in algorithms는 사용 사례가 제공되는 알고리즘과 입력 포맷에 맞을 때 ML 엔지니어링 노력을 줄일 수 있습니다. 그러나 기존 TensorFlow 스크립트를 “실행”하지는 않습니다. 독자적인 DICOM 전처리와 커스텀 세그멘테이션 파이프라인을 built-in algorithm 워크플로로 옮기려면 보통 상당한 리팩터링과 데이터 변환이 필요하며, 이는 기존 코드를 보존하고 2주 내에 빠르게 이동해야 한다는 요구사항과 충돌합니다.
사전 구축된 TensorFlow containers를 사용하는 SageMaker Script Mode는 최소한의 변경으로 기존 TensorFlow 학습 및 추론 코드를 실행하도록 설계되었습니다. 사용자는 Python 스크립트를 제공하고, SageMaker는 관리형 인프라, GPU 지원 framework container, S3에서의 data channel 마운트, 모델 아티팩트 처리를 제공합니다. 이는 가장 빠른 마이그레이션, TF 2.12/Python 3.10 코드 보존, ml.p3.2xlarge 같은 단일 GPU 인스턴스 지원이라는 제약을 가장 잘 만족합니다.
Bring-your-own-container(BYOC)는 최대 유연성(커스텀 OS 패키지, 특수 의존성, 미지원 framework 버전)을 제공합니다. 하지만 Docker image를 빌드, 테스트, 보안 강화, 유지관리해야 하고, GPU를 위해 CUDA/cuDNN 호환성도 보장해야 합니다. 2주 마감과 TensorFlow 같은 메인스트림 framework를 고려하면, BYOC는 보통 SageMaker의 사전 구축 TensorFlow DLC + Script Mode보다 불필요하게 더 많은 노력이 듭니다.
AWS Marketplace 모델은 프로토타이핑을 가속할 수 있지만, 특화된 방사선 영상 세그멘테이션 요구사항과 일치하는 경우가 드물고 스타트업의 독자적 학습 코드와 전처리를 보존하지 못합니다. 서드파티 모델을 독자적인 DICOM 파이프라인과 도메인 특화 라벨링에 맞게 적용하는 데는 상당한 노력이 들고 라이선스/컴플라이언스 우려도 생깁니다. 또한 최소 변경으로 기존 학습 및 추론 스크립트를 마이그레이션해야 한다는 요구사항을 직접적으로 충족하지 못합니다.
문제 분석
핵심 개념:
이 문제는 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
문제 13
한 피트니스 앱 회사는 가속 인스턴스 타입(g5.xlarge)의 8개 Reserved Instances를 사용하여 Amazon SageMaker real-time endpoint에서 추천 모델의 현재 버전을 제공하고 있으며, 배포 프로세스 전용으로 동일한 타입의 Reserved Instance가 정확히 1개 추가로 제공됩니다. 전환 과정 동안 솔루션은 다운타임이나 서비스 중단 없이 기존 8개 인스턴스를 재사용하여 이전 모델 버전과 새 모델 버전을 모두 호스팅해야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?
all-at-once traffic shifting을 사용하는 blue/green은 traffic의 100%를 cut over하기 전에 새로운 green environment가 완전히 provisioning되어 준비되어 있어야 합니다. 현재 8개 instance에서 실행 중인 endpoint의 경우, 이는 사실상 전환 전에 replacement fleet을 구성할 수 있을 만큼의 추가 capacity가 필요하다는 뜻입니다. 하지만 추가로 사용 가능한 instance는 1개뿐이므로, all-at-once cutover를 위한 전체 green fleet을 준비할 capacity가 충분하지 않습니다. 따라서 이 선택지는 제시된 capacity 제약을 충족하지 못합니다.
canary traffic shifting과 크기 10%를 사용하는 blue/green deployment가 가장 적합합니다. 8-instance endpoint의 10%는 instance 1개에 해당하므로, 정확히 추가로 사용 가능한 Reserved Instance 1개와 일치하기 때문입니다. SageMaker는 new model용으로 instance 1개를 가진 green fleet을 시작하고, 소량의 traffic을 보내 health와 performance를 검증한 다음, capacity를 전환하면서 기존 8개 instance를 재사용해 deployment를 계속할 수 있습니다. 이 접근 방식은 blue fleet이 green environment를 검증하는 동안 계속 production traffic을 처리하므로 zero downtime을 유지합니다. 또한 전체 병렬 fleet을 요구하지 않고, 전환 중 기존 8개 instance를 재사용해야 한다는 요구 사항에도 직접 부합합니다.
shadow test는 production request의 일정 비율을 shadow variant로 미러링하지만, shadow response는 사용자에게 반환되지 않으며 deployment는 production cutover보다는 검증을 목적으로 합니다. 또한 shadow model을 병렬로 실행하기 위한 별도의 capacity가 여전히 필요하고, 그 자체로 production model version의 제어된 교체를 수행하지는 않습니다. 문제는 단순한 test mechanism이 아니라 zero downtime으로 version을 전환하는 deployment strategy를 묻고 있습니다. 따라서 shadow testing은 전체 deployment 요구 사항을 충족하지 못합니다.
rolling deployment는 endpoint instance를 batch 단위로 업데이트하여 시간이 지나면서 old instance를 new instance로 교체하지만, 기존 8개 instance와 정확히 추가 1개 instance를 사용해 전환 중 old model version과 new model version을 모두 호스팅해야 한다는 요구 사항에는 가장 잘 맞지 않습니다. 문제는 전환 중 version의 traffic-safe coexistence를 구체적으로 강조하고 있으며, 이는 blue/green canary가 설계된 목적입니다. rolling deployment는 점진적인 in-place replacement에 더 가깝고, 8개 중 추가 instance 1개가 암시하는 명시적인 10% extra-capacity 패턴에도 그렇게 깔끔하게 대응하지 않습니다. 이런 이유로 rolling batch size 1은 blue/green canary보다 덜 적절합니다.
문제 분석
핵심 개념: 이 문제는 Amazon SageMaker endpoint deployment guardrail과 model update 중 deployment strategy가 capacity를 어떻게 소비하는지를 테스트합니다. 핵심 요구 사항은 production에 기존 g5.xlarge instance 8개를 사용하면서 deployment를 위해 정확히 추가 instance 1개만 사용하여 zero downtime을 달성하는 것이며, 전환 중에는 기존 8개를 재사용해 old version과 new version을 모두 호스팅해야 합니다. SageMaker의 blue/green deployment는 canary traffic shifting으로 구성할 수 있으므로, 먼저 작은 green fleet만 생성할 수 있어 capacity가 제한된 rollout에 적합합니다. 흔한 오해는 spare capacity가 제한될 때 rolling deployment가 항상 최선의 선택이라는 것이지만, rolling update는 여기서 설명된 방식처럼 old endpoint fleet과 new endpoint fleet을 나란히 실행하기보다는 instance를 batch 단위로 교체합니다. 시험 팁: 문제에서 traffic shifting percentage와 안전한 cutover를 위한 소량의 추가 capacity를 명시적으로 언급하면 rolling이나 shadow보다는 blue/green canary를 떠올리세요.
14
문제 14
미디어 분석 팀이 4시간마다 job queue에서 AWS Batch array 전처리 job을 실행하고 때때로 수동으로도 실행합니다. 이 팀은 데이터 처리 단계에서 해당 job들의 S3 출력물을 소비할 Amazon SageMaker Pipelines를 구축하고 있으며, state machine이나 장시간 실행되는 서비스를 도입하지 않으면서 job이 성공한 후 2분 이내에 pipeline이 시작되어야 합니다. 운영 오버헤드가 가장 적으면서 AWS Batch job을 pipeline과 통합하는 접근 방식은 무엇입니까?
Step Functions는 명시적 제어 흐름( job 제출, 대기, 그다음 pipeline 시작)으로 AWS Batch와 SageMaker Pipelines를 오케스트레이션할 수 있습니다. 그러나 문제에서 state machine을 도입하지 말라고 명시하므로, 유효한 아키텍처일 수 있어도 Step Functions는 제외됩니다. 또한 워크플로 정의, 상태 관리, 그리고 이벤트 기반 트리거보다 더 복잡해질 수 있는 오류 처리 측면에서 운영 오버헤드를 추가합니다.
SageMaker Processing step은 AWS Batch job ARN이 아니라 S3(또는 FSx/EFS) 같은 데이터 소스에서 입력을 받습니다. Pipelines는 Batch job을 ARN으로 직접 “입력 아티팩트”로 소비할 수 없습니다. 올바른 통합 지점은 Batch가 생성한 S3 출력물이며, 이는 pipeline parameter로 전달하거나 규칙(convention)으로 발견해야지, Batch job 식별자를 processing 입력으로 참조하는 방식이 아닙니다.
Callback step은 사람 승인 또는 외부 시스템이 callback token을 통해 pipeline에 완료 신호를 보내도록 설계되었습니다. 이를 AWS Batch 실행에 사용하려면 외부 구성 요소(예: Lambda 또는 커스텀 서비스)가 Batch job을 시작하고 완료 시 callback을 호출해야 합니다. 이는 추가 구성 요소와 운영 오버헤드를 유발하며, 이미 실행되는 Batch job의 성공 이벤트에 반응하는 가장 단순한 방식이 아닙니다.
EventBridge는 최소한의 운영으로 AWS 서비스 이벤트에 반응하도록 설계되었습니다. AWS Batch는 Job State Change 이벤트를 내보내며, EventBridge rule은 SUCCEEDED를 매칭해 SageMaker의 StartPipelineExecution을 빠르게(일반적으로 수 초) 호출할 수 있습니다. 이는 “2분 이내 시작” 요구 사항을 충족하고, 스케줄 실행과 수동 실행 모두에서 동작하며, state machine이나 장시간 실행되는 poller를 피하면서 통합을 느슨하게 결합하고 복원력을 유지합니다.
문제 분석
핵심 개념:
이 문제는 최소한의 운영으로 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
문제 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 변경을 중앙화하려고 합니다. 어떤 솔루션이 이 요구 사항을 충족합니까?
정답입니다. SageMaker notebook instance는 AWS service에 접근하기 위해 execution IAM role을 사용합니다. 6개의 notebook 모두에 동일한 role을 attach하면 authorization이 중앙화되어 security team이 permission을 한 번만 업데이트하면 됩니다(이상적으로는 단일 customer-managed policy를 편집/attach). 이는 두 bucket에 대한 필요한 S3 read-only access와 최소 SageMaker permission만 부여하여 least privilege를 충족하고 administrator-level access를 피합니다.
오답입니다. IAM group은 SageMaker notebook instance에 직접 associate할 수 없습니다. Group은 IAM user에 permission을 할당하는 메커니즘이지 AWS compute/service identity에 대한 것이 아닙니다. Engineer가 group에 속해 있더라도 notebook instance는 AWS API 호출에 execution role을 사용하므로, group 변경만으로 notebook의 runtime permission을 안정적으로 중앙화할 수 없습니다.
오답이며 안전하지 않습니다. notebook instance에서 단일 IAM user의 long-term credential을 사용하는 것은 AWS best practice에 어긋납니다(key 노출 위험, rotation 부담, per-session credential 부재). AdministratorAccess를 attach하는 것은 광범위한 admin privilege를 피하라는 요구 사항을 위반하며 least-privilege 원칙을 깨뜨립니다. SageMaker는 embedded access key가 아니라 temporary credential을 사용하는 execution role을 사용하도록 설계되었습니다.
오답입니다. 이는 여러 잘못된 아이디어를 결합합니다. IAM group은 여전히 notebook instance에 attach할 수 없고, AdministratorAccess 부여는 명시적으로 필요 이상으로 광범위합니다. 또한 role은 principal(user/group)이 policy를 통해 assume할 수 있지만, notebook instance 자체에는 execution role이 필요합니다. Group을 role에 associate한다고 해서 notebook이 자동으로 그 role을 사용하게 되지 않으며, least privilege도 충족하지 못합니다.
문제 분석
핵심 개념:
이 문제는 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
문제 16
한 공공 의료 네트워크가 Amazon Q Business에 대한 API 호출을 통해 하루 약 2,000건의 질의를 처리하는 내부 법률 보조 챗봇을 배포하고 있습니다. 컴플라이언스 정책에 따라 모델의 응답에는 기밀 코드명 "Project Raven"(정확한 문구 일치)이 절대로 포함되면 안 되며, 해당 문자열이 인덱싱된 소스 문서에 존재하더라도 마찬가지입니다. 또한 기존 인덱스를 수정하지 않고 응답 시점에 제어가 강제되어야 합니다. 이 요구 사항을 충족하기 위해 팀은 무엇을 해야 합니까?
정답입니다. Amazon Q Business에서 “Project Raven”을 차단 문구로 차단하는 것은 인덱싱된 문서에 존재하더라도 응답에 해당 정확한 문자열이 나타나는 것을 방지하는 출력 시점 제어입니다. 이는 “절대로 포함되면 안 됨”이라는 컴플라이언스 요구 사항을 충족하며, 기존 인덱스를 변경하거나 재구축하지 않고 응답 시점에 강제한다는 제약도 만족합니다.
오답입니다. “Project Raven”이 포함된 검색 결과를 제외하는 것은 검색 시점 완화책이며, 응답 시점 보장을 제공하지 않습니다. 노출을 줄일 수는 있지만, 모델이 다른 검색된 구절, 사용자 프롬프트, 또는 부분 컨텍스트로부터 해당 문구를 여전히 생성할 수 있으므로 그 문구가 절대 나타나지 않는다고 보장할 수 없습니다. 요구 사항은 결정론적 응답 시점 차단을 요구합니다.
오답입니다. “Project Raven”이 포함된 문서를 제외한 새로운 Amazon Kendra 인덱스를 구축하는 것은 “기존 인덱스를 수정하지 않고”라는 제약을 위반합니다(재인덱싱/재구축은 사실상 인덱싱 접근을 변경하는 것입니다). 또한 해당 문구가 프롬프트나 다른 소스를 통해 유입될 수 있다면, 여전히 엄격한 응답 시점 보장을 제공하지 못합니다.
오답입니다. 문서 속성 부스팅은 랭킹/관련성(우선순위 낮춤)만 변경하며 보안 제어가 아닙니다. “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
문제 17
핀테크 스타트업의 데이터 사이언스 팀이 프라이빗 서브넷 내에서 6개의 ml.p3.8xlarge 인스턴스를 사용해 분산 Amazon SageMaker training job을 실행하려고 합니다. 또한 학습 실행 중 SageMaker 프로세스가 사용하는 전송 중 데이터(노드 간 트래픽 및 프레임워크 조정 메시지 포함)가 저장 시(at-rest) 암호화 설정을 변경하지 않고도 엔드 투 엔드로 암호화되도록 보장해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?
오답입니다. Batch Transform은 오프라인/배치 inference에 사용되며 분산 training job을 실행하는 기능이 아닙니다. Batch Transform에 대해 암호화된 통신을 활성화해도 SageMaker training cluster의 네트워크 트래픽 패턴(예: 그래디언트 교환, MPI/NCCL collective)에는 영향을 주지 않습니다. 요구 사항은 분산 학습 실행과 노드 간 조정 트래픽을 명시적으로 대상으로 하며, 이는 Batch Transform 설정으로는 커버되지 않습니다.
정답입니다. SageMaker training job의 inter-container traffic encryption은 분산 학습에 참여하는 인스턴스/컨테이너 간 전송 중 데이터를 암호화하도록 설계되었습니다. 여기에는 분산 프레임워크에 필요한 노드 간 트래픽과 조정 메시지가 포함됩니다. 데이터, 볼륨 또는 artifact에 대한 저장 시(at-rest) 암호화 설정을 변경할 필요 없이 training cluster에 대해 “엔드 투 엔드 전송 중 암호화” 요구 사항을 충족합니다.
오답입니다. training job 요청에서 KMS key를 제공하는 것은 주로 저장 시(at-rest) 암호화(예: training 인스턴스가 사용하는 EBS 볼륨 및/또는 구성에 따라 S3에 기록되는 출력 artifact)를 활성화합니다. 스토리지 보안에는 중요하지만, 분산 학습 중 노드 간 또는 프레임워크 조정 트래픽이 전송 중에 암호화되도록 보장하지는 않습니다. 이 문제는 실행 중 전송 중 암호화에 초점을 맞춥니다.
오답입니다. SageMaker Studio Domain의 KMS key는 Studio 관련 스토리지(예: 사용자 홈 디렉터리를 위한 EFS 볼륨) 및 특정 Studio 리소스의 저장 시(at-rest) 암호화를 관리합니다. 이는 별도의 SageMaker 분산 training job cluster의 런타임 네트워크 암호화 동작을 제어하지 않습니다. 요구 사항은 Studio domain 스토리지 암호화가 아니라 training job의 전송 중 트래픽에 관한 것입니다.
문제 분석
핵심 개념:
이 문제는 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
문제 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에서 이를 강제할 솔루션은 무엇입니까?
정답입니다. SageMaker는 서비스별 조건 키인 sagemaker:RootAccess를 지원하며, 이는 CreateNotebookInstance 및 UpdateNotebookInstance 요청에 대한 IAM 정책에서 평가할 수 있습니다. RootAccess가 Disabled여야 한다고 요구하는 명시적 Deny를 사용하면, AWS는 notebook instance가 생성되거나 수정되기 전에 API 호출을 차단하므로 사전 예방적 강제 적용 요구 사항을 충족합니다. 이 Deny를 AWS Organizations SCP에 적용하면 모든 멤버 계정과 모든 Region에서, 해당 계정의 관리자에게도 적용됩니다. 또한 Console, CLI/SDK, CloudFormation, Service Catalog를 통한 실행도 모두 동일한 SageMaker API를 최종적으로 호출하므로 이 경우도 포함됩니다.
오답입니다. AWS KMS 암호화는 EBS 볼륨 및 기타 암호화된 리소스의 저장 데이터 보호를 제어하지만, RootAccess와 같은 SageMaker notebook instance의 OS 수준 설정은 제어하지 않습니다. key policy는 누가 CMK를 사용할 수 있는지는 제한할 수 있지만, notebook이 root 활성화 상태로 생성되는지 여부는 제한할 수 없습니다. 따라서 root access 구성을 방지해야 한다는 요구 사항을 충족하지 못합니다.
오답입니다. EventBridge + Lambda 삭제는 사후 대응(remediation) 방식입니다. root access가 있는 notebook이 몇 초 동안이라도 존재할 수 있으며(함수가 실패하면 더 오래 지속될 수 있음), 이는 “절대 생성되면 안 된다” 및 “사전 예방적으로 차단해야 한다”는 요구 사항을 위반합니다. 또한 운영상 위험(이벤트 누락, throttling, 재시도)을 초래하며, 요청 승인 시점에 강력한 예방적 guardrail을 제공하지 못합니다.
오답입니다. CloudFormation stack 이벤트 감지는 CloudFormation을 통해 생성된 리소스에만 적용되며, Console/CLI/SDK 또는 CloudFormation 기반이 아닐 수 있는 Service Catalog product를 통해 생성된 리소스에는 적용되지 않습니다. 또한 적용 가능한 경우에도 stack 생성/업데이트 후 삭제하는 것은 여전히 사후 대응 방식이므로, 비준수 리소스가 일시적으로라도 존재할 수 있어 사전 예방적 방지 요구 사항을 충족하지 못합니다.
문제 분석
핵심 개념:
이 문제는 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
문제 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을 제공합니까?
S3 bucket versioning은 객체의 여러 변형을 유지하여 실수로 인한 overwrite/delete로부터 보호하고 rollback을 지원합니다. 하지만 어떤 객체에 누가 접근할 수 있는지를 제어하지는 않습니다. Versioning을 활성화하더라도 객체 key에 대해 s3:GetObject 권한이 있는 principal은 여전히 읽을 수 있고, s3:PutObject 권한이 있는 principal은 여전히 쓸 수 있습니다. Versioning은 내구성/복구 기능이지, 부서 격리를 위한 access control 메커니즘이 아닙니다.
S3 Object Lock은 retention 기간 동안 객체가 삭제되거나 overwrite되지 않도록 write-once-read-many (WORM) retention 및 legal hold를 강제합니다. 이는 compliance와 immutability를 위한 것이지, 사용자 또는 부서별로 read/write permission 범위를 제한하기 위한 것이 아닙니다. Object Lock은 IAM permission이 허용하는 경우 engineer가 다른 부서 데이터를 읽는 것을 막을 수 없으므로, 격리 요구사항을 충족하지 못합니다.
S3의 CORS 규칙은 어떤 web origin(domain)이 browser 기반으로 S3에 요청할 수 있는지, 그리고 어떤 method/header가 허용되는지를 정의합니다. SageMaker Studio notebook과 training job은 CORS가 관장하는 browser cross-origin call이 아니라 AWS SDK와 IAM credential/role을 사용해 S3에 접근합니다. 따라서 CORS는 prefix별 authorization을 강제하지 못하며, engineer가 다른 부서 prefix에 접근하는 것을 차단하지 못합니다.
S3 prefix로 범위를 제한한 IAM policy는 least-privilege access를 강제하는 올바른 방법입니다. s3:prefix condition을 사용해 허용된 prefix에 대해서만 ListBucket을 허용하고, arn:aws:s3:::edu-ml-data/<dept>/*에 대해서만 GetObject/PutObject를 허용하는 policy를 생성합니다. 이를 각 부서에서 사용하는 SageMaker execution role에 연결하고(그리고 Studio user profile을 그에 맞게 매핑) interactive notebook과 training job 모두가 일관되게 제한되도록 합니다.
문제 분석
핵심 개념:
이 문제는 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
문제 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는 무엇을 해야 합니까?
오답입니다. SageMaker Model Monitor는 data quality, drift, bias, 그리고(ground truth가 उपलब्ध한 경우) model quality와 같은 지속적인 모델 거버넌스 신호에 초점을 둡니다. endpoint cold-start 또는 initialization latency를 직접 측정하지 않습니다. Model Monitor jobs를 스케줄링해도 추가 400 ms가 모델 시작 때문인지 inference 로직 때문인지 확인하는 데 도움이 되지 않습니다.
오답입니다. Model Monitor 출력에 대해 CloudWatch metrics를 활성화하더라도, Model Monitor는 여전히 serverless inference cold starts를 진단하기 위한 올바른 도구가 아닙니다. 이 문제는 endpoint runtime에서의 요청 latency 분해에 관한 것이며, 이는 Model Monitor job metrics가 아니라 SageMaker endpoint CloudWatch metrics가 제공합니다.
정답입니다. ModelSetupTime은 SageMaker model을 inference용으로 준비하는 것과 관련된 initialization overhead를 가장 직접적으로 측정하는 CloudWatch metric입니다. serverless inference 시나리오에서 endpoint가 유휴 상태였던 후 latency가 증가한다면, 해당 첫 요청들에서 높아진 ModelSetupTime은 cold start의 강력한 증거입니다. 이를 통해 엔지니어는 startup overhead와 실제 inference code path를 구분할 수 있습니다. 이 metric은 SageMaker가 CloudWatch로 내보내므로, 이 가설을 확인하기 위해 살펴봐야 할 적절한 운영 신호입니다.
오답입니다. ModelLoadingWaitTime은 latency 급증이 cold-start setup overhead로 인해 발생하는지 검증하기에 가장 좋은 metric이 아닙니다. wait-time metric은 model loading 또는 resources를 기다리는 데 소요된 시간을 시사하지만, ModelSetupTime만큼 전체 initialization 및 setup 단계를 직접적으로 나타내지는 않습니다. 문제는 startup 시간이 원인인지 어떻게 확인할지를 묻고 있으므로, setup을 명시적으로 측정하는 metric이 더 나은 선택입니다. 시험에서는 이름과 목적이 의심되는 문제와 가장 정확하게 일치하는 metric을 우선 선택하세요.
문제 분석
핵심 개념:
이 문제는 단계를 기준으로 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를 통해 사용할 수 있다는 점도 기억하세요.
모든 문제 &
정답 무료
상세
해설
실제 시험과
가장 유사
