CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Microsoft AI-102
Microsoft AI-102

Practice Test #3

50개 문제와 100분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

50문제100분700/1000합격 점수
기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도

기출 문제

1
문제 1

HOTSPOT - 다음 전시물에 표시된 것처럼 사용자에게 정보를 제공하는 chatbot을 구축하고 있습니다.

diagram

드롭다운 메뉴를 사용하여 그래픽에 제시된 정보를 기반으로 각 문장을 완성하는 답안을 선택하십시오. 참고: 각 정답 선택은 1점입니다. Hot Area:

파트 1:

챗봇이 ______을(를) 표시하고 있습니다.

정답: A (an Adaptive Card). 제시된 화면은 복잡하고 구조화된 레이아웃을 보여줍니다: 여러 개의 제목(Passengers, Stops), 반복되는 여정 블록, 좌/우로 정렬된 컬럼(SFO/AMS가 양쪽에 표시), 그리고 정교한 간격 배치가 있습니다. 이는 containers와 column sets를 사용해 유연한 구성(composition)이 가능한 Adaptive Cards의 전형적인 특징입니다. 왜 Hero Card (B)가 아닌가: Hero Card는 고정된 스키마(제목, 부제목, 텍스트, 큰 이미지 1개, 버튼)로 구성됩니다. 여정(itinerary)처럼 다중 컬럼과 반복되는 구조화 섹션을 위해 설계되지 않았습니다. 왜 Thumbnail Card (C)가 아닌가: Thumbnail Card는 작은 썸네일 이미지를 사용하는 점만 다를 뿐 Hero Card와 유사하며, 여전히 고정된 레이아웃을 사용합니다. 따라서 제시된 것과 같은 그리드/컬럼 형식의 포맷을 지원하지 않습니다. 시험 관점에서: “form-like” 또는 “UI-like”한 구조화된 콘텐츠, 특히 컬럼이나 반복 섹션이 보이면 Adaptive Card를 선택하세요.

파트 2:

이 카드는 ______을(를) 포함합니다.

정답: B (image). 이 카드는 각 항공편 구간의 가운데에 비행기 아이콘이 명확히 포함되어 있습니다. 이는 카드 내에서 렌더링되는 image 요소입니다. action set (A)가 아닌 이유: ActionSet은 일반적으로 버튼(예: “Select”, “View details”, “Book”) 형태로 나타나는데, 제시된 화면에는 이러한 요소가 보이지 않습니다. Adaptive Cards가 actions를 포함할 수는 있지만, 스크린샷에는 표시되어 있지 않습니다. image group (C)가 아닌 이유: image group(Adaptive Cards에서 흔히 ImageSet으로 표현)은 여러 이미지를 함께 표시하는 컬렉션(예: 썸네일/아바타 행)입니다. 제시된 화면은 구간당 비행기 아이콘 1개만 보여주며, 그룹으로 묶인 세트가 아닙니다. media (D)가 아닌 이유: Adaptive Cards에서 “Media”는 오디오/비디오 재생이 가능한 임베디드 미디어를 의미합니다. 제시된 화면은 재생 가능한 media가 아니라 정적인 아이콘입니다.

2
문제 2

고객이 Azure Cognitive Search를 사용합니다. 고객은 서버 측 암호화를 활성화하고 Azure에 저장된 customer-managed keys (CMK)를 사용하려고 합니다. 계획된 변경의 영향은 무엇입니까? 정답은 세 가지입니다. 각 정답은 완전한 해결책을 제시합니다. 참고: 각 정답 선택은 1점입니다.

오답입니다. Azure Cognitive Search CMK에 대한 Azure 문서에서는 customer-managed keys 활성화의 표준 영향으로 index size 증가를 명시하지 않습니다. Encryption metadata와 key wrapping은 service-level implementation details이지만, 시험 목표에서는 이를 index size의 보장되거나 문서화된 사용자 가시적 변화로 보지 않습니다. 따라서 이 선택지는 선택할 수 있는 신뢰할 만한 영향이 아닙니다.

오답입니다. 이론적으로는 어떤 security feature든 일부 operational overhead를 유발할 수 있지만, Azure Cognitive Search CMK가 표준 영향으로 query times 증가를 초래한다고 문서화되어 있지는 않습니다. Product guidance에서는 일반적으로 CMK가 활성화되었다는 이유만으로 query execution이 느려진다고 설명하지 않습니다. 자격증 시험에서는 이는 문서화된 효과가 아니라 근거 없는 가정에 해당합니다.

오답입니다. Azure Cognitive Search에서 customer-managed keys를 활성화하기 위해 self-signed X.509 certificate는 필요하지 않습니다. 지원되는 모델은 Azure Key Vault에 저장된 key를 사용하며, search service가 managed identity 또는 구성된 credentials를 통해 해당 키에 액세스하는 방식입니다. Certificates는 이 service의 일반적인 CMK 설정과 관련이 없습니다.

오답입니다. CMK를 활성화해도 index size는 감소하지 않습니다. Encryption은 security control이지 compression mechanism이 아니며, Azure Cognitive Search에서 CMK가 storage footprint를 줄인다는 문서화된 동작은 없습니다. 이 선택지는 일부가 추측할 수 있는 내용의 반대이지만, 여전히 근거가 없습니다.

오답입니다. Customer-managed keys는 query performance를 향상시키지 않습니다. CMK의 목적은 compliance, governance, 그리고 encryption keys에 대한 control이며, search operations를 가속화하기 위한 것이 아닙니다. CMK 활성화 후 query times가 감소할 것이라고 기대할 문서화된 근거는 없습니다.

