오답입니다. 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 저장/읽기)이며 키 재생성의 자동 결과가 아닙니다.
Cloud Pass를 다운로드하고 모든 Microsoft AI-102 기출 문제를 풀어보세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
앱 받기
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
2
문제 2
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 변경에는 사용할 수 없다는 점을 기억하세요.
3
문제 3
다음은 Azure Cognitive Services 리소스를 프로그래밍 방식으로 생성하기 위한 C# 메서드입니다.
static void create_resource(CognitiveServicesManagementClient client, string resource_name, string kind, string account_tier, string location)
{
CognitiveServicesAccount parameters =
new CognitiveServicesAccount(null, null, kind, location, resource_name,
new CognitiveServicesAccountProperties(), new Sku(account_tier));
var result = client.Accounts.Create(resource_group_name, account_tier, parameters);
}
West US Azure region에서 무료 Azure 리소스를 생성하기 위해 이 메서드를 호출해야 합니다. 해당 리소스는 이미지의 캡션을 자동으로 생성하는 데 사용됩니다.
어떤 코드를 사용해야 합니까?
정답입니다. "ComputerVision"은 캡션 생성 등 사전 구축 이미지 분석 기능에 적합한 kind입니다. "F0"는 무료 SKU로, 무료 리소스 요구 사항을 충족합니다. "westus"는 West US Azure region을 지정합니다. 이 조합은 이미지 캡션 생성에 적합한 무료 Computer Vision 리소스를 프로비저닝합니다(무료 티어 제한 내에서).
오답입니다. "CustomVision.Prediction"은 Custom Vision으로 학습한 모델(분류/객체 감지)의 예측을 호스팅하고 실행하는 데 사용됩니다. Computer Vision/Image Analysis에 포함된 사전 구축 캡셔닝 기능은 제공하지 않습니다. "F0"가 무료이고 "westus"가 유효하더라도, 자동 캡션 생성에 필요한 서비스 kind가 잘못되었습니다.
오답입니다. "ComputerVision"은 캡셔닝에 올바른 서비스 kind이지만, "S0"는 무료 티어가 아니라 유료 Standard 티어입니다. 문제에서 무료 Azure 리소스 생성을 명시적으로 요구하므로, S0 사용은 요구 사항을 위반합니다(기능적으로는 캡셔닝이 가능하더라도).
오답입니다. 이 옵션은 두 가지 측면에서 잘못되었습니다. "CustomVision.Prediction"(사전 구축 캡셔닝에 적합한 서비스가 아님)을 사용하고, 요구되는 무료 티어 대신 "S0"(유료 티어)를 사용합니다. Custom Vision prediction 리소스는 사용자 지정 모델 추론용이며, 이미지에서 캡션을 생성하는 용도가 아닙니다.
문제 분석
핵심 개념:
이 문제는 이미지 캡셔닝 시나리오에 맞는 올바른 Azure AI (Cognitive Services) 계정 유형("kind")과 SKU를 프로비저닝하는 방법을 평가합니다. 이미지 캡셔닝은 Computer Vision 기능(Image Analysis)이며, Azure AI services에서 ComputerVision kind로 프로비저닝됩니다.
정답이 맞는 이유:
West US에서 캡션을 생성할 수 있는 무료 리소스를 만들려면 다음을 선택해야 합니다.
1) kind = "ComputerVision"(캡션 생성과 같은 이미지 분석 기능을 지원하는 서비스),
2) SKU = "F0"(무료 티어), 그리고
3) location = "westus".
옵션 A는 이 세 가지 요구 사항을 모두 충족합니다. 메서드 시그니처에서 매개변수는 직접 매핑됩니다: resource_name="res1", kind="ComputerVision", account_tier="F0", location="westus".
주요 기능 및 모범 사례:
- Computer Vision(Image Analysis)은 캡셔닝(자연어 설명)과 함께 tags, objects, OCR, smart cropping 등의 기능을 제공합니다. AI-102에서는 캡셔닝이 Custom Vision(학습) 기능이 아니라는 점을 기억해야 합니다.
- SKU 선택은 중요합니다: F0는 무료 티어(일반적으로 분당/일당 트랜잭션 제한이 있으며, 종종 subscription당 region/service별로 무료 계정 1개로 제한됨)입니다. S0는 유료 표준 티어입니다.
- Region은 해당 서비스와 SKU를 지원해야 합니다. West US는 Computer Vision에 유효한 region이지만, 실제 배포에서는 regional availability와 quota 제한을 확인해야 합니다.
- Azure Well-Architected Framework 관점에서: 워크로드에 맞는 올바른 서비스를 선택하고(performance efficiency), dev/test에는 최소 비용 티어를 사용하며(cost optimization), 프로덕션에서는 S0로의 확장/업그레이드를 계획합니다.
흔한 오해:
- Custom Vision과 Computer Vision을 혼동: Custom Vision은 사용자 지정 이미지 분류/객체 감지 모델을 구축하고 호스팅하기 위한 것(학습 및 예측 리소스)입니다. Computer Vision/Image Analysis에 포함된 사전 구축 캡셔닝 기능은 제공하지 않습니다.
- "더 강력하다"는 이유로 S0를 선택: 문제에서 무료 리소스를 명시적으로 요구하므로 F0가 필요합니다.
시험 팁:
- 매핑을 암기하세요: 이미지 캡셔닝/설명 => ComputerVision kind(Image Analysis). CustomVision.* kind는 사용자 지정 모델 학습/예측용입니다.
- SKU 키워드를 확인하세요: F0 = Free, S0 = Standard(유료). 또한 region 문자열이 Azure location 명명과 일치하는지 확인하세요(예: "westus").
4
문제 4
공개용 웹사이트의 비디오와 텍스트를 처리할 새로운 영업 시스템을 개발하고 있습니다.
영업 시스템이 사용자의 데이터를 처리했음을 사용자에게 알릴 계획입니다.
이는 책임 있는 AI 원칙 중 어떤 것을 충족하는 데 도움이 됩니까?
Transparency는 AI 시스템이 사용자의 데이터를 언제, 어떻게 처리하고 결과에 어떤 영향을 미치는지에 대해 사용자에게 개방적이고 명확하게 알리는 것입니다. 비디오와 텍스트가 처리되었음을 사용자에게 알리는 행위는 AI 기반 또는 자동화된 처리에 대한 명시적 고지에 해당합니다. 이는 “black box”처럼 무엇이 일어났는지 모르는 상태에서 발생하는 놀람을 줄이고, 사용자가 시스템의 동작과 데이터 처리 방식을 이해하는 데 도움을 줍니다. Responsible AI 프레임워크에서 이러한 사용자 알림은 대중 대상 애플리케이션에서 transparency 기대치를 충족하기 위한 직접적인 메커니즘입니다.
Fairness는 서로 다른 사용자 집단(예: 성별, 연령, 민족) 전반에서 시스템이 편향되거나 차별적인 결과를 내지 않도록 보장하는 데 초점이 있습니다. 단지 처리가 발생했음을 사용자에게 알리는 것만으로는 모델 출력이 공정한지, 편향이 측정되고 완화되었는지와는 무관합니다. Fairness를 위해서는 대표성 있는 학습 데이터, 편향 평가, 완화 기법과 같은 단계가 필요합니다. 따라서 알림만으로는 fairness 원칙을 충족하지 못합니다.
Inclusiveness는 다양한 능력, 언어, 배경을 가진 사람들이 접근 가능하고 사용하기 쉽도록 AI 시스템을 설계하는 것입니다. 데이터가 처리되었다는 알림은 시스템이 접근성 요구(예: screen reader 지원), 다국어 사용자, 다양한 사용 맥락을 지원한다는 것을 보장하지 않습니다. Inclusiveness는 참여를 넓히고 장벽을 줄이기 위한 UX 및 기능 설계 선택을 포함합니다. 따라서 이 알림이 직접적으로 다루는 주요 원칙은 inclusiveness가 아닙니다.
Reliability and safety는 시스템이 예상 및 비예상 조건에서 일관되고, 보안적으로 안전하며, 안전하게 동작하는지에 관한 것입니다. 사용자에게 처리 사실을 알리는 것은 모델의 견고성, 오류 처리, 보안 통제, 안전 가드레일을 개선하지 않습니다. Reliability and safety는 테스트, 모니터링, 폴백 동작, 유해한 출력이나 장애로부터의 보호를 통해 입증됩니다. 따라서 이 선택지는 사용자 알림이라는 시나리오의 행동과 일치하지 않습니다.
문제 분석
핵심 개념:
이 문제는 Responsible AI 원칙에 대한 이해를 평가합니다. 특히 사용자의 데이터(비디오/텍스트)가 AI-enabled 시스템에 의해 처리되었음을 사용자에게 알리는 것이 어떤 원칙에 해당하는지 묻습니다.
정답이 맞는 이유:
사용자에게 데이터가 처리되었음을 알리는 것은 시스템이 어떻게 동작하고 사용자 데이터가 어떻게 사용되는지에 대해 공개적으로 안내하는 사례입니다. 이는 transparency 원칙과 일치하며, transparency는 AI의 개입 여부, 데이터 사용, 시스템 동작에 대해 사용자에게 명확히 커뮤니케이션하는 것을 강조합니다. 대중을 대상으로 하는 시나리오에서 transparency는 종종 고지(disclosure)를 포함합니다(예: “AI가 사용됩니다”, “콘텐츠가 분석됩니다”, “처리가 수행되었습니다”). 이를 통해 사용자는 자동화된 처리에 대해 예상치 못한 놀람을 겪지 않게 됩니다.
주요 기능 / 구성:
- 콘텐츠를 처리하는 데 AI가 사용된다는 사용자 대상 고지/알림
- 어떤 데이터(비디오, 텍스트)가 언제, 어떤 목적을 위해 처리되는지에 대한 명확한 설명
- 정확한 사용자 알림을 뒷받침하기 위한 감사 가능성/추적성 산출물(로그, 처리 상태)
- 동의 및 개인정보 고지는 종종 transparency와 함께 제공되지만(서로 구분되는 개념)
흔한 오해:
- transparency와 fairness를 혼동: fairness는 사용자에게 알리는 것이 아니라 집단 간 편향된 결과를 피하는 것에 관한 원칙입니다.
- transparency와 reliability and safety를 혼동: reliability/safety는 견고하고 안전하며 보안적으로 안전한 운영에 초점이 있으며, 사용자 고지와는 다릅니다.
- transparency와 inclusiveness를 혼동: inclusiveness는 접근성과 다양한 사용자를 위해 시스템이 잘 동작하도록 하는 것이지, 처리 사실을 커뮤니케이션하는 것이 아닙니다.
시험 팁:
- Transparency = AI 사용을 고지하고, 결정/처리를 설명하며, 시스템 동작을 이해 가능하게 만듦.
- Fairness = 편향을 완화하고 인구통계 전반에서 공정한 결과를 보장.
- Inclusiveness = 접근성과 다양한 사용자 요구를 고려해 설계.
- Reliability and safety = 견고성, 보안, 페일세이프, 예상 조건에서의 안전한 운영.
5
문제 5
(2개 선택)
URL 배열로부터 knowledge base를 생성할 Azure WebJob을 빌드하고 있습니다.
관련 API key를 가진 QnAMakerClient 객체를 인스턴스화하고, 해당 객체를 client라는 변수에 할당합니다.
knowledge base를 생성하는 메서드를 개발해야 합니다.
메서드에 포함해야 하는 두 가지 작업은 무엇입니까? 각 정답은 솔루션의 일부를 제시합니다.
참고: 각 정답 선택은 1점입니다.
이 시나리오에서는 오답입니다. FileDTO 객체는 파일 콘텐츠(예: 문서 업로드)로부터 KB를 생성할 때 사용됩니다. 문제는 KB가 URL 배열로부터 생성된다고 했으므로, WebJob 데이터를 FileDTO로 표현할 필요가 없습니다. 파일이 관련되더라도 CreateKbDTO와 CreateAsync는 여전히 필요하며, FileDTO만으로는 충분하지 않습니다.
정답입니다. client.Knowledgebase.CreateAsync는 QnA Maker에서 knowledge base 생성을 시작하는 SDK 호출입니다. KB 생성은 비동기 management operation이므로, CreateAsync는 일반적으로 성공 또는 실패할 때까지 폴링하는 operation을 반환합니다. 입력 URL을 어떻게 모델링하든 CreateAsync를 호출하지 않으면 KB가 생성되지 않으므로, 이는 필수 작업입니다.
명시된 요구 사항에 대해 오답입니다. QnADTO는 KB 콘텐츠로 명시적인 question/answer pair(큐레이션된 QnA)를 제공할 때 사용됩니다. 문제는 URL 배열로부터 KB를 생성한다고 명시하며, 이는 create 요청에서 URL 소스로 표현됩니다. 선택적으로 QnADTO 항목을 추가할 수는 있지만, URL 기반 생성 요구 사항을 충족하는 데 필수는 아닙니다.
정답입니다. CreateKbDTO는 이름과 소스(URL 등)를 포함하여 생성할 knowledge base를 정의하는 요청 객체입니다. URL로부터 KB를 생성하려면, 해당 URL을 적절한 필드에 포함하는 CreateKbDTO를 구성해야 합니다. 그런 다음 이 DTO를 Knowledgebase.CreateAsync에 전달하여 생성 operation을 시작합니다.
문제 분석
핵심 개념:
이 문제는 QnA Maker SDK(QnAMakerClient)를 사용하여 프로그래밍 방식으로 QnA Maker knowledge base를 생성하는 방법을 테스트합니다. 클래식 QnA Maker 워크플로에서는 KB 이름과 소스(URL, 파일 또는 QnA pair)를 설명하는 “create KB” 요청을 제출합니다. SDK는 이 요청을 CreateKbDTO 객체로 모델링하며, Knowledgebase.CreateAsync 작업을 통해 제출합니다.
정답이 맞는 이유:
URL 배열로부터 knowledge base를 생성하려면, 메서드는 (1) KB와 해당 콘텐츠 소스를 설명하는 요청 payload를 구성하고, (2) KB 생성을 시작하는 API를 호출해야 합니다. SDK에서 payload는 CreateKbDTO(소스로 URL 목록을 포함할 수 있음)이며, API 호출은 client.Knowledgebase.CreateAsync입니다. CreateAsync는 일반적으로 완료될 때까지 폴링하는 operation을 반환하며, 이후 KB를 publish할 수 있습니다.
주요 기능 / 모범 사례:
- CreateKbDTO는 KB 생성을 위한 중심 요청 모델이며, URL, 파일 및/또는 QnA pair를 포함할 수 있습니다.
- Knowledgebase.CreateAsync는 비동기 operation을 시작합니다. 프로덕션 코드에서는 operation 상태를 폴링하고 실패/timeout을 처리해야 합니다.
- 생성 후에는 일반적으로 PublishAsync를 호출하여 KB를 런타임 쿼리에 사용할 수 있도록 합니다.
- Azure Well-Architected 관점에서, 일시적 실패에 대한 retry/backoff를 구현하고, 문제 해결을 위해 operation ID를 로깅하며, QnA Maker management endpoint의 throttling 제한을 고려합니다.
일반적인 오해:
“URL로부터 KB 생성”을 “파일 업로드” 또는 “QnA pair를 수동 제공”과 혼동하기 쉽습니다. 이것들도 유효한 입력이지만, 문제는 명시적으로 URL을 언급하며, 필요한 단계는 여전히 CreateKbDTO를 빌드하고 CreateAsync를 호출하는 것입니다.
시험 팁:
QnA Maker management operation의 패턴을 기억하세요: 적절한 DTO(CreateKbDTO/UpdateKbOperationDTO 등)를 빌드하고, 해당 Knowledgebase 메서드(CreateAsync/UpdateAsync)를 호출한 다음, operation을 폴링하고 publish합니다. CreateKbDTO + Knowledgebase.CreateAsync가 함께 보이면, 그것이 정석적인 create-KB 흐름입니다.
6
문제 6
당신은 한 회사 제품에 대한 리뷰를 기반으로 워드 클라우드를 생성하는 솔루션을 개발하고 있습니다.
어떤 Text Analytics REST API endpoint를 사용해야 합니까?
keyPhrases는 Azure AI Language/Text Analytics의 Key Phrase Extraction endpoint입니다. 각 리뷰에서 가장 관련성이 높은 구/문구(예: “battery life”, “poor packaging”)를 반환하며, 이를 집계하고 가중치를 부여해 워드 클라우드를 생성할 수 있습니다. 이는 비정형 리뷰 텍스트에서 공통 주제를 요약하는 가장 직접적인 기능입니다.
sentiment는 의견의 극성을 분석하고 점수/레이블(positive, neutral, negative) 및 선택적으로 문장 수준 sentiment를 반환합니다. 고객이 어떻게 느끼는지 이해하는 데는 유용하지만, 워드 클라우드를 렌더링하는 데 필요한 단어 또는 구/문구를 제공하지 않습니다. key phrases와 sentiment를 결합할 수는 있지만, sentiment만으로는 충분하지 않습니다.
languages는 입력 텍스트의 언어를 감지합니다. 이는 문서를 올바른 모델로 라우팅하거나 language hint를 제공해 후속 추출 품질을 개선하는 데 도움이 되는 전처리 단계가 될 수 있습니다. 그러나 language detection은 키워드나 구/문구를 추출하지 않으므로 워드 클라우드 구축을 직접 지원할 수 없습니다.
entities/recognition/general은 organizations, people, locations 등과 같은 범주의 entities를 식별하는 named entity recognition(NER)을 수행합니다. 워드 클라우드가 특정 entity 중심이라면 도움이 될 수 있지만, 일반적인 리뷰 워드 클라우드는 key phrase extraction이 더 잘 포착하는 설명적 key phrases(기능, 이슈, 속성)가 필요합니다.
문제 분석
핵심 개념:
이 문제는 비정형 텍스트에서 의미 있는 용어를 추출하는 Azure AI Language(이전 명칭: Text Analytics) 기능을 평가합니다. 워드 클라우드는 일반적으로 코퍼스(예: 제품 리뷰)에서 가장 자주 등장하거나 가장 관련성이 높은 구/문구를 기반으로 생성됩니다. 이를 직접 지원하는 API 기능은 Key Phrase Extraction입니다.
정답이 맞는 이유:
리뷰로 워드 클라우드를 생성하려면 고객이 언급하는 주요 주제와 용어(예: “battery life”, “customer service”, “easy setup”)를 식별해야 합니다. 이를 위한 Text Analytics REST API endpoint는 keyPhrases(Key Phrase Extraction)입니다. 이 endpoint는 문서별로 관련성이 필터링된 key phrases 집합을 반환하므로, 워드 클라우드 가중치 산정(리뷰 전반에서 출현 횟수 집계, 필요 시 관련도 또는 리뷰 평점으로 가중치 부여)에 이상적인 입력이 됩니다.
주요 기능 / 모범 사례:
Key Phrase Extraction은 다음을 수행할 때 가장 잘 동작합니다.
- 정확도를 높이기 위해 올바른 language hint를 제공(또는 먼저 언어를 감지)합니다.
- 텍스트 전처리(boilerplate 제거, 거의 동일한 리뷰 중복 제거)를 수행하여 클라우드가 왜곡되는 것을 방지합니다.
- 문서 전반의 결과를 집계(구/문구 카운트, 대소문자 정규화, 필요 시 동의어 병합)합니다.
Azure Well-Architected Framework 관점에서는 성능 효율성(서비스 제한 내에서 요청당 문서를 배치), 비용 최적화(필요하지 않은 sentiment 같은 호출 회피), 신뢰성(일시적 실패에 대한 재시도, throttling 처리)을 고려하십시오.
흔한 오해:
Sentiment analysis는 리뷰와 자주 연관되지만, 워드 클라우드에 표시할 용어가 아니라 극성 점수(positive/neutral/negative)를 출력합니다. Entity recognition은 named entities(브랜드, 사람, 위치)를 추출할 수 있지만, 워드 클라우드를 유용하게 만드는 “fast shipping” 같은 설명적 구/문구를 놓칠 수 있습니다. Language detection은 전처리 단계로는 유용하지만, 클라우드를 위한 단어/구를 생성하지는 않습니다.
시험 팁:
AI-102에서는 원하는 출력에 맞춰 올바른 Language 기능을 매핑하십시오.
- “주요 용어/주제는 무엇인가?” -> keyPhrases
- “사람들이 어떻게 느끼는가?” -> sentiment
- “어떤 언어인가?” -> languages
- “어떤 named entities가 언급되는가?” -> entities/recognition
또한 endpoint 명명은 API 버전에 따라 달라질 수 있지만, 기능 이름(Key Phrase Extraction)은 Azure AI Language 문서에서 일관되게 유지된다는 점을 기억하십시오.
7
문제 7
(2개 선택)
Microsoft Bot Framework SDK 및 Azure Bot Service를 사용하여 bot을 빌드합니다.
Azure에 bot을 배포할 계획입니다.
Bot Channels Registration 서비스를 사용하여 bot을 등록합니다.
배포를 완료하는 데 필요한 두 값은 무엇입니까? 각 정답은 솔루션의 일부를 제시합니다.
참고: 각 정답 선택은 1점입니다.
botId는 Bot Channels Registration 배포에 표준적으로 필요한 값이 아닙니다. Bot Framework 및 Azure Bot Service에서 채널이 사용하는 핵심 ID는 Azure AD 애플리케이션(Microsoft App) ID입니다. 일부 도구에서 bot resource ID를 표시할 수는 있지만, bot 엔드포인트로의 요청을 인증하는 데 필요한 자격 증명 쌍은 아닙니다.
tenantId는 app이 등록된 Azure AD tenant를 식별합니다. multi-tenant vs single-tenant app 시나리오에서 중요할 수는 있지만, Bot Channels Registration은 배포를 완료하기 위해 tenantId를 요구하지 않습니다. 채널과의 bot 런타임 인증은 tenantId를 명시적으로 사용하기보다 appId와 자격 증명(secret/cert)에 의존합니다.
appId(Microsoft App ID / client ID)는 bot에서 사용하는 Azure AD 애플리케이션을 고유하게 식별하므로 필요합니다. 채널은 tokens를 발급할 때 이 ID를 사용하고, bot은 이를 사용해 들어오는 요청을 검증합니다. 배포 설정에서는 일반적으로 MicrosoftAppId로 제공되며 bot에 사용되는 app registration과 일치해야 합니다.
objectId는 app registration의 service principal 또는 application object에 대한 디렉터리 object identifier입니다. Graph API 작업 및 일부 Azure AD 관리 작업에 유용하지만, bot 인증을 위해 Bot Channels Registration을 구성하는 데 필요하지 않습니다. Bot Framework는 objectId가 아니라 appId와 자격 증명을 기대합니다.
appSecret(Microsoft App Password / client secret)은 appId와 짝을 이루는 자격 증명으로 필요합니다. 이를 통해 bot이 Azure AD 애플리케이션으로 인증할 수 있으며 token 획득/검증 흐름에서 사용됩니다. 프로덕션에서는 안전하게 저장(예: Key Vault)하고 보안 모범 사례를 충족하도록 정기적으로 rotation해야 합니다.
문제 분석
핵심 개념:
이 문제는 Microsoft Bot Framework SDK로 빌드한 bot을 Azure Bot Service(특히 Bot Channels Registration)가 어떻게 인증하는지 테스트합니다. bot을 등록할 때 Azure는 채널(Teams, Web Chat, Direct Line 등)이 bot 엔드포인트를 안전하게 호출할 수 있도록 Azure AD 애플리케이션 ID가 필요합니다. 이 ID는 Application (client) ID와 client secret(또는 certificate)로 표현됩니다.
정답이 맞는 이유:
Bot Channels Registration으로 배포/등록을 완료하려면 Microsoft App ID(client ID)와 자격 증명(일반적으로 Microsoft App Password, 즉 app secret)을 제공해야 합니다. Bot Framework는 이러한 값을 사용하여 들어오는 요청(JWT tokens)을 검증하고, bot이 다른 서비스를 호출할 때 tokens를 획득합니다. appId가 없으면 bot에 ID가 없고, appSecret이 없으면 해당 ID로 인증할 수 없습니다.
주요 기능/구성 및 모범 사례:
- appId는 Azure AD app registration(또는 등록 중 생성되는 managed identity 유사 bot ID)에 해당합니다.
- appSecret은 해당 app registration의 client secret입니다. 프로덕션에서는 Azure Key Vault에 저장하고 App Service/Function 구성 설정을 통해 참조합니다.
- 가능하면 secrets 대신 certificate 자격 증명을 선호하여 더 강력한 보안과 더 쉬운 rotation을 구현합니다.
- bot의 messaging endpoint가 HTTPS로 접근 가능해야 하며, App Service/Function 구성에 MicrosoftAppId 및 MicrosoftAppPassword(또는 동등한 설정)가 포함되어야 합니다.
이는 Azure Well-Architected Framework 보안 원칙(least privilege, secure secret storage, credential rotation)과 일치합니다.
일반적인 오해:
- botId를 appId와 혼동하는 경우가 많지만, Bot Channels Registration은 인증에 별도의 “botId” 값이 아니라 Azure AD app ID를 사용합니다.
- tenantId 및 objectId는 Azure AD 식별자이지만, 런타임 인증을 위한 bot 채널 등록 구성에는 필요하지 않습니다.
시험 팁:
Bot Framework/Azure Bot Service 관련 문제에서는 채널 등록 및 bot 인증에 필요한 쌍으로 “Microsoft App ID”와 “Microsoft App Password/secret”을 찾으십시오. Tenant/object IDs는 일반적으로 기본 bot 채널 배포가 아니라 디렉터리 범위 작업에 사용됩니다.
8
문제 8
(2개 선택)
Computer Vision client library를 사용하는 메서드를 개발하고 있습니다. 이 메서드는 이미지에서 optical character recognition (OCR)을 수행합니다. 메서드에는 다음 코드가 있습니다.
public static async Task ReadFileUrl(ComputerVisionClient client, string urlFile)
{
const int numberOfCharsInOperationId = 36;
var txtHeaders = await client.ReadAsync(urlFile, language: "en");
string opLocation = textHeaders.OperationLocation;
string operationId = opLocation.Substring(opLocation.Length - numberOfCharsInOperationId);
ReadOperationResult results;
results = await client.GetReadResultAsync(Guid.Parse(operationId));
var textUrlFileResults = results.AnalyzeResult.ReadResults;
foreach (ReadResult page in textUrlFileResults)
{
foreach (Line line in page.Lines)
{
Console.WriteLine(line.Text);
}
}
}
테스트 중에 GetReadResultAsync 메서드 호출이 read 작업이 완료되기 전에 발생하는 것을 발견했습니다.
read 작업이 완료될 때까지 GetReadResultAsync 메서드가 진행되지 않도록 해야 합니다.
어떤 두 가지 작업을 수행해야 합니까? 각 정답은 솔루션의 일부를 제시합니다.
참고: 각 정답 선택은 1점입니다.
오답입니다. GetReadResultAsync는 OCR 작업의 상태와 결과를 가져오기 위해 operation identifier가 필요합니다. .NET SDK에서는 일반적으로 Guid로 전달합니다(따라서 Guid.Parse 사용). 매개변수를 제거하면 컴파일되지 않으며 Read 작업의 비동기 특성과도 관련이 없습니다. 타이밍 문제는 ID 전달 방식을 바꾸는 것이 아니라 폴링으로 해결합니다.
정답입니다. get_read_result 응답에는 status 필드(일반적으로 "notStarted", "running", "succeeded", "failed")가 포함됩니다. 이 status를 확인하고 "succeeded"가 된 후에만 analyze_result/read_results를 처리해야 합니다. 이것이 OCR 작업이 끝나기 전에 line을 읽으려는 시도를 방지하는 핵심 가드입니다.
오답입니다. ReadAsync에서 반환되는 객체는 주로 결과를 폴링하기 위해 사용하는 Operation-Location 헤더를 제공합니다. 완료 status는 초기 응답 헤더에서 신뢰성 있게 얻을 수 없으며, 대신 GetReadResultAsync를 호출하고 반환된 ReadOperationResult.Status를 검사해야 합니다. txtHeaders.Status를 확인하는 것은 OCR 처리가 끝났는지 판단하는 올바른 메커니즘이 아닙니다.
정답입니다. 작업이 비동기이므로 완료될 때까지 get_read_result를 폴링해야 합니다. 지연(delay)을 포함하는 루프 안에서 get_read_result를 호출하면 서비스를 과도하게 호출하는 것(rate limit/throttling)을 방지하고 백엔드 OCR 작업이 완료될 시간을 제공합니다. 견고하고 시험에 적합한 솔루션을 위해 status 확인 및 timeout과 함께 사용합니다.
문제 분석
핵심 개념:
Azure AI Vision Read (OCR)은 비동기 작업입니다. 초기 호출(read)은 Operation-Location 헤더를 즉시 반환하며, 이 헤더는 서버 측 작업을 가리킵니다. 결과를 사용하기 전에 작업이 종료 상태(terminal state)에 도달할 때까지 서비스를 폴링(polling)해야 합니다.
정답이 맞는 이유:
get_read_result(.NET에서는 GetReadResultAsync)가 완료 전에 진행되지 않도록 하려면 폴링을 구현합니다. 폴링에는 (1) get_read_result를 반복 호출하고 (2) 반환된 status를 확인하여 "succeeded"(또는 종료 실패 상태)일 때까지 기다리는 과정이 필요합니다. 따라서:
- read_results/status 값을 확인하는 코드를 추가합니다(B). Read API는 "notStarted", "running", "succeeded", "failed"와 같은 status를 반환합니다. status가 "succeeded"일 때만 analyze_result.read_results를 반복 처리해야 합니다.
- 지연(delay)을 포함하는 루프 안에서 get_read_result 호출을 래핑합니다(D). 지연이 없으면 타이트 루프가 되어(CPU 낭비, rate limit 초과) 완료를 보장하지 못합니다.
주요 기능 / 모범 사례:
- sleep/backoff(예: 1~2초)와 최대 timeout을 포함한 폴링 루프를 사용하여 무한 대기를 방지합니다.
- 종료 실패 상태("failed")를 처리하고 오류를 raise/log합니다.
- 이는 Azure Well-Architected Framework의 reliability 및 performance efficiency에 부합합니다: 불필요한 호출을 피하고, transient 상태를 처리하며, timeout을 구현합니다.
일반적인 오해:
일부는 Operation-Location 자체가 status를 변경한다고 생각하지만(그렇지 않음), 이는 단지 조회할 URL입니다. 또 다른 일부는 operation_id를 제거하면 동기 동작이 된다고 생각하지만, Read API는 본질적으로 비동기입니다.
시험 팁:
AI-102에서는 다음을 기억하세요: Vision Read/OCR은 비동기 패턴(제출 -> Operation-Location -> 결과 폴링)을 사용합니다. “작업이 완료되지 않음”과 관련된 질문은 일반적으로 “지연을 포함한 루프에서 status를 폴링하여 succeeded/failed가 될 때까지 대기”를 기대합니다.
9
문제 9
참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 하나입니다. 시리즈의 각 질문에는 명시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다.
이 섹션에서 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다.
Azure Cognitive Search 서비스가 있습니다.
지난 12개월 동안 쿼리 볼륨이 꾸준히 증가했습니다.
Cognitive Search 서비스에 대한 일부 검색 쿼리 요청이 제한(throttling)되고 있음을 발견했습니다.
검색 쿼리 요청이 제한(throttling)될 가능성을 줄여야 합니다.
솔루션: 더 높은 tier를 사용하는 Cognitive Search 서비스로 마이그레이션합니다.
이것이 목표를 충족합니까?
예. 더 높은 Azure Cognitive Search tier는 더 큰 리소스 용량과 더 높은 서비스 한계를 제공하므로, 증가하는 쿼리 볼륨에서 요청이 throttled될 가능성을 직접적으로 줄입니다. Throttling(종종 HTTP 429)은 서비스가 처리량 또는 리소스 사용률에 대한 tier/scale-unit 한계에 도달할 때 발생합니다. 더 높은 tier로 마이그레이션하면 사용 가능한 compute가 증가하고 더 높은 최대 replicas/partitions가 열릴 수 있어, 쿼리 처리 용량이 개선되고 throttling 가능성이 낮아집니다.
아니오가 틀린 이유는, 더 높은 tier로 이동하는 것이 용량 부족으로 인한 throttling을 완화하는 대표적인 방법이기 때문입니다. 더 높은 tier는 일반적으로 향상된 성능 특성과 더 높은 한계를 제공하여 증가한 쿼리 부하를 흡수하는 데 도움이 됩니다. 쿼리 처리량에 대한 가장 직접적인 해결책은 replicas를 scale out하는 것이지만, tier가 스케일을 얼마나 확장할 수 있는지와 기본 용량 자체를 제한하는 요인이 될 수 있습니다. 따라서 tier를 업그레이드하는 것은 throttling 가능성을 줄인다는 목표를 충족할 수 있습니다.
문제 분석
핵심 개념:
이 문제는 Azure Cognitive Search가 용량 한계와 throttling을 어떻게 처리하는지, 그리고 쿼리(읽기) 워크로드에서 throttling을 줄이기 위해 어떤 스케일링 조치가 효과적인지를 평가합니다.
정답이 맞는 이유:
Azure Cognitive Search는 서비스 tier와 사용 가능한 replicas/partitions 수에 따라 요청 속도 및 리소스 한계를 적용합니다. Throttling은 일반적으로 서비스가 쿼리 처리 용량의 한계에 도달했거나 근접했을 때 발생합니다(예: 초당 요청 수가 너무 많음, CPU/메모리 압박이 큼, 동시 작업이 너무 많음). 더 높은 tier로 마이그레이션하면 사용 가능한 리소스와 더 높은 서비스 한계를 제공하므로, 증가한 쿼리 볼륨에서 throttling 임계값에 도달할 가능성이 줄어듭니다. 따라서 더 높은 tier로 이동하는 것은 throttling 위험을 줄이는 유효한 방법입니다.
주요 기능 / 구성:
- Service tier는 전체 용량과 서비스 한계(예: 처리량, 스토리지, 성능 특성)를 결정합니다.
- Replicas는 쿼리 처리량과 가용성을 확장합니다(더 많은 replicas = 더 많은 쿼리 용량).
- Partitions는 인덱스/스토리지 및 ingestion 용량을 확장합니다(더 많은 partitions = 더 큰 인덱스 용량; 설계에 따라 성능에도 영향을 줄 수 있음).
- Throttling은 보통 HTTP 429 (Too Many Requests)로 나타나며, scale up(tier) 및/또는 scale out(replicas)으로 완화할 수 있습니다.
흔한 오해:
- Partitions가 주로 쿼리 throttling을 해결한다고 가정: partitions는 주로 인덱스 크기와 ingestion을 다루며, 쿼리 처리량의 주요 레버는 replicas입니다.
- Throttling이 오직 클라이언트 측 문제라고 생각: 재시도/backoff가 도움이 되긴 하지만, 지속적인 throttling은 보통 서비스 용량 부족을 의미합니다.
- Replicas를 늘릴 수 있으니 tier 변경은 무의미하다고 믿음: 일부 tier는 최대 replicas/partitions에 상한이 있고 성능 한계도 낮아, tier가 병목 요인이 될 수 있습니다.
시험 팁:
- 문제가 쿼리 throttling이라면: replicas를 늘리고/또는 더 높은 tier로 이동을 고려하세요.
- 문제가 indexing/스토리지 한계라면: partitions를 늘리고/또는 더 높은 tier로 이동을 고려하세요.
- 시나리오에서 HTTP 429를 확인하세요. 이는 종종 용량 throttling 신호입니다.
- Tier 업그레이드는 허용되는 최대 replicas/partitions를 높이고 처리량을 위한 여유(headroom)를 더 제공합니다.
10
문제 10
예측 유지보수를 수행할 계획입니다.
1년 동안 100대의 산업용 기계에서 IoT 센서 데이터를 수집합니다. 각 기계에는 50개의 서로 다른 센서가 있으며, 이 센서들은 1분 간격으로 데이터를 생성합니다. 총 5,000개의 time series 데이터셋이 있습니다.
기계 고장을 예측하는 데 도움이 되도록 각 time series에서 비정상적인 값을 식별해야 합니다.
어떤 Azure 서비스를 사용해야 합니까?
Anomaly Detector가 가장 적합한 이유는 요구 사항이 산업용 기계에서 수집된 시계열 sensor data의 비정상 값을 식별하는 것이기 때문입니다. Predictive maintenance는 일반적으로 시간에 따른 급증, 급감 또는 동작 변화와 같은 비정상 telemetry patterns를 찾는 데 의존합니다. 제시된 옵션 중 이것만이 문서 처리, search 또는 image analysis가 아니라 anomaly detection을 목적으로 하는 서비스입니다. 이 시험 문제의 맥락에서 이는 sensor 기반 time series를 분석하기 위한 예상 Azure 서비스입니다.
Cognitive Search는 knowledge mining(텍스트 및 문서(예: PDF, Office 파일, 구조화된 데이터) 인덱싱, enrichment, 쿼리)에 사용됩니다. 레코드를 저장하고 검색할 수는 있지만, 센서 telemetry를 위한 native time-series anomaly detection 알고리즘을 제공하지는 않습니다. 유지보수 로그나 매뉴얼을 검색하는 데는 유용할 수 있으나, time series에서 비정상적인 숫자 값을 탐지하는 용도는 아닙니다.
Form Recognizer(Azure AI Document Intelligence)는 invoice, receipt, form과 같은 문서에서 텍스트, key-value pair, table, 구조화된 필드를 추출합니다. 분 단위 센서 측정값과 같은 숫자 telemetry 스트림을 분석하거나 time-series 데이터에서 anomaly를 탐지하도록 설계되지 않았습니다. 유지보수 보고서를 디지털화하는 데는 도움이 될 수 있지만, 센서 판독값의 outlier를 식별하지는 못합니다.
Custom Vision은 라벨링된 이미지를 사용해 image classification 또는 object detection model을 학습시키는 computer vision 서비스입니다. time-series 센서 측정값을 분석하는 것이 아니라 시각적 검사 시나리오(예: 사진에서 결함 탐지)에 적합합니다. 이 문제는 많은 센서에 대한 순수한 time-series anomaly detection이므로 Custom Vision은 요구사항에 맞지 않습니다.
문제 분석
핵심 개념:
이 문제는 시계열 sensor telemetry에서 이상 징후를 탐지하도록 설계된 Azure 서비스를 선택하는 것에 관한 것입니다. Predictive maintenance 시나리오는 일반적으로 sensor readings의 스트림을 분석하여 급증, 급감 및 장비의 임박한 고장을 나타낼 수 있는 기타 비정상 패턴을 찾습니다.
정답인 이유:
제시된 옵션 중 Anomaly Detector는 시계열 데이터의 anomaly detection과 직접적으로 관련된 서비스입니다. 이 시나리오는 1분 간격으로 수집되는 5,000개의 개별 sensor series를 설명하며, 요구 사항은 문서를 검색하거나, form fields를 추출하거나, 이미지를 분류하는 것이 아니라 각 series에서 비정상 값을 식별하는 것입니다. 시험 관점에서 이는 시계열 anomaly detection을 위한 Azure 서비스에 직접적으로 해당합니다.
주요 기능:
- 텍스트, 문서 또는 이미지가 아니라 숫자형 시계열 분석을 위해 설계되었습니다.
- telemetry streams에서 outlier와 비정상 패턴을 탐지하는 데 사용됩니다.
- sensor 동작이 정상 운영 범위를 벗어나는 Predictive maintenance 시나리오에 적합합니다.
- 비정상 readings를 드러내기 위해 각 sensor stream을 독립적으로 분석하는 것을 지원합니다.
흔한 오해:
Cognitive Search는 anomaly scoring이 아니라 콘텐츠 indexing 및 querying을 위한 것입니다. Form Recognizer는 문서에서 정보를 추출하기 위한 것입니다. Custom Vision은 image classification 및 object detection을 위한 것입니다. 이러한 서비스 중 어느 것도 숫자형 시계열 anomaly detection을 위한 것은 아닙니다.
시험 팁:
문제에서 time series, telemetry, unusual values, outliers 또는 predictive maintenance가 언급되면, 옵션에 있다면 예상되는 시험 정답은 Anomaly Detector입니다. sensor data의 anomaly detection을 document AI, search 또는 computer vision 작업과 혼동하지 마세요.
