CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
  1. Cloud Pass
  2. Microsoft
  3. Microsoft AI-102
Microsoft AI-102

Microsoft

Microsoft AI-102

306+ 기출 문제 (AI 검증 답안 포함)

Designing and Implementing a Microsoft Azure AI Solution

Free questions & answers실제 시험 기출 문제
AI-powered explanations상세 해설
Real exam-style questions실제 시험과 가장 유사
306+ 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

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

시험 도메인

Plan and Manage an Azure AI Solution출제율 23%
Implement Generative AI Solutions출제율 18%
Implement an Agentic Solution출제율 8%
Implement Computer Vision Solutions출제율 13%
Implement Natural Language Processing Solutions출제율 19%
Implement Knowledge Mining and Information Extraction Solutions출제율 19%

실전 문제

1
문제 1

DRAG DROP - 각각 고유한 Language Understanding 모델을 가진 챗봇이 100개 있습니다. 자주 각 모델에 동일한 구문을 추가해야 합니다. 새 구문을 포함하도록 Language Understanding 모델을 프로그래밍 방식으로 업데이트해야 합니다. 코드를 어떻게 완성해야 합니까? 답하려면 적절한 값을 올바른 대상에 끌어다 놓으십시오. 각 값은 한 번, 여러 번 또는 전혀 사용하지 않을 수 있습니다. 콘텐츠를 보려면 창 사이의 분할 막대를 끌거나 스크롤해야 할 수 있습니다. 참고: 각 정답 선택은 1점입니다. 선택 및 배치:

파트 1:

var phraselistId = await client.Features.______

빈칸은 client.Features.______ 뒤에 오므로, phrase list 식별자를 반환하는 Features operations group의 메서드여야 합니다. LUIS Authoring SDK에서 phrase list는 Features 아래에서 관리되며, 새로운 phrase list feature를 생성하는 데 사용되는 메서드는 AddPhraseListAsync이고, 이는 생성된 phrase list ID(일반적으로 integer)를 반환합니다. 이는 변수명 phraselistId 및 await 사용과 일치합니다. 다른 선택지가 틀린 이유: - Phraselist와 Phrases는 메서드가 아니며, property 이름처럼 보이므로 client.Features.<method> 구문에 맞지 않습니다. - PhraselistCreateObject는 인자로 사용되는 type이지, 메서드가 아닙니다. - SavePhraselistAsync는 기존 phrase list를 업데이트하는 데 사용되며(ID가 필요), 처음 ID를 얻기 위한 용도가 아닙니다. - UploadPhraseListAsync는 이 맥락에서 Authoring SDK의 표준 LUIS phrase list 생성 호출이 아닙니다.

파트 2:

(appId, versionId, new ______

스니펫은 다음을 보여줍니다: (appId, versionId, new ______. 이는 코드가 API 호출에 전달하기 위해 new 키워드로 객체를 인스턴스화하고 있음을 의미합니다. Authoring SDK를 통해 LUIS에서 phrase list를 생성할 때, 요청 본문은 PhraselistCreateObject(Name, Phrases, IsExchangeable 등의 속성을 포함하는 DTO)로 표현됩니다. 따라서 new PhraselistCreateObject가 올바른 완성입니다. 다른 선택지가 틀린 이유: - AddPhraseListAsync와 SavePhraselistAsync는 메서드이며, new로 인스턴스화하는 타입이 아닙니다. - Phraselist와 Phrases는 올바른 요청 객체 타입이 아닙니다. Phrases는 일반적으로 create object 내부의 속성(예: SDK 버전에 따라 콤마로 구분된 문자열 또는 리스트)입니다. - UploadPhraseListAsync는 메서드이며 new 뒤에 올 수 없습니다. 실무에서는 Phrases 필드에 공유할 구문들을 채운 다음, 앱/버전별로 AddPhraseListAsync를 호출하고, 필요하다면 학습/게시를 수행합니다.

2
문제 2

다음 요구 사항을 충족하는 chatbot을 구축해야 합니다: ✑ chit-chat, knowledge base, 그리고 multilingual models를 지원 ✑ 사용자 메시지에 대해 sentiment analysis를 수행 ✑ 최적의 language model을 자동으로 선택 chatbot에 무엇을 통합해야 합니까?

QnA Maker는 knowledge base 응답을 지원하고 chit-chat 콘텐츠를 포함할 수 있으며, Language Understanding은 intent 식별을 돕습니다. Dispatch는 여러 model 간에 요청을 라우팅할 수 있으므로 이 선택지는 chatbot orchestration을 부분적으로 충족합니다. 그러나 sentiment analysis에 필요한 Azure 서비스인 Text Analytics가 포함되어 있지 않습니다. sentiment analysis가 명시적으로 요구되므로 이 선택지는 불완전합니다.

Translator는 다국어 시나리오를 지원하고 Speech는 음성 기반 입력 및 출력을 지원하며, Dispatch는 utterance를 서로 다른 model로 라우팅할 수 있습니다. 그러나 음성 상호작용이 명시적으로 필요하지 않은 이상 Speech는 제시된 요구 사항과 관련이 없습니다. 이 선택지에는 sentiment analysis를 위한 Text Analytics도 없고, QnA Maker와 같은 knowledge base 기능도 포함되어 있지 않습니다. 따라서 전체 요구 사항을 충족하지 못합니다.

Language Understanding은 intent를 식별할 수 있고, Text Analytics는 sentiment analysis를 수행하며, QnA Maker는 knowledge base 및 chit-chat 시나리오를 지원합니다. 그러나 이 선택지에는 여러 language model 또는 knowledge source 중에서 최적의 model을 자동 선택하는 데 사용되는 Azure 구성 요소인 Dispatch가 포함되어 있지 않습니다. LUIS 자체는 하나의 model 내에서 intent recognition을 수행하지만, 여러 model 중에서 선택하는 기존 routing mechanism은 아닙니다. 자동 model 선택이 명시적으로 요구되므로 이 선택지는 최적의 답이 아닙니다.

Text Analytics는 sentiment analysis에 사용되는 Azure 서비스이므로 사용자 메시지를 분석해야 한다는 요구 사항을 충족합니다. Translator는 언어 간 텍스트를 번역하여 다국어 지원을 제공하므로 chatbot의 다국어 요구 사항을 해결합니다. Dispatch는 utterance를 올바른 LUIS app 또는 QnA Maker knowledge base와 같은 가장 적절한 model로 라우팅하는 데 특화되어 있으므로, 최적의 language model을 자동으로 선택해야 한다는 요구 사항과 일치합니다. 이 선택지에 QnA Maker가 명시적으로 포함되어 있지는 않지만, 문제에서 강조하는 세 가지 기능인 sentiment, 다국어 지원, 자동 model 선택을 모두 포괄하는 유일한 선택지입니다.

문제 분석

핵심 개념: 이 문제는 다국어 상호작용을 지원하고, sentiment를 분석하며, 사용자 utterance를 가장 적절한 language model로 자동 라우팅해야 하는 chatbot에 적합한 Azure 서비스를 선택하는 것에 관한 것입니다. 기존 Azure Bot Framework 아키텍처에서는 어떤 downstream model 또는 knowledge source가 utterance를 처리해야 하는지 결정하기 위해 Dispatch를 사용하고, sentiment analysis는 Text Analytics가 제공하며, 다국어 지원은 Translator가 제공합니다. 정답인 이유: "최적의 language model을 자동으로 선택"해야 한다는 요구 사항은 여러 LUIS app과 QnA Maker knowledge base 전반에서 utterance를 라우팅하도록 설계된 Dispatch를 직접적으로 가리킵니다. sentiment analysis는 Text Analytics가 제공하고, 다국어 지원은 Translator가 제공합니다. 제공된 선택지 중 이러한 세 가지 필수 기능을 모두 포함하는 것은 D뿐입니다. 주요 기능: - Text Analytics는 들어오는 사용자 메시지에 대해 sentiment analysis를 수행합니다. - Translator는 언어 간 텍스트를 번역하여 다국어 대화를 가능하게 합니다. - Dispatch는 utterance를 가장 적절한 language understanding model 또는 knowledge source로 라우팅합니다. 이러한 서비스는 여러 언어와 여러 NLP back end를 지원해야 하는 bot에서 일반적으로 함께 사용됩니다. 흔한 오해: 자주 하는 실수는 QnA Maker와 LUIS를 선택하는 것인데, 둘 다 핵심 chatbot 서비스이지만 sentiment analysis는 수행하지 않습니다. 또 다른 흔한 혼동은 LUIS만으로 여러 model 중에서 자동 선택이 가능하다고 생각하는 것입니다. Azure의 기존 아키텍처에서 이 목적의 routing layer는 Dispatch입니다. QnA Maker는 chit-chat을 지원할 수 있지만, 이 문제는 자동 model 선택과 다국어 지원을 더 직접적으로 강조합니다. 시험 팁: - sentiment analysis = Text Analytics. - 다국어 번역 = Translator. - language/intent model 간 자동 라우팅 = Dispatch. - QnA Maker는 FAQ/KB 응답용이지만, 선택지에 필요한 sentiment 또는 translation 기능이 없으면 불완전합니다.

3
문제 3

당신은 e-commerce 플랫폼을 위한 Language Understanding 모델을 구축하고 있습니다. 청구지 주소를 캡처하기 위한 entity를 구성해야 합니다. 청구지 주소에 어떤 entity type을 사용해야 합니까?

Machine learned entity는 가변적인 자연어 입력을 위해 설계되었으며 라벨링된 예시로부터 일반화할 수 있습니다. 청구지 주소는 유효한 형식과 구성요소가 매우 다양하므로, street, city, region, postal code, country 같은 sub-entity를 포함한 machine learned(종종 composite) entity에 이상적입니다. 이 접근 방식은 지역 전반으로 확장 가능하며, 패턴 기반 추출에 비해 취약한 규칙 유지보수를 줄여줍니다.

Regex entity는 일관된 형식의 문자열(예: invoice number, order ID, 엄격한 패턴의 phone number)에 가장 적합합니다. 주소는 국가 간은 물론 한 국가 내에서도(약어, 동/호수 표기, 구두점, 순서) 형식이 일관되지 않습니다. regex 기반 접근은 복잡하고 오류가 발생하기 쉬우며 유지보수가 어려워, 프로덕션 NLU에서 신뢰성이 떨어집니다.

geographyV2는 도시, 국가/지역 등 지리 개념과 기타 위치 관련 용어에 초점을 둔 prebuilt entity입니다. street line, unit number, postal code를 포함한 완전한 우편/청구지 주소를 하나의 구조화된 entity로 신뢰성 있게 추출하지 못합니다. sub-entity(예: city/country 추출)로는 도움이 될 수 있지만, 전체 청구지 주소에 대한 최적의 primary entity type은 아닙니다.

Pattern.any는 자유 형식 텍스트 구간을 캡처할 때 사용되며, 종종 utterance의 나머지 부분을 세부 구조 없이 가져오고자 할 때(예: 짧은 설명) 사용됩니다. 주소 구성요소를 구조적으로 추출하지 못하고 관련 없는 단어까지 과도하게 캡처할 수 있습니다. 청구지 주소는 downstream 처리를 위해 구조화된 필드가 필요한 경우가 일반적이므로, machine learned entity로 더 잘 달성됩니다.

List entity는 알려진 값과 동의어로 이루어진 닫힌 유한 집합(예: 지원 결제 수단: Visa, MasterCard, PayPal)에 적합합니다. 청구지 주소는 사실상 무한하며 사용자별로 달라지므로 list entity는 현실적으로 불가능합니다. 가능한 주소 목록을 유지하는 것은 불가능하고, 사용자가 입력하는 새로운 주소로 일반화되지도 않습니다.

문제 분석

핵심 개념: 이 문제는 Language Understanding (LUIS / Conversational Language Understanding)에서의 entity 설계를 다룹니다. Entity는 사용자 utterance에서 구조화된 데이터(슬롯)를 추출하는 방식입니다. 올바른 entity type을 선택하면 정확도, 유지보수성, 그리고 모델의 일반화 성능에 영향을 줍니다. 정답이 맞는 이유: 청구지 주소는 복잡하고 가변적이며 여러 부분으로 구성된 개념(번지/건물번호, 도로명, 동/호수, 도시, 주/도, 우편번호, 국가)이고, 지역에 따라 다양한 형식으로 표현될 수 있습니다. machine learned entity가 가장 적합한데, 라벨링된 예시로부터 학습하여 보지 못한 주소 변형에도 일반화할 수 있기 때문입니다. 실제로는 “BillingAddress”를 child entity(Street, City, Region, PostalCode, Country)로 구성된 composite machine learned entity로 모델링하여 구조를 캡처하는 경우가 많습니다. 주요 특징 / Best Practices: - machine learned entity(종종 composite)를 사용하고, 다양한 주소 형식(US, EU, APAC), 약어, 구두점 등을 포함하는 여러 예시를 라벨링합니다. - downstream에서 필요한 구성요소(세금 계산, 배송 검증, 사기 탐지)를 위해 sub-entity를 추가하는 것을 고려합니다. - NLU layer 외부에서의 validation(예: address verification services)과 결합합니다. NLU 추출은 우편 주소 검증과 동일하지 않기 때문입니다. - Azure Well-Architected 관점에서 이는 Reliability와 Operational Excellence를 향상시킵니다. 모델이 새로운 형식에 더 탄력적이며, 취약한 패턴보다 진화시키기 쉽습니다. 흔한 오해: Regex는 주소가 “구조화되어 보이기” 때문에 매력적으로 보일 수 있지만, 실제 주소는 변형이 너무 많아 regex가 취약하고 유지보수가 어렵습니다. prebuilt geography entity(geographyV2)는 위치(도시, 국가, 관심 지점)에 초점을 맞추며, 전체 우편 주소를 다루지 않습니다. list entity는 닫힌 집합에만 적합한데, 주소는 그렇지 않습니다. 시험 팁: - 개방형이며 변동이 큰 사용자 입력에는 machine learned entity를 사용합니다. - 고정된 어휘 집합(예: 결제 수단 유형)에는 list entity를 사용합니다. - 형식이 일관된 강한 패턴의 문자열(주문 ID, SKU)에는 regex entity를 사용합니다. - prebuilt entity는 정확히 해당 개념과 일치할 때 가장 좋습니다(예: 날짜에는 datetimeV2). 하지만 전체 주소처럼 복잡한 다중 필드 개념에 대한 모델링을 대체하지는 못합니다.

4
문제 4

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 시리즈의 각 질문에는 명시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 두 개 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션의 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. Language Understanding service를 사용하여 language model을 빌드합니다. 이 language model은 FindContact라는 intent를 사용하여 연락처 목록에서 정보를 검색하는 데 사용됩니다. 대화형 전문가가 학습에 사용할 다음 phrase 목록을 제공합니다. ✑ London의 연락처를 찾아줘. ✑ Seattle에 아는 사람이 누구야? ✑ Ukraine의 연락처를 검색해줘. Language Understanding에서 phrase list를 구현해야 합니다. 솔루션: location에 대한 새 intent를 생성합니다. 이것이 목표를 충족합니까?

Yes는 LUIS의 phrase list가 새로운 intent를 만들어 구현되는 것이 아니기 때문에 오답입니다. intent는 사용자가 무엇을 하려는지 분류하는 데 사용되며, 제공된 모든 utterance는 분명히 FindContact intent에 속합니다. London, Seattle, Ukraine는 location 정보의 예시이며, 다른 intent로 분리하는 대신 entity를 통해 추출해야 합니다. location에 대해 새로운 intent를 사용하면 모델을 혼란스럽게 하고 제시된 설계 목표를 충족하지 못합니다.

No가 정답인 이유는 location에 대해 새로운 intent를 만드는 것이 phrase list를 올바르게 구현해야 한다는 요구 사항을 충족하지 못하기 때문입니다. 모든 샘플 utterance에서 사용자의 목표는 여전히 FindContact이므로 intent는 변경되지 않아야 합니다. London, Seattle, Ukraine와 같은 가변 용어는 entity로 캡처해야 하는 location 값이며, 필요에 따라 phrase list feature의 지원을 받을 수 있습니다. 별도의 Location intent를 만드는 것은 데이터 값을 사용자 목표로 잘못 모델링하는 것이며 intent classification의 효과를 떨어뜨립니다.

문제 분석

핵심 개념: 이 문제는 동일한 intent 또는 entity 컨텍스트 내에서 관련 단어의 인식을 향상시키기 위해 Language Understanding (LUIS)에서 phrase list를 사용하는 방법에 대한 이해를 평가합니다. phrase list는 새로운 intent를 만드는 것이 아니라, 서로 대체 가능하거나 관련된 용어의 중요도를 높이는 데 사용되는 feature입니다. 이 시나리오에서 utterance들은 모두 동일한 사용자 목표인 연락처 찾기를 표현하며, city 또는 country는 추출해야 하는 가변 데이터입니다. 정답인 이유: 이 솔루션은 목표를 충족하지 못합니다. location에 대해 새로운 intent를 만드는 것은 잘못된 모델링 선택이기 때문입니다. "Find contacts in London," "Who do I know in Seattle?" 및 "Search for contacts in Ukraine"는 모두 기존 FindContact intent에 매핑됩니다. location 값은 entity로 처리해야 하며, 필요한 경우 phrase list를 사용하여 location 관련 vocabulary의 인식을 향상시킬 수 있습니다. 주요 기능: LUIS의 phrase list는 모델이 관련 단어를 인식하고 예측 정확도를 향상시키는 데 도움이 되는 feature 힌트로 작동합니다. intent는 사용자의 목표를 나타내고, entity는 location과 같은 매개변수를 캡처합니다. 이 경우 location은 별도의 intent가 아니라 geographical location과 같은 entity로 모델링해야 합니다. 일반적인 오해: 흔한 실수는 utterance에서 중요한 모든 명사나 keyword마다 새로운 intent를 만드는 것입니다. 그러나 intent는 데이터 값이 아니라 작업 또는 목표를 나타내야 합니다. 또 다른 오해는 phrase list가 entity를 대체한다는 것입니다. 실제로 phrase list는 모델을 지원하고, entity는 실제 값을 추출합니다. 시험 팁: AI-102에서는 여러 utterance가 동일한 작업을 표현하지만 이름, 날짜 또는 장소와 같은 세부 사항만 다른 경우, 하나의 intent를 유지하고 달라지는 부분은 entity로 추출해야 합니다. 관련 용어의 인식을 향상시키기 위해 phrase list를 사용하되, 사용자의 목표가 실제로 다른 경우가 아니라면 새로운 intent를 만들지 마세요.

5
문제 5

HOTSPOT - 감정 분석 및 광학 문자 인식(OCR)을 수행하는 데 사용할 새 리소스를 만들어야 합니다. 솔루션은 다음 요구 사항을 충족해야 합니다. ✑ 단일 키와 엔드포인트를 사용하여 여러 서비스에 액세스합니다. ✑ 향후 사용할 수 있는 서비스에 대한 청구를 통합합니다. ✑ 향후 Computer Vision 사용을 지원합니다. 새 리소스를 만들기 위해 HTTP 요청을 어떻게 완료해야 합니까? 답하려면 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택은 1점입니다. 핫 영역:

파트 1:

______ https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/RG1/providers/Microsoft.CognitiveServices/accounts/CS1?api-version=2017-04-18

올바른 verb는 PUT입니다. 요청이 리소스 이름(…/accounts/CS1)을 포함하는 특정 resource ID를 대상으로 하기 때문입니다. Azure Resource Manager에서 PUT은 해당 정확한 URI에서 새 리소스를 생성하거나 기존 리소스를 완전히 교체하는 데 사용되며, idempotent합니다(요청을 반복해도 동일한 리소스 상태가 됩니다). 이는 Microsoft.CognitiveServices/accounts와 같은 리소스를 프로비저닝할 때의 표준 패턴입니다. POST는 여기서 올바르지 않습니다. POST는 일반적으로 서비스가 하위 리소스를 생성하고/또는 identifier를 생성하는 경우, 또는 작업을 호출하는 경우(예: /listKeys, /regenerateKey 또는 기타 action endpoint)에 사용됩니다. PATCH는 기존 리소스를 부분적으로 업데이트하는 데 사용되며(예: tags 또는 특정 속성 수정), 고정된 resource URI에서 완전히 새로운 리소스를 생성하는 일반적인 방법이 아닙니다. 따라서 management endpoint를 통해 CS1을 생성하려면 PUT을 사용합니다.

파트 2:

"kind": "______",

"kind" 속성의 올바른 값은 "CognitiveServices"입니다. 요구 사항에서 다음을 명시적으로 요구하기 때문입니다: 1) 여러 서비스를 액세스하기 위한 단일 key 및 endpoint, 2) 향후 서비스에 대한 통합 청구, 그리고 3) 향후 Computer Vision 지원. "CognitiveServices"는 multi-service Azure AI resource(multi-service account)를 의미합니다. 이 resource type은 동일한 account 하에서 여러 Azure AI services 전반에 걸쳐 사용할 수 있는 하나의 endpoint/keys를 제공하도록 설계되어 있어, 통합 및 향후 확장 요구 사항을 직접 충족합니다. "TextAnalytics"는 language 기능(예: sentiment analysis)으로 제한된 single-service resource를 생성하며, OCR 또는 향후 Computer Vision에 대해 동일한 endpoint/key를 사용해야 한다는 요구 사항을 충족하지 못합니다. "ComputerVision" 역시 single-service이며, 동일한 endpoint/key 하에서 sentiment analysis를 포함하지 못합니다. 따라서 모든 요구 사항과 일치하는 유일한 선택지는 "kind": "CognitiveServices"입니다.

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

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