정답입니다. Azure Cognitive Search는 Azure Key Vault를 통해 customer-managed encryption keys를 저장하고 사용합니다. search service는 at-rest 상태의 service data를 보호하는 데 사용되는 internal encryption keys를 wrap 및 unwrap할 수 있도록 해당 키에 대한 액세스 권한을 부여받아야 합니다. 이것이 Azure Cognitive Search에서 CMK를 활성화하기 위한 핵심 platform dependency이며, 제시된 선택지 중 유일하게 명확히 지원되는 영향입니다.

문제 분석

핵심 개념: Azure Cognitive Search는 indexes, synonym maps, indexers, data sources, skillsets, 및 knowledge stores의 추가적인 at-rest encryption을 위해 customer-managed keys (CMK)를 지원합니다. CMK를 사용하려면 encryption keys를 Azure Key Vault에 저장해야 하며, search service가 일반적으로 managed identity와 적절한 permissions를 통해 해당 키에 액세스하도록 구성되어야 합니다. 주요 특징에는 더 강력한 compliance control, key lifecycle에 대한 customer ownership, 그리고 rotation 및 auditing을 위한 Azure Key Vault와의 통합이 포함됩니다. 흔한 오해는 CMK가 index size를 실질적으로 변경하거나, 시험에서 고정된 영향으로 간주될 정도로 query execution을 직접적으로 느리게 만든다는 것입니다. 그러나 이는 Azure Cognitive Search에 대해 일반적으로 문서화된 표준 효과가 아닙니다. 시험 팁: Azure Cognitive Search에서 CMK를 보면, 즉시 Azure Key Vault 요구 사항, identity/permissions 구성, 그리고 storage 또는 query-performance 변화가 아니라 key store에 대한 운영상 dependency를 떠올리세요.

3
문제 3

HOTSPOT - West US Azure region에서 호스팅되는 contoso1이라는 Computer Vision 리소스가 있습니다. smart cropping 기능을 사용하여 contoso1로 제품 사진의 크기를 다른 크기로 만들어야 합니다. API URL을 어떻게 완성해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택은 1점입니다. 핫 영역:

파트 1:

curl -H "Ocp-Apim-Subscription-Key: xxx" / -o "sample.png" -H "Content-Type: application/json" / "______" /vision/v3.1/

올바른 호스트: "https://contoso1.cognitiveservices.azure.com". contoso1이라는 이름의 Computer Vision 리소스를 생성하면, Azure는 https://<resource-name>.cognitiveservices.azure.com 형태의 리소스별 endpoint를 제공합니다. 이는 현재 Azure Cognitive Services/Azure AI services에서 권장되며 가장 일반적인 endpoint 형식입니다. A가 아닌 이유: https://api.projectoxford.ai 는 초기 Project Oxford 시절의 오래된 legacy endpoint이며, 최신 Azure Cognitive Services 리소스에서는 사용되지 않습니다. C가 아닌 이유: https://westus.api.cognitive.microsoft.com 는 이전의 regional endpoint 스타일입니다. 일부 상황에서는 동작할 수 있지만, 이 문제는 리소스 이름 contoso1을 명시하고 해당 리소스를 사용하라고 하므로, 일반적인 regional endpoint가 아니라 리소스 endpoint를 사용하는 것이 맞습니다.

파트 2:

/vision/v3.1/______?width=100&height=100&smartCropping=true" /

정답 작업: generateThumbnail. 크기가 조정된 이미지를 생성하는 Computer Vision 작업은 thumbnail generation API이며, width와 height와 함께 smartCropping=true를 추가하여 smart cropping을 활성화합니다. 따라서 /vision/v3.1/ 뒤의 경로 세그먼트는 generateThumbnail이어야 하며, /vision/v3.1/generateThumbnail?width=100&height=100&smartCropping=true와 같은 URL이 생성됩니다. 왜 detect가 아닌가: detect는 새 이미지를 생성하는 것이 아니라 객체 감지(바운딩 박스와 레이블 반환)에 사용됩니다. 왜 areaOfInterest가 아닌가: areaOfInterest는 이미지에서 중요할 가능성이 높은 영역의 좌표를 반환하며, 잘라내기/크기 조정된 출력 이미지를 자체적으로 생성하지는 않습니다. 출력 이미지에 대한 smart cropping은 generateThumbnail의 일부로 구체적으로 제공됩니다.

4
문제 4

DRAG DROP - 모바일 앱에서 사용되는 Custom Vision 모델을 학습합니다. 연결된 데이터가 없는 새 이미지 1,000장을 받습니다. 이미지를 사용하여 모델을 다시 학습해야 합니다. 솔루션은 모델을 다시 학습하는 데 걸리는 시간을 최소화해야 합니다. Custom Vision 포털에서 수행해야 하는 세 가지 작업은 무엇입니까? 답하려면 작업 목록에서 적절한 작업을 답변 영역으로 이동하고 올바른 순서로 배열하십시오. 선택 및 배치:

파트 1:

아래 이미지에서 올바른 답(들)을 선택하세요.

question-image

Pass. 1,000개의 레이블이 지정되지 않은 이미지로 재학습 시간을 최소화하기 위해 Custom Vision portal에서 수행해야 하는 올바른 순서의 작업은 다음과 같습니다. 1) 모든 이미지를 업로드합니다. 2) 제안된 tags를 가져옵니다. 3) 제안을 검토하고 tags를 확인합니다. 이 방법이 가장 빠른 접근 방식인 이유는, 기존에 학습된 model을 기반으로 Custom Vision의 suggested tags(종종 smart labeling이라고도 함)를 사용하여 수동 레이블링 작업을 최소화하기 때문입니다. 대량 업로드 후 portal이 새 이미지에 대한 tags를 제안할 수 있으며, 사용자는 이를 검증/수정하기만 하면 되므로 각 이미지를 처음부터 tag하는 것보다 훨씬 빠릅니다. 다른 옵션이 덜 적합한 이유: “Upload the images by category” 및 “Group the images locally into category folders”는 각 이미지의 올바른 category를 이미 알고 있다고 가정하는데, 이는 “no associated data”와 모순됩니다. “Tag the images manually”도 가능하긴 하지만 1,000개 이미지에 대해 가장 느리며, 재학습 시간(엔드 투 엔드)을 최소화해야 한다는 요구 사항을 충족하지 못합니다.

