65개 문제와 170분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
정유 공장 안전 시스템에서, 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도 항상 고려하라.
한 미디어 분석 회사는 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를 선호하십시오.
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를 우선 고려하십시오.
한 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 감소가 해당됩니다.
미디어 모니터링 팀이 주당 다국어 팟캐스트 오디오(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를 주의하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
온라인 마켓플레이스의 한 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가 최선의 답입니다.
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)와 구분하십시오.
한 데이터 과학자가 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 권한도 필요할 수 있음).
한 공공 의료 네트워크가 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의 차단 문구(때로는 차단 단어/문구로 설명됨)는 특정 문자열이 응답으로 출력되는 것을 방지하여 컴플라이언스와 안전을 지원하도록 설계되었습니다. 이는 출력 제어(응답 시점 강제)로서 정책이 요구하는 바와 정확히 일치합니다. 액세스 제어 통합 및 콘텐츠 필터링 같은 다른 제어를 보완하지만, 재인덱싱 없이 “이 정확한 문구는 절대 포함되면 안 됨” 제약을 유일하게 충족합니다. 흔한 오해: 흔한 함정은 검색 시점 필터링(문서 또는 결과 제외)에 집중하는 것입니다. 검색에서 일부 항목을 제외하더라도, 모델은 다른 검색된 콘텐츠, 사용자 프롬프트 인젝션, 또는 모델 동작으로 인해 해당 문구를 여전히 생성할 수 있습니다. 또 다른 오해는 콘텐츠를 “우선순위 낮춤”(부스팅)하면 위험이 줄어든다는 것인데, 이는 비노출을 보장하지 않습니다. 시험 팁: “응답에 절대 나타나면 안 됨”과 “응답 시점에 강제”라는 문구가 보이면, 검색 튜닝/랭킹/재인덱싱이 아니라 차단 문구/용어 같은 출력 가드레일을 찾으십시오. 또한 “기존 인덱스를 수정하지 않고” 같은 제약은 재구축/재수집 솔루션을 배제합니다. 의료/컴플라이언스 시나리오에서는 확률적 관련성 튜닝보다 결정론적 제어(명시적 차단)를 선호하십시오.
핀테크 스타트업의 데이터 사이언스 팀이 프라이빗 서브넷 내에서 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 구성은 각각 보안 제어가 다르므로 구분해야 합니다.
학습 기간: 2 weeks
Used these questions exclusively to study, passed on first time. The app questions is very similar to the actual exam.
학습 기간: 2 weeks
Passed Oct 2025 with 905 score.
학습 기간: 1 month
문제 좋네요 굿굿!!


이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