6
문제 6

다음 HTTP 요청을 성공적으로 실행합니다. POST https://management.azure.com/subscriptions/18c51a87-3a69-47a8-aedc-a54745f708a1/resourceGroups/RG1/providers/ Microsoft.CognitiveServices/accounts/contoso1/regenerateKey?api-version=2017-04-18 Body{"keyName": "Key2"} 요청의 결과는 무엇입니까?

오답입니다. regenerateKey ARM 작업은 리소스 자체에서 Cognitive Services 계정 키를 재생성할 뿐이며, Azure Key Vault에서 secret을 자동으로 생성하거나 업데이트하지 않습니다. Key Vault 통합은 별도로 구현하는 모범 사례입니다(예: 반환된 키를 secret으로 저장하거나 자동화를 사용). 표시된 요청은 Key Vault API가 아니라 management.azure.com 및 CognitiveServices provider를 대상으로 합니다.

오답입니다. “Query keys”는 Azure AI Search(이전 Azure Cognitive Search)와 관련되며 Search 서비스 API를 통해 관리되며, Microsoft.CognitiveServices/accounts/regenerateKey를 통해 관리되지 않습니다. Cognitive Services 계정은 서비스 endpoint에 대한 인증에 subscription keys(Key1/Key2)를 사용합니다. 요청 본문은 query key가 아니라 계정 키인 Key2를 명시적으로 참조합니다.

오답입니다. 두 키를 모두 교체하려면 두 번의 별도 호출이 필요합니다. 하나는 keyName=Key1, 다른 하나는 keyName=Key2로 호출해야 합니다(또는 둘 다를 교체하는 명시적 작업이 필요하지만 이 API에는 없습니다). regenerateKey 작업은 지정된 키만 재생성합니다. 요청이 Key2를 지정하므로 보조 키만 변경되고 Key1은 유효하며 변경되지 않습니다.

정답입니다. 이 요청은 {"keyName":"Key2"}로 Cognitive Services 계정 작업 regenerateKey를 호출합니다. Cognitive Services 계정에는 두 개의 키(Key1 및 Key2)가 있습니다. Key2를 재생성하면 보조 subscription key가 재설정되어 기존 Key2가 무효화되고 새 Key2 값이 반환됩니다. 이는 연속성을 위해 Key1을 변경하지 않은 채 표준 키 교체 관행을 지원합니다.

문제 분석

핵심 개념: 이 문제는 Azure Resource Manager (ARM) REST API를 사용하여 Azure Cognitive Services (Azure AI services) 계정에 대해 management-plane 키 교체를 테스트합니다. Cognitive Services 계정은 클라이언트 애플리케이션이 data-plane endpoint에 인증하는 데 사용하는 두 개의 access key(Key1 및 Key2)를 노출합니다. ARM 작업 regenerateKey는 이러한 계정 키 중 하나를 교체(rotate)하기 위한 것입니다. 정답인 이유: 요청은 다음을 호출합니다. POST .../Microsoft.CognitiveServices/accounts/contoso1/regenerateKey?api-version=2017-04-18 본문 {"keyName":"Key2"}와 함께. Cognitive Services에서 Key1은 일반적으로 primary key로, Key2는 secondary key로 취급됩니다. regenerateKey 작업은 지정된 키만 재생성(재설정)합니다. keyName이 Key2이므로, 서비스는 기존 Key2를 무효화하고 새로 생성된 Key2 값을 반환합니다. Key1은 변경되지 않습니다. 따라서 결과는 보조 subscription key가 재설정되었다는 것입니다. 주요 기능 / 모범 사례: 두 개의 키를 사용하면 다운타임을 최소화하면서 안전하게 키를 교체할 수 있습니다. 즉, 애플리케이션을 교체되지 않은 키를 사용하도록 업데이트한 다음 다른 키를 재생성하고, 이후 전환하여 반복합니다. 이는 Azure Well-Architected Framework 보안 지침(자격 증명 교체, least privilege, secret 위생)과 일치합니다. 프로덕션에서는 키를 Azure Key Vault에 저장하고 앱에서 이를 참조하는 것이 좋습니다(가능하면 managed identities 사용). 그러나 regenerateKey 호출 자체는 Key Vault에 secret을 생성하거나 저장하지 않습니다. 일반적인 오해: 일부는 “regenerateKey”를 두 키 모두를 교체하는 것으로 혼동하지만, 이는 이름으로 지정된 키만 대상으로 합니다. 또 다른 혼동은 Cognitive Services 계정 키를 “query keys”(Azure AI Search와 관련된 개념)와 혼동하는 것인데, 이는 서로 다른 리소스와 API입니다. 시험 팁: management-plane과 data-plane 작업을 구분하십시오. management.azure.com에서 regenerateKey 같은 provider action을 호출하는 것은 리소스 구성/자격 증명에 영향을 주는 ARM 작업입니다. 또한 두 키 교체 패턴을 기억하십시오. Key1 또는 Key2를 지정하면 해당 키만 변경됩니다. 질문에 Key Vault가 언급되면, 이는 일반적으로 별도의 단계(예: secret 저장/읽기)이며 키 재생성의 자동 결과가 아닙니다.