5
문제 5
(2개 선택)

새 리소스 그룹 RG1에 QnA Maker 서비스를 프로비저닝할 계획입니다. RG1에서 AP1이라는 이름의 App Service plan을 생성합니다. QnA Maker 서비스를 프로비저닝할 때 RG1에 자동으로 생성되는 Azure 리소스 두 가지는 무엇입니까? 각 정답은 솔루션의 일부를 제시합니다. 참고: 각 정답 선택은 1점입니다.

LUIS라고도 하는 Language Understanding은 intent detection과 entity extraction에 사용되는 별도의 Azure AI 서비스입니다. QnA Maker를 함께 사용하는 bot과 통합될 수는 있지만, QnA Maker 서비스를 만들 때 자동으로 프로비저닝되지는 않습니다. 기대되는 두 개의 종속 리소스는 NLP intent 서비스가 아닙니다. 따라서 이 옵션은 틀렸습니다.

Azure SQL Database는 QnA Maker를 위해 생성되는 표준 리소스 집합의 일부가 아닙니다. QnA Maker는 기본 retrieval engine으로 relational database를 사용하지 않고, 대신 Azure Cognitive Search에 의존합니다. 애플리케이션이 custom metadata나 logging을 위해 별도로 SQL을 사용할 수는 있지만, 그것은 QnA Maker 프로비저닝 외부의 설계 선택입니다. 따라서 이 옵션은 틀렸습니다.

Azure Storage는 QnA Maker 프로비저닝의 일부로 자동 생성되어 서비스의 기반 데이터와 artifact를 지원합니다. QnA Maker는 relational database에 의존하기보다 운영 콘텐츠를 위한 지원 storage를 사용합니다. legacy QnA Maker 종속성에 대한 시험 문제에서 Storage는 자동으로 프로비저닝되는 것으로 기대되는 리소스 중 하나입니다. 따라서 search 리소스와 함께 올바른 선택입니다.

Azure Cognitive Search는 QnA Maker가 question-and-answer pair를 효율적으로 저장하고 검색하기 위해 search index에 의존하므로 자동 생성됩니다. 이 서비스는 본질적으로 retrieval-based이므로 인덱싱과 ranking이 핵심 런타임 기능입니다. 각 knowledge base는 Cognitive Search가 빠르게 쿼리할 수 있는 searchable content를 기반으로 합니다. 이 종속성은 AI-102를 위해 기억해야 할 가장 중요한 아키텍처 사실 중 하나입니다.

Azure App Service는 QnA Maker가 web endpoint를 노출하고 시나리오에서 AP1이라는 App Service plan을 언급하기 때문에 그럴듯한 선택지처럼 보입니다. 그러나 이 시험 문항에서 기대하는 자동 생성 리소스는 Azure Cognitive Search와 Azure Storage입니다. App Service plan은 호스팅 관련 맥락이지만, 문제가 묻는 두 개의 정답 중 하나는 아닙니다. 따라서 이 옵션은 선택하면 안 됩니다.

문제 분석

핵심 개념: 이 문제는 QnA Maker 서비스를 만들 때 자동으로 배포되는 지원 Azure 리소스를 테스트합니다. 기존 QnA Maker 아키텍처에서는 Azure가 인덱싱과 서비스 데이터 저장에 사용되는 종속 리소스를 프로비저닝합니다. 정답 리소스는 Azure Cognitive Search와 Azure Storage입니다. 정답인 이유: Azure Cognitive Search는 QnA Maker가 question-and-answer pair를 인덱싱하고 런타임에 검색하는 retrieval-based 서비스이기 때문에 필요합니다. Azure Storage도 서비스에서 사용하는 지원 데이터를 저장하기 위해 생성됩니다. 호스팅에는 App Service plan이 관련되지만, 시험에서는 resource group에 자동으로 생성되는 보조 리소스를 Search와 Storage로 구분하는 것이 핵심입니다. 주요 기능: Cognitive Search는 knowledge base 콘텐츠의 인덱싱, ranking, 빠른 lookup을 제공합니다. Azure Storage는 서비스 artifact와 운영 데이터를 지속적으로 저장하는 역할을 지원합니다. QnA Maker는 서비스가 프로비저닝될 때 내부적으로 이러한 관리형 Azure 리소스에 의존합니다. 흔한 오해: 많은 응시자가 QnA Maker가 HTTP endpoint를 노출한다는 이유로 Azure App Service를 선택하지만, 시나리오에 App Service plan이 있다고 해서 App Service가 자동 생성되는 두 개의 정답 중 하나라는 뜻은 아닙니다. Language Understanding은 별도의 서비스이며, Azure SQL Database는 표준 QnA Maker 프로비저닝의 일부가 아닙니다. 시험 팁: legacy QnA Maker 프로비저닝에 대한 AI-102 문제에서는 Search와 Storage를 중심으로 한 종속성 패턴을 기억하세요. 기존 App Service plan과 시험에서 기대하는 자동 생성 리소스 목록을 혼동하지 않도록 주의하세요.

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

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

6
문제 6

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 시리즈의 각 질문에는 명시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션에서 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. Azure virtual machine인 vm1에서 실행되는 app1이라는 web app을 생성합니다. Vm1은 vnet1이라는 Azure virtual network에 있습니다. service1이라는 새 Azure Cognitive Search 서비스를 생성할 계획입니다. public internet을 통해 트래픽을 라우팅하지 않고 app1이 service1에 직접 연결할 수 있도록 해야 합니다. 솔루션: service1과 public endpoint를 배포하고 IP firewall rule을 구성합니다. 이것이 목표를 충족합니까?

예가 틀린 이유는 IP firewall rule이 Azure Cognitive Search에 대한 private connectivity를 제공하지 않기 때문입니다. 이는 승인된 public source IP address에 대한 access만 제한할 뿐이며, private networking 기능이 아니라 access-control 방식입니다. 서비스는 여전히 public endpoint를 통해 도달되므로, traffic 경로는 public internet을 피해야 한다는 요구 사항을 충족하지 않습니다. 목표를 충족하려면 설계에서 private endpoint와 적절한 private DNS configuration을 사용해야 합니다.

아니요가 정답인 이유는 IP firewall rule이 있는 public endpoint는 여전히 Azure Cognitive Search를 public interface를 통해 노출하기 때문입니다. firewall은 어떤 source IP address가 연결할 수 있는지만 제한할 뿐이며, traffic은 여전히 virtual network의 private IP가 아니라 public endpoint를 대상으로 합니다. 요구 사항은 app1이 public internet을 통해 traffic을 라우팅하지 않고 연결해야 한다고 명시하고 있으며, 이를 위해서는 일반적으로 private endpoint가 포함된 Azure Private Link가 필요합니다. private endpoint를 사용하면 vm1은 search service를 private address로 확인하고 public internet 대신 Azure backbone을 통해 통신합니다.

문제 분석

핵심 개념: 이 문제는 Azure OpenAI (AI1) 및 Azure AI Content Safety (CS1)를 사용하는 generative AI chatbot에 대해 safety/content filtering을 평가하고 조정하는 방법을 테스트합니다. AI-102 관점에서는 test prompt를 실행하고 filter configuration을 최적화하기 위한 올바른 tooling/workflow를 선택하는 내용입니다. 정답인 이유: Content Safety Studio의 “Safety metaprompt” 기능을 사용하는 것은 content filter configuration을 최적화하기 위해 sample question에 대해 체계적인 test를 실행하는 적절한 방법이 아닙니다. Content Safety Studio는 Content Safety 기능(text/image moderation, severity threshold, testing)을 탐색하고 평가하는 데 사용되지만, “Safety metaprompt”는 chatbot의 input/output pipeline에 대한 content filter를 batch 스타일로 테스트하고 조정하기 위한 주요 기능이 아닙니다. content filter configuration을 최적화하려면 일반적으로 Content Safety Studio의 testing 환경(text/image용) 및/또는 representative prompt와 response를 Content Safety API를 통해 전송하는 programmatic evaluation을 사용하고, 결과에 따라 category threshold(hate, sexual, violence, self-harm)와 action(block, allow, review)을 조정합니다. 주요 기능 및 모범 사례: - Content Safety Studio를 사용하여 configurable severity threshold로 text moderation을 테스트하고 category 전반의 detection을 검토합니다. - 반복 가능한 최적화를 위해 sample user input과 model output으로 구성된 curated dataset를 API를 통해 CS1에 제출하는 test harness를 실행하고, score/severity를 수집하며 threshold를 반복 조정합니다. - Azure Well-Architected Framework (Reliability/Operational Excellence)에 맞춰 evaluation을 자동화하고, safety config를 version 관리하며, false positive/negative를 모니터링합니다. - Azure OpenAI에서는 model 측 content filtering과 외부 moderation(CS1)을 구분합니다. user input 경로와 model output 경로를 모두 테스트해야 합니다. 일반적인 오해: 어떤 “metaprompt” 또는 “safety prompt” 기능이든 filter를 테스트하기 위한 것이라고 생각하기 쉽습니다. 그러나 filter 최적화는 prompt template 기능에 관한 것이 아니라, dataset에 대한 moderation 결과를 측정하고 threshold/action을 조정하는 것입니다. 시험 팁: “optimize content filter configurations”와 “run tests on sample questions”를 보면, Content Safety Studio testing 도구 및/또는 자동화된 API 기반 evaluation pipeline을 떠올리세요. 또한 Content Safety는 moderation scoring을 위한 전용 서비스이며, OpenAI prompt 기법이 threshold 조정과 측정 가능한 test 실행을 대체하지 않는다는 점도 기억하세요.

7
문제 7
(3개 선택)

스마트 e-commerce 프로젝트를 개발하고 있습니다. Cognitive Search 솔루션의 일부로 자동 완성을 구현해야 합니다. 어떤 세 가지 작업을 수행해야 합니까? 각 정답은 솔루션의 일부를 제시합니다. 참고: 각 정답 선택은 1점입니다.

이는 Azure AI Search autocomplete가 표준 search endpoint가 아니라 autocomplete endpoint를 통해 호출되기 때문에 필요합니다. 요청은 service가 어떤 suggester 정의를 사용할지 알 수 있도록 suggesterName을 지정해야 합니다. suggester를 참조하지 않으면 service는 type-ahead 동작을 위해 구성된 source field를 적용할 수 없습니다.

이는 autocomplete가 index에 정의된 suggester에 의존하기 때문에 필요합니다. 하나의 suggester는 여러 source field를 포함할 수 있으며, 이것이 세 가지 product name variant 전반에서 autocomplete를 지원하는 올바른 방법입니다. 관련된 모든 field에 대해 하나의 suggester를 만드는 것이 더 단순하며 표준적인 Azure AI Search 설계입니다.

이는 search endpoint가 autocomplete가 아니라 full-text search를 수행하기 때문에 틀렸습니다. searchFields를 지정하더라도 동작은 여전히 표준 search이며, autocomplete에서 기대되는 전용 type-ahead 경험을 제공하지 않습니다. Azure AI Search에는 이 목적을 위한 별도의 autocomplete API가 있습니다.