7
문제 7

HOTSPOT - 텍스트 분석에 사용될 Azure Cognitive Services 서비스의 컨테이너화된 버전을 배포할 계획입니다. 서비스의 endpoint URI로 https://contoso.cognitiveservices.azure.com 을 구성하고, Text Analytics Sentiment Analysis 컨테이너의 최신 버전을 pull합니다. Docker를 사용하여 Azure virtual machine에서 컨테이너를 실행해야 합니다. 명령을 어떻게 완성해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택은 1점입니다. 핫 영역:

파트 1:

docker run --rm -it -p 5000:5000 --memory 8g --cpus 1 \ ______ \

docker run 명령에서 빈칸(백슬래시 바로 뒤)은 container image 참조가 들어가는 위치입니다. 시나리오에서 Text Analytics Sentiment Analysis container의 최신 버전을 pull했다고 했으므로, 올바른 image는 sentiment container인 mcr.microsoft.com/azure-cognitive-services/textanalytics/sentiment(옵션 D)입니다. 다른 선택지가 틀린 이유: - A(http://contoso.blob.core.windows.net)는 Azure Storage endpoint이며, container image가 아닙니다. - B(https://contoso.cognitiveservices.azure.com)는 Billing에 사용되는 Azure AI resource endpoint이며, image가 아닙니다. - C는 다른 Text Analytics container(key phrase extraction)로, sentiment analysis 요구사항과 일치하지 않습니다. 시험에서는 “container X를 pull했다”를 해당 MCR image 이름에 항상 매핑하세요. image는 docker run의 마지막 인자(또는 environment variables/flags 뒤)에 위치합니다.

파트 2:

Eula=accept \ Billing= ______ \

Billing 매개변수는 컨테이너 사용량을 측정(metering)하는 데 사용할 Azure AI 리소스의 endpoint URI로 설정해야 합니다. 문제에서 endpoint URI가 https://contoso.cognitiveservices.azure.com 로 구성되어 있다고 명시하므로, Billing은 해당 값이어야 합니다(Option B). 다른 선택지가 틀린 이유: - A는 Azure Blob Storage endpoint이며 Azure AI 컨테이너 billing에 사용되지 않습니다. - C와 D는 컨테이너 image 이름이며 billing endpoint가 아닙니다. 시험 팁: Azure AI 컨테이너는 일반적으로 최소한 Eula=accept, Billing=<cognitiveservices endpoint>, ApiKey=<key>가 필요합니다. hotspot에 ApiKey가 표시되지 않더라도, Billing은 거의 항상 https://<resource>.cognitiveservices.azure.com(또는 해당 리소스에서 사용하는 regional endpoint 형식)을 가리킵니다.

8
문제 8

DRAG DROP - Face API를 사용하여 샘플 이미지 기반으로 특정 인물의 사진을 찾는 사진 애플리케이션을 개발하고 있습니다. 사진을 찾기 위한 POST 요청을 생성해야 합니다. 요청을 어떻게 완성해야 합니까? 답하려면 적절한 값을 올바른 대상에 끌어다 놓으십시오. 각 값은 한 번, 여러 번 또는 전혀 사용하지 않을 수 있습니다. 콘텐츠를 보려면 창 사이의 분할 막대를 끌거나 스크롤해야 할 수 있습니다. 참고: 각 올바른 선택은 1점입니다. 선택 및 배치:

파트 1:

POST {Endpoint}/face/v1.0/______

올바른 endpoint는 POST {Endpoint}/face/v1.0/findsimilars입니다. Find Similar API는 query face (faceId)를 입력으로 받아, 지정된 faceListId/largeFaceListId(또는 일부 구성에서는 candidate faceIds 집합)에서 유사한 얼굴을 검색하도록 설계되었습니다. 이는 각 저장된 사진이 face list에서 연관된 persistedFaceId를 가질 수 있고, API가 가장 가까운 매칭을 반환하기 때문에 “샘플 이미지 기반으로 한 사람의 사진을 찾기” 요구사항과 일치합니다. 다른 선택지가 틀린 이유: detect는 얼굴을 추출하고 faceId(들)를 반환할 뿐 검색은 하지 않습니다. identify는 PersonGroup/LargePersonGroup에 대해 사람을 식별( personId 후보 반환)하는 용도이며, 유사한 사진을 직접 찾는 것과는 다른 워크플로우입니다. verify는 두 얼굴(또는 face vs person)을 비교하여 yes/no 신뢰도를 제공할 뿐 검색이 아닙니다. group은 알 수 없는 얼굴들을 그룹으로 클러스터링할 뿐, 특정 대상 검색이 아닙니다. matchFace/matchPerson은 endpoint가 아니라 findsimilars의 “mode” property 값입니다.

파트 2:

"mode": "______"

요청 본문 속성의 올바른 값은 "mode": "matchFace"입니다. Face API Find Similar 요청에서 “mode”는 매칭 전략을 결정합니다. matchFace는 쿼리 face와 유사하게 보이는 face를 찾고자 할 때 사용되며, FaceList/LargeFaceList에서 매칭되는 사진(각 사진에는 face entry가 있음)을 반환하는 데 이상적입니다. 이는 출력이 유사한 face의 순위가 매겨진 목록이어야 하는 사진 검색 경험과 일치합니다. 다른 옵션이 틀린 이유: detect/findsimilars/group/identify/verify는 작업/endpoint이며, “mode” 필드에 대한 유효한 값이 아닙니다. "matchPerson"은 유효한 mode이지만, 개별 face가 아니라 persons(집계된 identity)에 대해 매칭하고자 할 때 사용됩니다. 이는 person-level 매칭 시나리오에 더 부합하며 일반적으로 다른 데이터 구성과 함께 사용됩니다. “사진 찾기”에는 face-level 매칭(matchFace)이 가장 적절합니다.

9
문제 9

HOTSPOT - Face API를 사용하는 애플리케이션을 개발합니다. person group에 여러 이미지를 추가해야 합니다. 코드를 어떻게 완성해야 합니까? 답하려면 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택은 1점입니다. 핫 영역:

파트 1:

using (______ t = File.OpenRead(imagePath))

빈칸은 C# using 문에서 사용하는 변수 타입입니다: using (______ t = File.OpenRead(imagePath)). File.OpenRead(string path)는 FileStream을 반환하며, FileStream은 Stream을 상속합니다. 따라서 선언해야 하는 올바른 타입은 Stream입니다. 다른 선택지가 틀린 이유: - A. File은 System.IO의 static helper class이므로 File 타입의 변수를 선언하지 않습니다. - C. Uri는 URI/URL 값을 나타내며, OpenRead가 반환하는 file stream이 아닙니다. - D. Url은 이 시나리오에서 사용하는 표준 .NET 타입이 아닙니다. Face API 시나리오에서는 이미지가 로컬에 저장되어 있거나, private blob에 있거나, 또는 공개적으로 접근 가능하지 않은 경우 Stream을 사용하는 것이 일반적입니다. 또한 이미지를 인터넷에서 접근 가능한 URL로 만들 필요가 없어 보안 측면에서 더 나을 수 있습니다.

파트 2:

await faceClient.PersonGroupPerson.______(personGroupId, personId, t);

주어진 코드에서 stream 변수(t)를 메서드 호출에 전달하므로, 올바른 SDK 메서드는 AddFaceFromStreamAsync(personGroupId, personId, t)입니다. 이 메서드는 Stream에서 이미지 바이트를 업로드하여 지정된 person group의 지정된 person에 persisted face를 추가합니다. 다른 선택지가 틀린 이유: - B. AddFaceFromUrlAsync는 Stream이 아니라 URL 문자열(또는 URL을 포함한 요청)이 필요합니다. - C. CreateAsync는 리소스(예: person 생성)를 만들 때 사용하며, face 이미지를 추가하는 용도가 아닙니다. - D. GetAsync는 기존 리소스/metadata를 조회하는 메서드로, training 이미지를 추가하지 않습니다. 시험 팁: 여러 face를 추가한 후에는 일반적으로 PersonGroup.TrainAsync를 호출하고 training status를 폴링합니다. 또한 각 이미지에 감지 가능한 face가 포함되어 있어야 하며, 그렇지 않으면 add 작업이 실패합니다.

10
문제 10

HOTSPOT - Computer Vision client library를 사용할 애플리케이션을 개발하고 있습니다. 애플리케이션에는 다음 코드가 있습니다.

public async TaskAnalyzeImage(ComputerVisionClient client, string localImage)
{
    List features = new List()
    {
        VisualFeatureTypes.Description,
        VisualFeatureTypes.Tags,
    };
    using (Stream imageStream = File.OpenRead(localImage))
    {
        try
        {
            ImageAnalysis results = await client.AnalyzeImageInStreamAsync(imageStream, features);

            foreach (var caption in results.Description.Captions)
            {
                Console.WriteLine($"{caption.Text} with confidence {caption.Confidence}");
            }

            foreach (var tag in results.Tags)
            {
                Console.WriteLine($"{tag.Name} {tag.Confidence}");
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
    }
}

다음 각 문에 대해, 문이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:

파트 1:

이 코드는 얼굴 인식을 수행합니다.

아니요. 이 코드는 얼굴 인식을 수행하지 않습니다. features에 VisualFeatureTypes.Description와 VisualFeatureTypes.Tags만 포함한 상태로 client.AnalyzeImageInStreamAsync(imageStream, features)를 호출합니다. 해당 작업은 캡션과 태그를 포함하는 일반적인 ImageAnalysis 결과를 반환하며, 신원(Identity) 인식은 반환하지 않습니다. 얼굴 인식(사람을 식별하는 것)은 이 호출로 제공되지 않으며, Azure에서는 일반적으로 전용 Azure AI Face service(또는 특정 얼굴 관련 기능/endpoint)로 처리합니다. 이는 얼굴을 감지한 다음 person group 또는 유사한 구성에 대해 verify/identify를 수행하는 방식입니다. 얼굴 감지(얼굴 사각형/속성 찾기)조차도 얼굴 관련 출력 요청 또는 적절한 API 사용이 필요하며, Description/Tags를 요청하는 것만으로는 암시되지 않습니다. 따라서 이 코드가 얼굴 인식을 수행한다는 진술은 올바르지 않습니다.

파트 2:

이 코드는 태그와 해당 신뢰도(confidence)를 나열합니다.

예. 이 코드는 태그와 해당 신뢰도(confidence)를 나열합니다. features 목록에 VisualFeatureTypes.Tags가 명시적으로 포함되어 있으며, 이는 Computer Vision service가 이미지에 대한 태그 예측을 반환하도록 지시합니다. 분석 호출이 완료된 후, 코드는 results.Tags를 순회합니다: foreach (var tag in results.Tags) { Console.WriteLine($"{tag.Name} {tag.Confidence}"); } 이는 각 태그의 Name과 Confidence 점수를 출력합니다. 이는 요청된 visual feature(Tags)와 열거되는 출력 간의 직접적인 매핑입니다. features 목록에 Tags가 포함되지 않았다면, results.Tags는 일반적으로 비어 있거나 채워지지 않으며, 루프는 의미 있는 출력을 생성하지 못합니다. Tags가 요청되고 출력되므로, 해당 진술은 참입니다.

파트 3:

이 코드는 로컬 파일 시스템에서 파일을 읽습니다.

예. 이 코드는 로컬 파일 시스템에서 파일을 읽습니다. 메서드 시그니처에는 string localImage가 포함되어 있고, using 블록 내부에서 File.OpenRead(localImage)를 호출합니다. File.OpenRead는 애플리케이션이 실행 중인 머신에서 파일 경로를 열고 Stream을 반환하는 .NET API입니다. 그 Stream은 AnalyzeImageInStreamAsync로 전달되며, 이는 Stream으로 제공되는 이미지 콘텐츠(예: 로컬 파일, 메모리 스트림 또는 기타 Stream 소스)를 분석하도록 특별히 설계되었습니다. 이는 일반적으로 이미지 URL을 받는 AnalyzeImageAsync와는 다릅니다. 코드가 로컬 경로와 함께 File.OpenRead를 사용하므로, 로컬 파일 시스템에서 읽고 있는 것이 확실합니다.

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

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

11
문제 11

Azure Cognitive Search에서 인덱싱을 위한 관리 포털로 사용되는 웹 앱을 배포합니다. 이 앱은 primary admin key를 사용하도록 구성되어 있습니다. 보안 검토 중에 검색 인덱스에 대한 무단 변경을 발견합니다. primary access key가 유출되었을 가능성이 있다고 의심합니다. 인덱스 관리 endpoint에 대한 무단 액세스를 방지해야 합니다. 솔루션은 다운타임을 최소화해야 합니다. 다음으로 무엇을 해야 합니까?

오답입니다. primary admin key를 먼저 regenerate하면 앱이 현재 사용 중인 credential이 즉시 무효화됩니다. 즉, 구성이 secondary key로 업데이트될 때까지 management portal이 액세스를 잃을 수 있으므로 downtime을 최소화하지 못합니다. 최종적으로는 두 key 모두 rotation하게 되더라도, 현재 유출이 의심되는 primary key에 연결된 live app에 대해서는 이 순서가 운영상 잘못되었습니다.

오답입니다. query key는 Azure Cognitive Search에서 index 관리 endpoint를 호출할 수 없습니다. web app은 indexing을 위한 management portal이므로, query key로 전환하면 기능 수행에 필요한 권한을 잃게 됩니다. admin key를 regenerate하는 것은 유용하지만, 이 선택지는 필요한 administrative 기능을 깨뜨립니다.

정답입니다. 애플리케이션은 현재 primary admin key를 사용 중이므로, secondary key를 먼저 regenerate하면 실행 중인 앱에 영향을 주지 않고 새로운 대체 credential을 만들 수 있습니다. 앱이 그 새 secondary key를 사용하도록 업데이트한 후에는, 유출이 의심되는 primary key를 안전하게 regenerate하여 비인가 액세스를 즉시 무효화할 수 있습니다. 이 순서는 downtime을 최소화하면서 관리 기능을 유지하고, 표준 dual-key rotation 패턴을 따릅니다.

오답입니다. query key는 read-only search 요청에만 사용되며 admin 수준의 index 관리 액세스에는 아무런 영향을 주지 않습니다. query key를 추가하거나 삭제해도 indexes를 수정할 수 있는 유출된 admin key를 무효화할 수 없습니다. 또한 management portal은 administrative 작업에 query key를 사용할 수 없으므로 이 선택지는 성립하지 않습니다.

문제 분석

핵심 개념: Azure Cognitive Search는 관리 액세스가 필요한 애플리케이션을 중단 없이 운영할 수 있도록 두 개의 admin key를 제공합니다. admin key는 indexes, indexers 및 기타 search 리소스에 대한 전체 제어 권한을 허용하므로, 유출이 의심되면 즉시 rotation이 필요합니다. downtime을 최소화하는 가장 안전한 방식은 현재 사용 중이 아닌 key를 먼저 regenerate하고, 애플리케이션을 그 새 key로 전환한 다음, 유출이 의심되는 key를 regenerate하는 것입니다. 정답인 이유: 앱은 현재 primary admin key를 사용 중이며, 이 key의 유출이 의심됩니다. primary key를 먼저 regenerate하면 앱 구성이 업데이트될 때까지 즉시 액세스를 잃게 되어 downtime 위험이 커집니다. secondary key를 먼저 regenerate하면 새로운 유효한 admin credential을 만들 수 있고, 앱을 그 key로 전환한 뒤 유출이 의심되는 primary key를 regenerate하여 공격자의 액세스를 무효화할 수 있습니다. 주요 특징: - index 관리 작업에는 admin key가 필요하며, query key는 read-only입니다. - Azure Cognitive Search는 seamless rotation을 지원하기 위해 primary 및 secondary admin key를 모두 제공합니다. - key를 regenerate하면 해당 슬롯의 이전 값은 즉시 무효화됩니다. - service interruption을 최소화할 때는 사용하지 않는 key를 먼저 rotation하는 것이 표준 접근 방식입니다. 흔한 오해: 흔한 실수는 가장 긴급해 보인다는 이유로 유출이 의심되는 key를 먼저 regenerate하는 것이지만, 앱이 여전히 그 key를 사용 중이면 애플리케이션이 중단될 수 있습니다. 또 다른 오해는 query key를 admin key 대신 사용할 수 있다는 것이지만, query key는 관리 작업을 수행할 수 없습니다. 전체 rotation cycle을 명시적으로 완료해야 하는 경우가 아니라면 두 key를 즉시 모두 regenerate할 필요도 없습니다. 시험 팁: - key가 유출되었고 앱이 현재 그 key를 사용 중이라면, downtime이 허용되지 않는 한 먼저 regenerate하지 마세요. - primary/secondary key를 제공하는 Azure 서비스에서는 시험에서 보통 다음 순서를 기대합니다: 사용하지 않는 key를 rotation하고, 클라이언트를 전환한 다음, 기존 key를 rotation합니다. - query key는 search query 전용이며 administrative 변경에는 사용할 수 없다는 점을 기억하세요.

12
문제 12

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가 아니라 정적인 아이콘입니다.

13
문제 13

HOTSPOT - 챗봇의 설계를 검토하고 있습니다. 해당 챗봇에는 다음 조각을 포함하는 language generation 파일이 있습니다.

Greet(user)

  • ${Greeting()}, ${user.name} 다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
파트 1:

${user.name}는 prompt를 사용하여 사용자 이름을 가져옵니다.

${user.name}는 prompt를 사용하여 사용자 이름을 가져오지 않습니다. Bot Framework Composer LG에서 ${...}는 런타임에 봇의 memory/state에 대해 expression을 평가합니다. expression "user.name"은 "user" memory scope(user state)에서 "name" property의 값을 읽습니다. 해당 값은 이전에 code, dialog step 또는 prompt에 의해 설정되었을 수 있지만, expression 자체는 prompt가 아니며 사용자에게 입력을 요청하지 않습니다. prompt는 dialog에서(예: "Ask a question" step) 구현되며 사용자 입력을 수집하고 이를 user.name과 같은 property에 저장합니다. 해당 저장이 발생한 이후에야 ${user.name}가 수집된 값으로 resolve됩니다. 따라서 “prompt를 사용하여” 이름을 가져온다고 말하는 것은 부정확하며, state/memory에서 가져오는 것입니다.

파트 2:

Greet()는 language generation template의 이름입니다.

LG file에서 header `# Greet(user)`는 `user`라는 하나의 parameter를 가진 `Greet`라는 이름의 template를 정의합니다. 괄호는 parameter list를 포함하며 template name 자체의 일부가 아닙니다. 따라서 `Greet()`가 language generation template의 이름이라는 설명은 false입니다. `Greet`가 template name이고, `user`는 input parameter입니다.

파트 3:

${Greeting()}는 language generation 파일에 있는 템플릿을 참조하는 것입니다.

LG에서 `${...}`는 runtime에 평가할 expression을 포함합니다. `Greeting()`은 function-like syntax를 사용하며 다른 LG template로 resolve될 수 있습니다. 하지만 사용 가능한 definitions와 context에 따라 function을 나타낼 수도 있습니다. fragment에는 `# Greeting` template declaration이 표시되어 있지 않으므로, 이것이 language generation file의 template에 대한 reference라고 확실하게 결론내릴 수 없습니다. 따라서 이 진술은 snippet만으로는 신뢰할 수 있게 참이라고 할 수 없습니다.

14
문제 14

DRAG DROP - Face API에 대한 호출을 개발하고 있습니다. 이 호출은 employeefaces라는 기존 목록에서 유사한 얼굴을 찾아야 합니다. employeefaces 목록에는 60,000개의 이미지가 포함되어 있습니다. HTTP 요청의 본문을 어떻게 완성해야 합니까? 답하려면 적절한 값을 올바른 대상에 끌어다 놓으십시오. 각 값은 한 번, 여러 번 또는 전혀 사용하지 않을 수 있습니다. 내용을 보려면 창 사이의 분할 막대를 끌거나 스크롤해야 할 수 있습니다. 참고: 각 올바른 선택은 1점입니다. 선택 및 배치:

파트 1:

"______": "employeefaces",

컬렉션에 60,000개의 이미지가 포함되어 있으므로, Find Similar 요청은 FaceList가 아니라 LargeFaceList를 대상으로 해야 합니다. JSON body에서 올바른 property 이름은 첫 글자가 소문자인 "largeFaceListId"이며, 그 값은 "employeefaces"여야 합니다. "faceListId"는 더 작은 FaceList resource에 사용하는 것이므로 이 규모에는 적합하지 않습니다. "matchFace"와 "matchPerson"은 mode 값이지, 컬렉션 식별자 property가 아닙니다.

파트 2:

"mode": "______"

정답 mode는 "matchFace"입니다. 왜냐하면 이 시나리오는 기존 face list에서 유사한 얼굴을 찾도록 명시적으로 요구하기 때문입니다. Find Similar API에서 "matchFace"는 query face와 시각적으로 유사한 얼굴을 반환하는 반면, "matchPerson"은 더 엄격하며 동일한 사람일 가능성이 높은 얼굴을 반환하도록 의도되었습니다. 작업이 LargeFaceList에 대한 similarity search이므로 "matchFace"가 요구 사항에 가장 잘 부합합니다. "faceListId"와 "largeFaceListId"는 identifier property이며, "mode" field에 대한 유효한 값이 아닙니다.

15
문제 15

HOTSPOT - 텍스트 처리 솔루션을 개발하고 있습니다. 다음 메서드를 개발합니다.

static void GetKeyPhrases(TextAnalyticsClient textAnalyticsClient, string text)
{
    var response = textAnalyticsClient.ExtractKeyPhrases(text);
    Console.WriteLine("Key phrases:");

    foreach (string keyphrase in response.Value)
    {
        Console.WriteLine($"\t{keyphrase}");
    }
}

다음 코드를 사용하여 메서드를 호출합니다. GetKeyPhrases(textAnalyticsClient, "the cat sat on the mat"); 다음 각 문장에 대해, 문장이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. Hot Area:

파트 1:

이 호출은 입력 문자열에서 핵심 구문을 추출하여 콘솔에 출력합니다.

예. 이 메서드는 Azure AI Language의 key phrase extraction 작업을 호출하고, 반환된 구문을 콘솔에 씁니다. 구체적으로, ExtractKeyPhrases는 Response<KeyPhraseCollection>을 반환하며, 코드는 response.Value(즉, KeyPhraseCollection)를 반복하면서 각 문자열을 출력합니다. 클라이언트가 올바르게 인증되어 있고, 리소스 엔드포인트가 유효하며, 호출이 성공한다면(예외 없음), 콘솔 출력에는 헤더 "Key phrases:" 다음에 추출된 각 key phrase가 한 줄씩 출력됩니다. 핵심은 코드가 동기식 SDK 메서드를 올바르게 사용하고 반환된 컬렉션을 열거하고 있다는 점입니다. 루프에서 추가적인 필터링이나 변환이 없으므로, 서비스가 반환하는 내용이 그대로 출력됩니다.

파트 2:

출력에는 다음 단어들이 포함됩니다: the, cat, sat, on, and mat.

아니요. Key phrase extraction은 입력의 모든 단어를 반환하지 않습니다. 가장 관련성이 높은 구(phrase)만 반환하며, 일반적으로 명사/명사구에 초점을 맞추고 stop words 및 가치가 낮은 용어는 제외합니다. 문장 "the cat sat on the mat"에서 "the"와 "on" 같은 단어는 전형적인 stop words이므로 key phrases로 반환될 가능성이 매우 낮습니다. "sat" 같은 동사도 모델이 중요도(salience)를 어떻게 판단하느냐에 따라 반환될 수도 있고 아닐 수도 있습니다. 더 일반적인 출력은 "cat"과 "mat" 같은 소수의 집합(그리고 언어 휴리스틱에 따라 "cat sat" 또는 "the mat"가 포함될 수도 있음)일 수 있지만, 모든 토큰이 포함된다고 가정할 수는 없습니다. 시험에서는 다음을 기억하세요: key phrase extraction은 tokenization이 아니라 summarization에 가깝습니다.

파트 3:

출력에는 핵심 구문에 대한 신뢰도 수준이 포함됩니다.

아니요. 출력에는 신뢰도 수준이 포함되지 않습니다. Azure.AI.TextAnalytics SDK의 ExtractKeyPhrases API는 추출된 핵심 구문 문자열(KeyPhraseCollection)만 반환하기 때문입니다. 이 응답 타입에는 핵심 구문별 신뢰도 점수 속성이 없으며, 샘플 코드는 구문 텍스트만 출력합니다. 이는 신뢰도 점수가 응답 스키마의 일부로 포함되는 다른 Azure AI Language 기능(예: 감정 분석의 SentimentConfidenceScores 또는 특정 분류 출력)과 다릅니다. 여기서 SDK의 표면 영역은 의도적으로 단순하며, 구문 목록만 제공합니다. 따라서 SDK 호출이나 제공된 코드 모두 신뢰도 값을 출력할 수 없습니다.

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

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

16
문제 16

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 이 시리즈의 각 질문에는 명시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션의 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. Language Understanding service를 사용하여 language model을 빌드합니다. 이 language model은 FindContact라는 intent를 사용하여 연락처 목록에서 정보를 검색하는 데 사용됩니다. 대화형 전문가가 학습에 사용할 다음 문구 목록을 제공합니다. ✑ London에 있는 연락처를 찾아줘. ✑ Seattle에 아는 사람이 누구야? ✑ Ukraine에 있는 연락처를 검색해줘. Language Understanding에서 phrase list를 구현해야 합니다. 솔루션: FindContact intent에 새 pattern을 만듭니다. 이것이 목표를 충족합니까?

예가 오답인 이유는 새 pattern을 만드는 것은 utterance가 template화할 수 있는 예측 가능한 구조를 공유하는 경우에만 도움이 되기 때문입니다. 이 경우 예시는 'Find contacts in London' 및 'Who do I know in Seattle?'처럼 서로 다른 표현을 사용하므로, 재사용 가능한 주요 요소는 문장 형식이 아니라 location term입니다. phrase list는 city 및 country name와 같은 관련 단어를 LUIS에 제공하여 entity recognition을 향상시킬 수 있습니다. 따라서 pattern만 사용하는 것은 phrase list를 구현해야 한다는 요구 사항을 충족하지 못합니다.

아니요가 정답인 이유는 목표가 제공된 term를 Language Understanding에 구현하는 것이며, pattern은 그 목적에 적합한 기능이 아니기 때문입니다. Pattern은 'Find contacts in {Location}'처럼 placeholder가 있는 안정적인 template를 따르는 utterance를 위해 설계되었습니다. sample utterance는 표현 방식이 크게 다르므로, 하나의 pattern으로는 이를 효과적으로 나타낼 수 없습니다. 서로 다른 utterance 형식 전반에서 관련 location value의 인식을 향상시키려는 경우에는 phrase list가 더 적절한 기능입니다.

문제 분석

핵심 개념: 이 문제는 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에 대한 체계적인 테스트를 실행하는 적절한 방법이 아닙니다. Content Safety Studio는 Content Safety 기능(text/image moderation, severity threshold, testing)을 탐색하고 평가하는 데 사용되지만, “Safety metaprompt”는 chatbot의 input/output pipeline에 대한 batch 스타일 테스트 및 content filter 조정을 위한 주요 기능이 아닙니다. 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를 사용하여 구성 가능한 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과 external moderation (CS1)을 구분합니다. user input 경로와 model output 경로를 모두 테스트해야 합니다. 일반적인 오해: 어떤 “metaprompt” 또는 “safety prompt” 기능이든 filter를 테스트하기 위한 것이라고 쉽게 생각할 수 있습니다. 그러나 filter 최적화는 dataset에 대한 moderation 결과를 측정하고 threshold/action을 조정하는 것이지, prompt template 기능에 관한 것이 아닙니다. 시험 팁: “content filter configuration 최적화”와 “sample question에 대한 테스트 실행”이 보이면, Content Safety Studio testing 도구 및/또는 자동화된 API 기반 evaluation pipeline을 떠올리세요. 또한 Content Safety는 moderation scoring을 위한 전용 서비스이며, OpenAI prompt 기법이 threshold 조정과 측정 가능한 테스트 실행을 대체하지 않는다는 점도 기억하세요.

17
문제 17

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 시리즈의 각 질문에는 명시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션의 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. Custom Vision 모델을 학습하여 꽃의 종을 식별하는 애플리케이션을 개발합니다. 새로운 꽃 종의 이미지를 받습니다. 새 이미지를 분류기에 추가해야 합니다. 솔루션: 새 이미지를 추가한 다음 Smart Labeler 도구를 사용합니다. 이것이 목표를 충족합니까?

아니요. image를 추가하고 Smart Labeler를 사용하는 것만으로는 classifier의 학습된 동작이 업데이트되지 않습니다. Smart Labeler는 tag를 제안할 뿐이며 model을 학습시키지 않습니다. 새로운 flower species의 경우 새로운 tag(class)를 만들어야 하고, image에 label을 지정한 다음(Smart Labeler는 보지 못한 species에 대해 정확하지 않을 수 있음), classifier를 다시 학습시키고 일반적으로 application이 업데이트된 classifier를 사용할 수 있도록 model을 다시 publish해야 합니다.

아니요, 정답입니다. image를 추가하고 Smart Labeler를 사용하는 것만으로는 classifier가 새로운 flower species를 인식하게 되지 않습니다. Azure Custom Vision에서 classifier는 tag와 연결된 label된 training image를 통해 학습하므로, 새로운 species는 project에서 새로운 class 또는 tag로 표현되어야 합니다. Smart Labeler는 label 제안을 도울 수 있지만, annotation 보조 도구일 뿐이며 학습된 model을 자동으로 업데이트하지는 않습니다. 새로운 image에 올바르게 label을 지정한 후에는 새로운 species가 model에 포함되도록 classifier를 다시 학습시켜야 합니다.

문제 분석

핵심 개념: 이 문제는 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에 대한 체계적인 테스트를 실행하는 적절한 방법이 아닙니다. 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과 external moderation(CS1)을 구분합니다. user input 경로와 model output 경로를 모두 테스트해야 합니다. 일반적인 오해: 어떤 “metaprompt” 또는 “safety prompt” 기능이든 filter를 테스트하기 위한 것이라고 쉽게 생각할 수 있습니다. 그러나 filter 최적화는 prompt template 기능에 관한 것이 아니라, dataset에 대한 moderation outcome을 측정하고 threshold/action을 조정하는 것입니다. 시험 팁: “content filter configuration을 최적화”하고 “sample question에 대해 테스트를 실행”한다는 표현이 보이면, Content Safety Studio testing 도구 및/또는 자동화된 API 기반 evaluation pipeline을 떠올리세요. 또한 Content Safety는 moderation scoring을 위한 전용 서비스이며, OpenAI prompt 기법이 threshold 조정과 측정 가능한 test run을 대체하지 않는다는 점도 기억하세요.

18
문제 18

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 시리즈의 각 질문에는 명시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상일 수 있으며, 다른 질문 세트에는 정답이 없을 수도 있습니다. 이 섹션의 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. Custom Vision 모델을 학습하여 꽃의 종을 식별하는 애플리케이션을 개발합니다. 새로운 꽃 종의 이미지를 받습니다. 새 이미지를 분류기에 추가해야 합니다. 솔루션: 새 이미지와 레이블을 기존 모델에 추가합니다. 모델을 다시 학습한 다음 모델을 게시합니다. 이것이 목표를 충족합니까?

예. 올바른 labels(tags)로 새 이미지를 추가하면 학습 데이터셋이 확장되어 새로운 꽃 종이 포함됩니다. 새로 추가된 라벨 예시로부터 학습하도록 새 iteration을 생성하려면 retraining이 필요합니다. retraining된 iteration을 publish하면 Prediction API가 제공하는 대상이 업데이트되어, 애플리케이션이 업데이트된 분류기를 사용하게 됩니다.

아니오는 틀렸습니다. 설명된 단계는 새로운 라벨 데이터로 분류기를 업데이트하는 표준 Custom Vision 워크플로 자체이기 때문입니다. retraining이 없으면 모델은 새로운 종을 학습하지 못하고, publishing이 없으면 업데이트된 iteration이 예측에 사용되지 않습니다. 이 해결책은 이미지와 라벨을 추가한 뒤 retraining과 publishing을 모두 포함하므로 목표를 충족합니다.

문제 분석

핵심 개념: 이 문제는 새로운 라벨이 지정된 학습 데이터(새로운 꽃 종 이미지)가 उपलब्ध해졌을 때 Azure Custom Vision 이미지 분류 모델을 어떻게 업데이트하는지, 그리고 업데이트된 모델을 예측에 사용할 수 있도록 하려면 어떤 단계가 필요한지를 평가합니다. 정답인 이유: Azure Custom Vision에서 분류기를 개선하거나 범위를 확장하려면, 적절한 tags(라벨)가 포함된 새 학습 이미지를 추가하고, retraining을 수행하여 새 iteration을 만든 다음, 해당 iteration을 publish하여 prediction endpoint가 업데이트된 모델을 사용하도록 해야 합니다. 이미지와 라벨을 추가하는 것은 학습 데이터셋을 업데이트할 뿐이며, retraining을 수행하기 전까지 모델은 변경되지 않습니다. 또한 retraining은 새 iteration을 만들지만, 이를 publish(또는 어떤 iteration을 publish할지 업데이트)하기 전까지 클라이언트는 이를 사용하지 않습니다. 따라서 새 꽃 종을 분류기에 반영하기 위한 엔드투엔드 워크플로는 이미지/tags 추가 → retraining → publishing 입니다. 주요 기능 / 구성: - Custom Vision의 tags(라벨)는 분류를 위한 클래스에 해당합니다. - Training은 새 model iteration을 생성하며, retrain을 할 때마다 새 iteration이 만들어집니다. - iteration을 publish하면 게시된 이름으로 Prediction API에서 사용할 수 있게 됩니다. - 최신 iteration을 publish하면서도, 롤백/비교를 위해 이전 iteration을 유지할 수 있습니다. 흔한 오해: - 이미지를 업로드하면 retraining 없이도 라이브 모델이 자동으로 업데이트된다고 생각하는 것. - retraining 후 publish를 잊어 prediction endpoint가 이전 iteration을 계속 제공하게 되는 것. - “training”과 “publishing”을 혼동하는 것: training은 iteration을 빌드하고, publishing은 추론(inference)을 위해 배포합니다. 시험 팁: - 항상 다음을 세트로 기억하세요: 라벨된 데이터 추가 → train(새 iteration) → publish(Prediction API로 제공). - 문제에서 “predictions에 사용” 또는 “앱에서 사용 가능”을 언급하면 publishing이 필요합니다. - 여러 iteration이 존재할 수 있지만, prediction endpoint에서 사용되는 것은 publish된 iteration뿐입니다.

19
문제 19

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 이 시리즈의 각 질문에는 명시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 두 개 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션의 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. Custom Vision 모델을 학습하여 꽃의 종을 식별하는 애플리케이션을 개발합니다. 새로운 꽃 종의 이미지를 받습니다. 새 이미지를 분류기에 추가해야 합니다. 솔루션: 새 모델을 만든 다음 새 이미지와 레이블을 업로드합니다. 이것이 목표를 충족합니까?

Yes는 목표가 기존 classifier를 별도의 model로 대체하는 것이 아니라, 새 이미지와 label을 기존 classifier에 추가하는 것이므로 오답입니다. Custom Vision은 현재 project에 tag된 이미지를 추가하고 retrain하는 방식의 점진적 개선을 위해 설계되었습니다. 새로운 model을 만들면 classifier context를 독립적으로 다시 구축해야 하며, 기존 flower-species classifier를 확장하는 의도된 접근 방식도 아닙니다. 시험에서는 요구 사항이 class나 example을 추가하는 것이라면, 일반적으로 기대되는 조치는 기존 project를 retraining하는 것입니다.

No가 정답인 이유는 기존 Custom Vision classifier에 새로운 flower species를 추가하는 표준 방법이 새로운 model을 만드는 것이 아니기 때문입니다. Azure Custom Vision에서는 일반적으로 동일한 project를 유지하고, 새 이미지를 업로드하고, 새 species를 나타내는 새로운 tag를 할당한 다음, model을 retrain합니다. 이렇게 하면 원래 species와 새로 추가된 species가 모두 포함된 새로운 iteration이 생성됩니다. 별도의 model로 시작하면 솔루션이 분리되고, 요구된 대로 기존 classifier를 직접 확장하지 못하게 됩니다.

문제 분석

핵심 개념: 이 문제는 새로운 class가 도입될 때 Azure Custom Vision image classification model을 어떻게 업데이트하는지 테스트합니다. Custom Vision에서는 일반적으로 별도의 model로 처음부터 다시 시작하는 대신, 동일한 project를 계속 사용하고, 새로운 class에 대해 새로 tag된 이미지를 추가한 다음, retrain하여 새로운 iteration을 만듭니다. 정답인 이유: 제안된 솔루션은 목표를 충족하지 못합니다. 새로운 model을 만드는 것은 불필요하며, 기존 classifier를 확장하는 일반적인 Custom Vision workflow와도 맞지 않기 때문입니다. 새로운 flower species를 추가하려면 기존 project에 새 이미지를 추가하고, 해당 species에 대한 새로운 tag/label을 할당한 다음, classifier를 retrain하여 model이 기존 지식을 유지하면서 추가 class를 학습하도록 해야 합니다. 주요 기능: - Custom Vision은 동일한 project 내에서 iterative training을 지원합니다. - 새로운 category는 새로운 tag를 만들고 labeled image를 업로드하여 추가합니다. - retraining은 동일한 model의 새로운 iteration을 생성하며, 이후 이를 평가하고 publish할 수 있습니다. - 동일한 project를 유지하면 기존 class와 training context가 보존됩니다. 흔한 오해: 흔한 실수는 새로운 class가 생기면 반드시 완전히 새로운 model이 필요하다고 가정하는 것입니다. Custom Vision에서는 일반적으로 problem type이 크게 바뀌는 경우, 예를 들어 classification에서 object detection으로 전환하는 경우나, 의도적으로 완전히 별도의 솔루션을 원하는 경우에만 새로운 model/project가 필요합니다. 시험 팁: 문제에서 기존 Custom Vision classifier에 새로운 labeled example 또는 새로운 class를 추가하라고 하면, 기존 project를 업데이트하고 retrain한다고 생각하세요. AI-102에서는 iteration, retrain, tag, existing classifier 같은 단어가 나오면 보통 별도의 model을 처음부터 만들면 안 된다는 의미입니다.

20
문제 20

HOTSPOT - 영국 영어(English (United Kingdom))로 진행되는 강의를 녹음하는 서비스를 개발하고 있습니다. translated text와 language identifier를 받는 AppendToTranscriptFile이라는 메서드가 있습니다. 참석자에게 각자의 언어로 강의 transcript를 제공하는 코드를 개발해야 합니다. 지원되는 언어는 English, French, Spanish, German입니다. 코드를 어떻게 완성해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택은 1점입니다. 핫 영역:

파트 1:

var lang = new List<string> ______

정답: B ({"fr", "de", "es"}). Speech translation에서는 소스 인식 언어를 별도로 지정합니다(여기서는 일반적으로 translation config에서 영국 영어를 "en-GB"로 설정). 그런 다음 BCP-47 language tag를 사용해 대상 언어를 추가합니다. 프랑스어, 독일어, 스페인어의 일반적인 tag는 "fr", "de", "es"입니다. 따라서 이 리스트는 번역할 대상 언어들의 집합입니다. 다른 선택지가 틀린 이유: - A ({"en-GB"})는 소스 언어이며, 추가로 번역할 대상 언어들의 집합이 아닙니다. - C ({"French", "Spanish", "German"})는 표시 이름을 사용하고 있으며, SDK가 기대하는 유효한 language identifier가 아닙니다. - D ({"languages"})는 language code 목록이 아니며, 실제 값이라기보다 placeholder 변수 이름처럼 보입니다.

파트 2:

using var recognizer = new ______ (config, audioConfig);

정답: D (TranslationRecognizer). 음성에서 번역된 transcript를 생성하기 위해 Speech SDK는 TranslationRecognizer를 사용하며, 이는 translation configuration(예: SpeechTranslationConfig)과 AudioConfig와 함께 동작합니다. 이는 소스 언어(en-GB)로 음성을 인식하고 동시에 여러 대상 언어(fr/de/es)로의 번역을 제공할 수 있습니다. recognizer는 번역 결과(보통 result.Translations["fr"] 등)를 노출하며, 이는 언어 식별자와 함께 번역된 텍스트를 추가하는 method signature와 일치합니다. 다른 선택지가 틀린 이유: - IntentRecognizer는 intent recognition(종종 LUIS/CLU patterns 사용)을 위한 것이며, 음성 번역이 아닙니다. - SpeakerRecognizer는 번역을 위한 표준 Speech SDK class가 아닙니다. speaker recognition/verification은 다른 API를 사용하며 번역을 수행하지 않습니다. - SpeechSynthesizer는 text-to-speech(오디오 출력)로, transcript에 필요한 방향과 반대입니다.

모의고사

Practice Test #1

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

Practice Test #2

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

Practice Test #3

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

다른 Microsoft 자격증

PL-300: Microsoft Power BI Data Analyst

PL-300: Microsoft Power BI Data Analyst

Microsoft AI-900

Microsoft AI-900

Fundamentals

Microsoft SC-200

Microsoft SC-200

Associate

Microsoft AZ-104

Microsoft AZ-104

Associate

Microsoft AZ-900

Microsoft AZ-900

Fundamentals

Microsoft SC-300

Microsoft SC-300

Associate

Microsoft DP-900

Microsoft DP-900

Fundamentals

Microsoft SC-900

Microsoft SC-900

Fundamentals

Microsoft AZ-305

Microsoft AZ-305

Expert

Microsoft AZ-204

Microsoft AZ-204

Associate

Microsoft AZ-500

Microsoft AZ-500

Associate

지금 학습 시작하기

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를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.