이는 Azure AI Search가 field마다 하나의 suggester를 요구하지 않기 때문에 틀렸습니다. 하나의 suggester는 여러 source field를 참조할 수 있으며, 이것이 관련 text field 전반에서 autocomplete를 일반적으로 구현하는 방식입니다. 서로 다른 suggestion 시나리오가 있는 경우가 아니라면 여러 suggester는 불필요한 복잡성만 추가합니다.

이는 searchAnalyzer가 search time에 query text가 어떻게 분석되는지를 제어하기 때문에 예상되는 analyzer 관련 선택지입니다. autocomplete의 경우, 사용자의 partial input은 suggester field의 indexed term과 매칭될 때 적절하게 처리되어야 합니다. product name variant에 적절한 search-time analyzer를 사용하면 입력된 prefix가 올바르게 해석되도록 하는 데 도움이 됩니다.

여기서는 최선의 답이 아닙니다. analyzer는 index-time analyzer를 설정하는 반면, 이 문제는 tokenization 전략을 다시 구축하는 것보다 autocomplete 동작 구현에 초점을 맞추고 있기 때문입니다. Azure AI Search 시험 문제에서 autocomplete 시나리오에서 user-entered text를 처리하기 위한 예상 구성은 일반적으로 searchAnalyzer입니다. 더 넓은 index 설계에서는 analyzer도 중요할 수 있지만, 여기서 평가하는 필수 작업은 아닙니다.

문제 분석

핵심 개념: Azure AI Search autocomplete는 index에 suggester가 필요하며, 해당 suggester를 참조하는 autocomplete endpoint로의 client 요청이 필요합니다. 또한 type-ahead에 사용되는 field는 query text가 indexed term에 대해 올바르게 처리되도록 적절한 analysis 동작으로 구성되어야 합니다. 정답인 이유: 관련 product name field에 대해 suggester를 정의하고, suggester name과 함께 autocomplete API를 호출하며, 해당 field에 대한 search-time analyzer 동작을 구성해야 합니다. 주요 기능: 하나의 suggester는 여러 field에 걸칠 수 있고, autocomplete는 일반 search endpoint가 아니라 전용 endpoint를 사용하며, analyzer 설정은 user input이 어떻게 해석되는지에 영향을 줍니다. 흔한 오해: 많은 응시자가 autocomplete를 full-text search와 혼동하거나, field마다 별도의 suggester가 필요하다고 가정하거나, 특정 analyzer property가 autocomplete에 항상 반드시 필요하다고 생각합니다. 시험 팁: Azure AI Search autocomplete가 보이면 suggester + autocomplete endpoint + 적절한 analyzer/search analyzer 구성 패턴을 찾고, 일반 search query를 설명하는 선택지는 피하세요.

8
문제 8

DRAG DROP - 컨테이너에 배포된 app1이라는 Language Understanding 애플리케이션을 사용할 계획입니다. App1은 lu1이라는 Language Understanding authoring resource를 사용하여 개발되었습니다. App1에는 다음 표에 표시된 버전이 있습니다.

diagram

app1의 최신 배포 가능한 버전을 사용하는 컨테이너를 만들어야 합니다. 어떤 세 가지 작업을 순서대로 수행해야 합니까? 답하려면 작업 목록에서 적절한 작업을 답 영역으로 이동하고 올바른 순서로 정렬하십시오. Select and Place:

파트 1:

버전이 environment variable로 설정된 컨테이너를 실행합니다.

environment variable로 버전이 설정된 상태로 LUIS 컨테이너를 실행하는 것은 LUIS 컨테이너가 모델을 선택하는 방식이 아닙니다. 컨테이너는 environment variable을 기반으로 authoring resource에서 특정 LUIS app 버전을 동적으로 가져오지 않습니다. 대신, 컨테이너는 사용자가 제공하는 model package(내보낸 artifact)를 로드합니다. environment variable은 컨테이너 구성(예: billing endpoint, API key, EULA acceptance, logging)에 사용되지만, 서비스에서 LUIS app 버전을 선택하는 데 사용되지는 않습니다. 버전 선택은 runtime 이전에 이루어집니다. LUIS portal(또는 APIs)에서 버전을 선택하고, 해당 버전을 containers용으로 export한 다음, 이를 컨테이너에 mount합니다. 따라서 이 작업은 컨테이너가 최신 deployable 버전을 사용하도록 보장하기 위한 올바른 순서의 일부가 아닙니다.

파트 2:

Export as JSON 옵션을 사용하여 모델을 내보냅니다.

“Export as JSON”을 사용하여 모델을 내보내는 것은 LUIS container에 배포하기 위한 올바른 내보내기 형식이 아닙니다. JSON 내보내기는 주로 환경 간에 LUIS app 정의(intents, entities, utterances, settings)를 이동하거나 소스 제어를 위해 사용되며, 일반적으로 LUIS authoring으로 다시 가져오기 위해 사용됩니다. container의 경우 Microsoft는 학습된 모델을 container에서 소비할 수 있는 형식(GZIP)으로 패키징하는 특정 내보내기 옵션을 제공합니다. container는 authoring JSON schema가 아니라 내보낸 모델 artifact를 기대합니다. 따라서 JSON 내보내기는 DevOps 워크플로에 유용할 수 있지만, 해당 모델로 container가 직접 예측을 실행할 수 있게 해주지는 않습니다. 그러므로 이는 필수 작업 중 하나가 아닙니다.

파트 3:

app1의 v1.1을 선택합니다.

v1.1을 선택해야 하는 이유는 컨테이너에 배포 가능한 최신 버전이기 때문입니다. 표에서 v1.2는 trained date가 없으므로 학습되지 않았음을 의미하며, 따라서 실행 가능한 model artifact로 내보낼 수 없습니다. v1.0은 학습되고 게시되었지만 v1.1보다 오래된 버전입니다. LUIS containers의 경우 “published date”는 결정 요인이 아니며, 학습(training)이 결정 요인입니다. Publishing은 Azure에서 호스팅되는 LUIS prediction endpoint와 관련이 있지만, 컨테이너 배포는 학습된 버전을 내보내는 것에 의존합니다. 따라서 최신 배포 가능 버전을 사용하는 컨테이너를 만들기 위해서는, 컨테이너용으로 내보내기(export) 전에 v1.1(가장 최신의 학습된 버전)을 선택해야 합니다.

파트 4:

컨테이너를 실행하고 모델 파일을 마운트합니다.

컨테이너를 실행하고 모델 파일을 마운트하는 것은 LUIS 컨테이너 배포에 필요한 단계입니다. LUIS 컨테이너는 런타임에 LUIS service에서 모델을 자동으로 가져오지 않으며, 컨테이너 내부의 filesystem에서 모델을 로드합니다. 표준 패턴은 다음과 같습니다: - 컨테이너용으로 학습된 LUIS app version을 export합니다(GZIP). - export된 package를 host에 배치합니다. - volume mount(예: -v hostPath:containerPath)로 컨테이너를 시작하여 컨테이너가 모델 package에 접근할 수 있도록 합니다. 이 접근 방식은 반복 가능한 배포를 지원하며 모범 사례에 부합합니다. 즉, 모델을 versioned artifact로 취급하여 rollback과 환경(dev/test/prod) 전반에서의 일관된 승격을 가능하게 합니다.

파트 5:

app1의 v1.0을 선택합니다.

v1.0을 선택하는 것은 올바르지 않습니다. 요구 사항은 최신 배포 가능한 버전을 사용하는 것이기 때문입니다. v1.0은 학습되고 게시되었지만 v1.1보다 오래된 버전입니다. 컨테이너 시나리오에서는 게시가 필요하지 않으며, 학습이 핵심 선행 조건입니다. v1.1은 더 최근(2020-10-01)에 학습되었고 v1.2는 학습되지 않았으므로, v1.1이 컨테이너로 내보내고 배포할 수 있는 가장 최신 버전입니다. v1.0을 선택하면 필요 이상으로 오래된 모델을 배포하게 되어 “최신 배포 가능한 버전” 요구 사항을 충족하지 못합니다. 따라서 v1.0은 선택하면 안 됩니다.

파트 6:

Export for containers (GZIP) 옵션을 사용하여 모델을 내보냅니다.

“Export for containers (GZIP)”를 사용하여 모델을 내보내는 것은 LUIS를 컨테이너에 배포하기 위한 올바른 내보내기 작업입니다. 이 옵션은 런타임에 필요한 학습된 아티팩트를 포함하는 컨테이너 호환 모델 패키지를 생성합니다. 컨테이너는 이 패키징된 모델 형식을 기대합니다. 이는 작성/가져오기 시나리오를 위한 앱 정의를 내보내는 “Export as JSON” 옵션과는 다르며, “Export as JSON”은 런타임에서 바로 사용할 수 있는 모델이 아닙니다. 올바른 순서에서는 최신 학습 버전(v1.1)을 선택한 후, 컨테이너 내보내기 옵션(GZIP)을 사용하여 해당 버전을 내보냅니다. 이렇게 하면 컨테이너에 마운트하는 아티팩트가 의도한 버전과 일치하며, 컨테이너가 예측을 제공하는 데 사용할 수 있습니다.

파트 7:

app1의 v1.2를 선택합니다.

v1.2를 선택하는 것은 올바르지 않습니다. 배포할 수 없기 때문입니다. 표에 trained date와 published date가 모두 표시되어 있지 않습니다. LUIS 버전은 런타임 사용(컨테이너 포함)을 위해 내보낼 수 있는 모델을 생성하려면 반드시 학습되어야 합니다. 학습이 없으면 내보낼 trained model artifact가 없습니다. v1.2가 숫자상 최신 버전이더라도 배포 가능 요건을 충족하지 않습니다. 문제는 “latest deployable version”을 구체적으로 묻고 있으며, 이는 실제로 배포할 수 있는 가장 최신 버전을 의미합니다. 따라서 v1.2를 선택하면 안 되며, 대신 v1.1을 선택한 다음 컨테이너용으로 export하고 컨테이너를 실행할 때 모델을 mount해야 합니다.

9
문제 9

URL에서 액세스할 수 있는 영수증이 있습니다. Form Recognizer 및 SDK를 사용하여 영수증에서 데이터를 추출해야 합니다. 솔루션은 prebuilt model을 사용해야 합니다. 어떤 client와 method를 사용해야 합니까?

오답입니다. FormRecognizerClient는 analysis를 실행하는 올바른 client이지만, 이 시나리오에서는 StartRecognizeContentFromUri가 잘못된 method입니다. 이 method는 일반적인 content 또는 layout extraction을 수행하며, 사전 구축된 receipt model이 생성하는 receipt 전용 schema보다는 text, tables, document structure에 초점을 둡니다. 문제에서 receipt용 사전 구축된 model을 명시적으로 요구하므로, 일반적인 content-recognition method는 요구 사항을 완전히 충족하지 못합니다. 시험에서는 receipt와 같은 document type이 명시적으로 언급되면 해당하는 사전 구축된 method를 우선 선택해야 합니다.

오답입니다. FormTrainingClient는 사전 구축된 model로 inference를 실행하는 것이 아니라 custom model을 생성, 관리, 학습하는 용도로 사용됩니다. 또한 StartRecognizeContentFromUri는 receipt 전용 사전 구축된 method가 아니므로, 이 선택지는 두 가지 측면에서 틀렸습니다. client도 잘못되었고 method도 잘못되었습니다. training client는 labeled 또는 unlabeled forms로 custom model을 구축하는 시나리오에서만 적절합니다. 이 작업은 사전 구축된 model을 사용해 receipt data를 추출하는 것이므로, 이 선택지는 SDK 사용 패턴에 맞지 않습니다.

정답입니다. FormRecognizerClient는 Form Recognizer SDK에서 analysis 및 inference 작업(사전 구축된 model 호출 포함)에 사용되는 client입니다. 요구 사항은 사전 구축된 receipt model을 사용하는 것이므로, 일반적인 layout 또는 content method가 아니라 receipt 전용 recognition method가 필요합니다. StartRecognizeReceiptsFromUri는 URL에 있는 receipt를 분석하고 merchant name, transaction date, totals, taxes, line items와 같은 구조화된 receipt field를 반환하도록 설계되었습니다. 이는 문제의 두 가지 제약 조건, 즉 SDK를 사용하고 URI 기반 document에 대해 사전 구축된 model을 사용하는 것을 모두 직접 충족합니다.

오답입니다. StartRecognizeReceiptsFromUri는 URL에서 receipt를 분석하기 위한 올바른 receipt 전용 method 이름이지만, 잘못된 client와 짝지어져 있습니다. FormTrainingClient는 사전 구축된 receipt analysis를 호출하는 데 사용되지 않으며, training 및 management와 같은 custom model lifecycle 작업에 사용됩니다. 사전 구축된 extraction 작업의 경우, SDK는 이 작업이 training이 아니라 inference이므로 FormRecognizerClient를 사용합니다. 따라서 method 이름 자체는 관련 있어 보이더라도 이 선택지는 오답입니다.

문제 분석

핵심 개념: 이 문제는 URL(URI)에서 액세스 가능한 영수증에서 prebuilt model을 사용해 구조화된 데이터를 추출하기 위한 Azure Form Recognizer(Azure AI Document Intelligence) SDK 사용을 테스트합니다. 또한 올바른 client 유형(인식/추론 vs 학습)을 선택하는지도 테스트합니다. 정답이 맞는 이유: prebuilt model(예: prebuilt receipt model)을 사용하려면 학습이 아니라 분석/추론을 수행합니다. 레거시 Form Recognizer SDK에서 추론 작업은 FormRecognizerClient로 수행합니다. 영수증의 경우, SDK는 공개적으로 액세스 가능한 URL(또는 SAS URL)에 있는 영수증을 분석하기 위한 전용 method인 StartRecognizeReceiptsFromUri를 제공합니다. 이는 두 요구 사항 (1) prebuilt receipt model 및 (2) URI에서 입력을 가져옴을 모두 충족합니다. 주요 기능 및 모범 사례: - Prebuilt models(영수증, 인보이스, ID document, business card 등)은 학습이 필요 없으며 일반적인 문서 유형에 최적화되어 있습니다. - URI 기반 method는 서비스가 문서를 가져올 수 있어야 합니다. URL이 Azure에서 도달 가능(공개 또는 시간 제한 SAS)한지 확인하세요. 적절한 액세스 없이 private network endpoint만 사용하면 실패합니다. - StartRecognize* 패턴은 분석에 시간이 걸릴 수 있으므로 long-running operation(LRO)입니다. 일반적으로 operation을 await한 다음 결과를 반복 처리합니다. - Azure Well-Architected 관점에서: secrets에는 managed identity/Key Vault를 사용하고, least privilege를 적용하며, resiliency(retry policies) 및 비용(prebuilt model은 페이지당 과금)을 고려하세요. 일반적인 오해: - “Content” method(콘텐츠/레이아웃 인식)는 텍스트와 구조를 추출하지만 영수증 전용 스키마(가맹점명, 합계, 세금, 품목 등)를 적용하지 않습니다. “영수증에서 데이터 추출”을 영수증 필드 관점에서 충족하지 못합니다. - FormTrainingClient는 custom model을 빌드하고 관리(학습, 모델 관리)하기 위한 것입니다. prebuilt receipt 분석을 실행하는 데 사용하지 않습니다. 시험 팁: - 작업 매핑: prebuilt model => FormRecognizerClient(analysis) + prebuilt 전용 method(Receipts/Invoices/BusinessCards/IdDocuments). - 입력이 URL이면 FromUri method를 선택하고, stream/file이면 FromUri가 없는 해당 method를 선택합니다. - 문제가 custom model, labeled data, 또는 model training/management를 언급할 때만 training client가 등장합니다.

10
문제 10

DRAG DROP - 테스트를 위해 로컬 디바이스와 온-프레미스 datacenter에서 Anomaly Detector API의 containerized 버전을 사용할 계획입니다. 다음 요구 사항을 containerized 배포가 충족하도록 해야 합니다: ✑ container를 실행하는 디바이스의 command-line history에 billing 및 API 정보가 저장되지 않도록 방지합니다. ✑ Azure role-based access control (Azure RBAC)을 사용하여 container image에 대한 액세스를 제어합니다. 어떤 네 가지 작업을 순서대로 수행해야 합니까? 답하려면 작업 목록에서 적절한 작업을 답변 영역으로 이동하고 올바른 순서로 정렬하십시오. 참고: 정답 선택지의 순서는 하나 이상이 올바를 수 있습니다. 선택한 올바른 순서에 대해서는 모두 점수를 받습니다. 선택 및 배치:

파트 1:

사용자 지정 Dockerfile을 생성합니다.

명시된 요구 사항을 충족하기 위해 사용자 지정 Dockerfile을 생성할 필요는 없습니다. 목표는 Anomaly Detector container image를 수정하는 것(예: 패키지 추가, entrypoint 변경, 또는 configuration을 image에 포함시키는 것)이 아닙니다. 대신 (1) billing/API 정보를 대화형 command line에 직접 입력하지 않도록 방지(스크립트 또는 environment file/secret 메커니즘을 통해 운영적으로 처리)하고 (2) Azure RBAC를 사용하여 image에 대한 액세스를 제어(Azure Container Registry에 image를 저장하여 처리)해야 합니다. 사용자 지정 Dockerfile은 secrets를 image layer에 포함시키도록 유도할 수 있어 오히려 역효과가 날 수 있는데, 이는 보안 anti-pattern입니다. Microsoft에서 제공하는 container image는 그대로 사용한 다음, re-tagging하여 ACR에 push해야 합니다. 따라서 정답은 아니요입니다.

파트 2:

Anomaly Detector 컨테이너 이미지를 pull합니다.

자체 레지스트리에 다시 호스팅하기 위한 전제 조건으로 Anomaly Detector 컨테이너 이미지를 pull해야 합니다. Azure RBAC를 통해 액세스를 제어해야 한다는 요구 사항은 Azure Container Registry (ACR)를 사용하는 것을 의미합니다. 이미지를 ACR에 push하려면 먼저 로컬(또는 파이프라인)에 이미지가 있어야 ACR 로그인 서버 이름으로 태그를 지정한 다음 push할 수 있습니다. 실제로는 소스 레지스트리(제품 문서에 따라 일반적으로 Microsoft Container Registry)에서 Microsoft 제공 이미지를 pull한 다음, 다시 태그를 지정하고(예: myregistry.azurecr.io/anomalydetector:tag) ACR에 push합니다. 이미지를 pull하지 않으면 이후의 push 단계를 수행할 수 없습니다. 따라서 예가 정답입니다.

파트 3:

docker run 스크립트를 배포합니다.

docker run 스크립트(또는 이에 상응하는 표준화된 실행 메커니즘)를 배포하는 것은 청구(billing) 및 API 정보가 커맨드라인 히스토리에 저장되는 것을 방지해야 한다는 요구사항을 직접적으로 충족합니다. 운영자가 docker run -e Eula=accept -e Billing=... -e ApiKey=... 와 같은 명령을 수동으로 실행하면, 해당 값이 shell history, 터미널 로깅, 또는 프로세스 감사에 의해 캡처될 수 있습니다. 스크립트를 배포하면 컨테이너 시작 방식을 중앙에서 관리할 수 있고, 시크릿을 대화형으로 직접 입력하는 일을 줄이거나 없앨 수 있습니다. 실제 배포에서는 이 스크립트가 보호된 위치(예: shell history 밖에서 설정된 environment variables, env-file, secret store, 또는 보안 구성 관리 도구)에서 값을 읽는 경우가 많습니다. 시험 문항은 “Distribute a docker run script”를 구체적으로 제시하지만, 핵심 의도는 커맨드라인에서 시크릿이 노출되는 것을 피하는 것입니다. 따라서 정답은 예입니다.

파트 4:

이미지를 Azure container registry에 푸시합니다.

Azure RBAC 액세스 제어 요구 사항을 충족하려면 이미지를 Azure container registry에 푸시해야 합니다. ACR은 Azure Active Directory와 통합되며 AcrPull(소비자용) 및 AcrPush(게시자용)와 같은 Azure 역할 할당을 지원합니다. 이를 통해 어떤 사용자/디바이스/ID가 Anomaly Detector container image를 pull할 수 있는지 제어할 수 있으며, 최소 권한 및 중앙 집중식 거버넌스에 부합합니다. 이미지가 ACR에 있으면 온프레미스 디바이스는(예: AAD principal, service principal 또는 기타 지원되는 메커니즘 사용) 인증한 뒤 적절한 역할 할당이 있는 경우에만 이미지를 pull할 수 있습니다. 이것이 public registry와 비교했을 때의 핵심적인 차별점입니다. 따라서 정답은 예입니다.

파트 5:

이미지를 빌드합니다.

이 요구 사항에서는 이미지를 빌드할 필요가 없습니다. 컨테이너 이미지를 커스터마이즈하라는 요청이 아니라, 이에 대한 액세스를 제어하고 명령 기록에 billing/API 세부 정보가 노출되지 않도록 하라는 요청입니다. 이는 기존 이미지를 ACR에 다시 호스팅(빌드 불필요)하고, secrets를 직접 타이핑하지 않도록 표준화된 실행 스크립트(또는 유사한 방식)를 배포함으로써 해결됩니다. “build” 단계는 커스텀 Dockerfile을 만들었거나 다른 방식으로 이미지를 수정한 경우에만 필요합니다. 권장 접근 방식은 vendor가 제공한 이미지를 pull한 다음 re-tag/push하여 ACR에 올리는 것이므로, 빌드는 불필요한 작업이며 복잡성과 위험(예: secrets의 실수로 인한 포함 또는 지원되는 이미지와의 drift)을 추가합니다. 따라서 정답은 아니요입니다.

파트 6:

이미지를 Docker Hub에 push합니다.

이미지를 Docker Hub에 push하는 것은 Azure RBAC를 사용하여 액세스를 제어해야 한다는 요구 사항을 충족하지 않습니다. Docker Hub에는 자체 인증/권한 부여 모델이 있으며, ACR이 제공하는 방식과 동일하게 Azure role assignments(AcrPull/AcrPush) 또는 Azure AD와 통합되지 않습니다. 문제에서 컨테이너 이미지에 대한 액세스를 제어하기 위해 Azure RBAC를 명시적으로 요구하므로, 이는 Azure Container Registry를 가리킵니다. 또한 Docker Hub는 기본적으로 public인 경우가 많고, private repositories를 사용하더라도 “Azure RBAC 사용” 요구 사항을 충족하지 못합니다. 시험 관점에서 올바른 registry 선택은 ACR입니다. 따라서 정답은 아니요입니다.

다른 모의고사

Practice Test #1

50 문제·100분·합격 700/1000

Practice Test #2

50 문제·100분·합격 700/1000
← 모든 Microsoft AI-102 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 Microsoft AI-102 기출 문제를 풀어보세요.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

FAQ개인정보 처리방침서비스 약관

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

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

앱 받기

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