연습 문제

문제 1

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 전 세계에 위치한 2,000개의 매장에서 point-of-sale (POS) 디바이스 데이터를 수집하기 위한 Azure 솔루션을 개발하고 있습니다. 단일 디바이스는 24시간마다 2 megabytes (MB)의 데이터를 생성할 수 있습니다. 각 매장 위치에는 데이터를 전송하는 디바이스가 1개에서 5개까지 있습니다. 디바이스 데이터는 Azure Blob storage에 저장해야 합니다. 디바이스 데이터는 디바이스 식별자를 기준으로 상관관계가 설정되어야 합니다. 앞으로 추가 매장이 개점할 것으로 예상됩니다. 디바이스 데이터를 수신하기 위한 솔루션을 구현해야 합니다. 솔루션: Azure Event Grid를 프로비저닝합니다. 디바이스 식별자를 평가하도록 event filtering을 구성합니다. 이 솔루션이 목표를 충족합니까?

문제 분석

핵심 개념: 이 문제는 대규모 디바이스 telemetry에 적합한 Azure 수집 서비스를 선택하고, Blob storage에 저장하기 전에 Event Grid(이벤트 알림/라우팅)와 고처리량 device-to-cloud 데이터 수집을 위해 설계된 서비스(IoT Hub/Event Hubs)의 차이를 이해하는지를 평가합니다. 정답인 이유: Event Grid는 주로 개별 이벤트(예: “blob created”, “resource changed”)를 위한 이벤트 라우팅 서비스이며, 수천 개의 POS 디바이스로부터 지속적인 디바이스 telemetry 업로드를 받기 위한 기본 엔드포인트로 설계되지 않았습니다. Event Grid는 event metadata에 대한 filtering을 지원하지만, 대규모에서 디바이스 데이터 스트림을 안정적으로 수신하고 버퍼링하는 데 필요한 디바이스 연결, 수집 의미 체계, 또는 telemetry 지향 기능을 제공하지 않습니다. 더 적절한 패턴은 Azure IoT Hub(또는 비-IoT 시나리오의 경우 Event Hubs)를 통해 디바이스 메시지를 수집한 다음, routing/Stream Analytics/Functions를 사용하여 디바이스 식별자별로 partitioning하여 Blob Storage에 쓰는 것입니다. 주요 기능 / 구성: - Azure Event Grid: 이벤트 알림, 핸들러로의 push delivery, event subject/type/data 필드에 대한 filtering, 이벤트에 대한 at-least-once delivery. - Azure IoT Hub: 디바이스별 identity, 디바이스 authentication, device-to-cloud telemetry 수집, storage/endpoints로의 message routing. - Azure Event Hubs: 고처리량 이벤트 수집, partitions/consumer groups; 일반적으로 Blob에 저장하기 위해 processors와 함께 사용됩니다. - 디바이스 식별자 기준 상관관계: IoT Hub device ID 또는 message properties를 사용하고, 효율적인 구성을 위해 /deviceId=/yyyy=/mm=/dd= 와 같은 Blob 경로에 씁니다. 일반적인 오해: - Event Grid를 임의의 디바이스 payload를 위한 범용 수집 엔드포인트로 가정하는 것; 이는 주로 Azure 서비스 또는 custom publishers가 내보내는 이벤트를 라우팅하기 위한 것이지, 대규모 direct device telemetry를 위한 것이 아닙니다. - “filtering”을 “correlation/storage partitioning”과 혼동하는 것; filtering은 이벤트가 어디로 가는지만 결정하며, 디바이스 ID별로 데이터를 본질적으로 구성하거나 저장하지는 않습니다. - IoT Hub가 제공하는 디바이스 관리 요구 사항(identity, authentication, throttling)을 간과하는 것. 시험 팁: - Event Grid는 반응형 워크플로와 알림(resource events, blob created 등)에 사용하고, 기본 telemetry 수집에는 사용하지 마세요. - 많은 디바이스가 데이터를 전송하는 경우: IoT Hub(디바이스 identity + telemetry) 또는 Event Hubs(stream ingestion)를 선호하세요. - 요구 사항에 “디바이스 식별자를 기준으로 상관관계 설정”이 포함되어 있다면, message properties + storage로의 downstream partitioning/routing을 떠올리세요. - 대상이 Blob Storage인 경우, 중간 수집 서비스와 processor(Functions/Stream Analytics) 또는 기본 제공 routing(IoT Hub routing)을 예상하세요.

문제 2

Azure 솔루션을 개발합니다. .NET API를 사용하여 No-SQL globally-distributed database에 연결해야 합니다. 데이터베이스에서 요청을 구성하고 실행하기 위한 객체를 만들어야 합니다. 어떤 코드 세그먼트를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 Azure Cosmos DB(a globally distributed NoSQL database)에 Azure Cosmos DB .NET SDK (v3+)를 사용하여 연결하는 방법을 테스트합니다. 이 SDK에서 요청을 구성하고 실행하기 위한 기본 진입점은 CosmosClient 객체이며, 이 객체는 connectivity, authentication, retries 및 효율적인 resource usage를 관리합니다. 정답인 이유: CosmosClient는 Cosmos DB account와 상호 작용하는 데 사용되는 최상위 client입니다. account endpoint URI와 key(또는 다른 credential)로 이를 생성한 다음, 이를 사용하여 Database 및 Container 객체에 대한 참조를 얻습니다(예: GetDatabase, GetContainer). CosmosClient는 오래 유지되고 application lifetime 전반에 걸쳐 재사용되도록 설계되어 connection management 및 performance optimizations를 가능하게 합니다. 따라서 new CosmosClient(EndpointUri, PrimaryKey)가 요청을 구성하고 실행하기 위한 올바른 코드 세그먼트입니다. 주요 기능 / 모범 사례: - socket exhaustion을 방지하고 performance를 향상시키기 위해 CosmosClient를 singleton(또는 app당 하나)으로 재사용합니다. - consistency, preferred regions, connection mode (Direct/Gateway), retries 및 diagnostics를 위해 CosmosClientOptions를 구성합니다. - 더 나은 security posture를 위해 가능하면 key 대신 Azure AD (DefaultAzureCredential)를 사용합니다. - Cosmos DB의 global distribution 및 multi-region reads/writes는 account 수준에서 처리되며, CosmosClient는 latency를 최적화하기 위해 ApplicationPreferredRegions로 구성할 수 있습니다. 이러한 내용은 Azure Well-Architected Framework의 pillars인 Performance Efficiency (client 재사용, preferred regions), Reliability (retries, multi-region), Security (keys보다 AAD)와 일치합니다. 일반적인 오해: 개발자는 때때로 endpoint/key로 Database 또는 Container를 직접 인스턴스화할 수 있다고 생각합니다. Cosmos DB .NET SDK에서 Database와 Container는 CosmosClient에서 얻는 논리적 resource reference이며, credential로 직접 생성하지 않습니다. 또 다른 혼동은 이전 SDK 패턴(DocumentClient)과 최신 CosmosClient 접근 방식을 혼동하는 것입니다. 시험 팁: AZ-204의 경우 object model을 기억하세요: CosmosClient (account-level) -> Database -> Container -> Items. connectivity를 구성하고 요청을 실행하는 객체를 묻는 문제라면 거의 항상 CosmosClient입니다. 또한 한 번 생성하고 여러 번 재사용하며, 가능하면 managed identity/AAD를 선호한다는 지침도 기억하세요.

문제 3

DRAG DROP - Web Apps 기능의 Microsoft Azure App Service를 사용하여 tier D1 app service plan을 사용하는 web app을 개발합니다. 트래픽 급증으로 인해 페이지 로드 시간이 증가했습니다. CPU 부하가 약 85%일 때 web app이 자동으로 scale되도록 보장하고 비용을 최소화해야 합니다. 어떤 네 가지 작업을 순서대로 수행해야 합니까? 답하려면 작업 목록에서 적절한 작업을 답 영역으로 이동하고 올바른 순서로 배열하세요. 참고: 정답 선택지의 순서는 하나 이상이 맞을 수 있습니다. 선택한 올바른 순서 중 어느 것이든 정답으로 인정됩니다. 선택 및 배치:

파트 1:

아래 이미지에서 정답을 선택하세요.

question-image

문제 4

DRAG DROP - 웹 애플리케이션을 개발합니다. 애플리케이션을 활성 Azure Active Directory (Azure AD) tenant에 등록해야 합니다. 어떤 세 가지 작업을 순서대로 수행해야 합니까? 답하려면 작업 목록의 모든 작업을 답안 영역으로 이동하고 올바른 순서로 배열하세요. 선택하고 배치하세요:

파트 1:

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

question-image

문제 5

HOTSPOT - Azure Web App을 개발하고 있습니다. 웹 앱에 대해 TLS mutual authentication을 구성합니다. 웹 앱에서 client certificate를 검증해야 합니다. 답하려면 답안 영역에서 적절한 옵션을 선택하세요. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:

파트 1:

Client certificate 위치: ______

파트 2:

인코딩 유형: ______

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

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

문제 6

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션에서 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 모바일 애플리케이션으로부터 메시지를 수신할 때 queue 데이터를 처리하는 Azure Service 애플리케이션을 개발하고 있습니다. 메시지는 서비스로 일관되게 전송되지 않을 수 있습니다. 다음 요구 사항이 있습니다: ✑ Queue 크기는 80 gigabytes (GB)를 초과하여 증가하면 안 됩니다. ✑ 메시지에 대해 first-in-first-out (FIFO) 순서를 사용해야 합니다. ✑ Azure 비용을 최소화해야 합니다. 메시징 솔루션을 구현해야 합니다. 솔루션: 모바일 애플리케이션에서 .Net API를 사용하여 Azure Service Bus Queue에 메시지를 추가합니다. Azure Service Bus Queue trigger를 사용하는 Azure Function App을 만듭니다. 이 솔루션이 목표를 충족합니까?

문제 분석

핵심 개념: 이 문제는 Azure Service Bus Queue와 해당 queue에 의해 트리거되는 Azure Function의 조합이 순서가 있는 메시징, 제한된 queue 용량, 그리고 저비용 event-driven 처리 요구 사항을 충족하는지 평가합니다. Azure Service Bus는 순서 보장 및 더 풍부한 broker 기능이 필요한 엔터프라이즈 queueing 시나리오를 위해 설계된 Azure 메시징 서비스입니다. Azure Functions는 메시지가 도착할 때만 실행되므로, 간헐적인 모바일 트래픽에 매우 적합합니다. 정답인 이유: 이 솔루션은 목표를 충족합니다. Service Bus queue는 최대 크기를 구성할 수 있으며, Standard tier에서는 80 GB를 지원하고, queue된 메시지에 대해 first-in-first-out 검색 의미 체계를 유지합니다. Service Bus trigger가 있는 Azure Function은 메시지가 존재할 때만 처리하므로, 트래픽이 일정하지 않을 때 compute 비용을 최소화합니다. 따라서 이 조합은 용량, 순서, 비용 요구 사항을 실용적인 Azure 네이티브 방식으로 해결합니다. 주요 기능: - Azure Service Bus Queue는 80 GB를 포함한 구성 가능한 최대 크기 값을 지원합니다. - Service Bus queue는 FIFO 스타일 처리에 적합한 순서 있는 brokered messaging을 제공합니다. - Service Bus trigger가 있는 Azure Functions는 serverless, event-driven 실행을 사용하여 유휴 compute 비용을 줄입니다. - 모바일 앱은 Service Bus용 .NET SDK를 사용하여 직접 메시지를 보낼 수 있습니다. 일반적인 오해: - 흔한 실수 중 하나는 Azure Storage Queue만이 저비용이라고 가정하는 것이지만, 이는 필요한 FIFO 동작을 제공하지 않습니다. - 또 다른 오해는 Service Bus에 크기 제한을 둘 수 없다는 것이지만, 실제로 queue 최대 크기는 지원되는 quota 값 내에서 구성 가능한 엔터티 속성입니다. - 일부 응시자는 sessions에 지나치게 집중하지만, 단일 queue 소비자 패턴의 경우 시험에서는 일반적으로 Storage Queue와 비교하여 Service Bus Queue를 FIFO를 지원하는 옵션으로 봅니다. 시험 팁: - 문제에서 FIFO 순서가 요구되면 일반적으로 Azure Storage Queue보다 Azure Service Bus Queue가 선호됩니다. - 메시지 도착이 일정하지 않다면 Azure Functions trigger가 대개 가장 비용 효율적인 compute 선택입니다. - 명시적인 queue 크기 요구 사항을 주의해서 보십시오. Service Bus queue 엔터티는 구성된 최대 크기를 지원하며, 이것이 이러한 시나리오에서 종종 결정적인 요소가 됩니다.

문제 7

사용자가 Azure storage에 사진과 비디오를 업로드할 수 있는 app을 개발하고 있습니다. 이 app은 storage REST API 호출을 사용하여 Account1이라는 blob storage account에 미디어를 업로드합니다. Container1 및 Container2라는 blob storage container가 있습니다. 비디오 업로드는 불규칙적으로 발생합니다. 새 비디오가 업로드될 때 특정 blob을 Container1에서 Container2로 복사해야 합니다. 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 Azure Blob Storage에 대한 event-driven automation을 테스트합니다. 업로드가 불규칙하게 발생할 때 polling 또는 수동 복사 방식은 비효율적입니다. 올바른 패턴은 storage event(BlobCreated)에 반응하고 serverless/action workflow를 트리거하여 blob을 복사하는 것입니다. 정답이 맞는 이유: Azure Event Grid는 storage account에서 발생하는 event(예: Microsoft.Storage.BlobCreated)를 구독할 수 있습니다. 새 비디오 blob이 Container1에 업로드되면 Event Grid는 endpoint(Azure Function, Logic App, Webhook 또는 Automation runbook)를 트리거할 수 있습니다. 그러면 해당 handler가 Storage SDK/REST(Copy Blob / Start Copy)를 사용하여 Container1에서 Container2로 server-side copy를 시작할 수 있습니다. 옵션 B는 일정에 의존하지 않고, 데이터를 client를 통해 이동시키지 않으면서, 새 비디오가 업로드될 때 자동으로 복사해야 한다는 핵심 요구 사항을 충족합니다. 주요 기능 및 모범 사례: Event Grid는 retry 및 dead-lettering 옵션과 함께 거의 실시간의 push-based notification을 제공하므로 Azure Well-Architected Framework 원칙(신뢰성 및 비용 최적화)에 부합합니다. 복사는 service-side operation(Start Copy)으로 수행되어야 하므로 데이터가 Azure Storage 내에 유지되어 egress, latency 및 compute를 최소화합니다. filtering(subject begins with /blobServices/default/containers/container1/ 및 ends with .mp4 등)을 적용하여 비디오만 workflow를 트리거하도록 할 수 있습니다. 일반적인 오해: 많은 사람들은 Put Blob이 blob을 “복사”할 수 있다고 생각하지만, Put Blob은 콘텐츠를 업로드하는 작업이며 storage 내부 복사를 수행하지 않습니다. 또 다른 선택지로 AzCopy를 고르기도 하지만, 이는 일반적으로 대량/수동 전송에 사용되며 여전히 host/agent와 orchestration이 필요합니다. virtual machine에 다운로드하는 방식은 가장 비효율적이며 불필요한 compute, 비용 및 장애 지점을 추가하므로 모범 사례에 어긋납니다. 시험 팁: “blob이 생성될 때” 또는 “업로드에 반응”과 같은 표현이 나오면 Event Grid + Function/Logic App을 떠올리십시오. “storage 내에서 복사”는 다시 업로드하는 방식보다 server-side copy(Start Copy / Copy Blob)를 떠올리십시오. 또한 Event Grid는 polling을 제거하고 비용을 줄여 주므로 불규칙한 event에 이상적이라는 점도 기억하십시오.

문제 8

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 귀하는 Azure Storage blob 데이터를 처리하기 위해 HTTP 트리거 Azure Function app을 개발합니다. 이 app은 blob의 output binding을 사용하여 트리거됩니다. 이 app은 4분 후에도 계속 timeout됩니다. app은 blob 데이터를 처리해야 합니다. app이 timeout되지 않고 blob 데이터를 처리하도록 해야 합니다. 솔루션: app이 App Service hosting plan을 사용하도록 구성하고 Always On 설정을 사용하도록 설정합니다. 이 솔루션이 목표를 충족합니까?

문제 9

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션에서 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 귀하는 Azure Web App으로 실행될 웹사이트를 개발하고 있습니다. 사용자는 자신의 Azure Active Directory (Azure AD) 자격 증명을 사용하여 인증합니다. 웹사이트에 대해 사용자에게 다음 권한 수준 중 하나를 할당할 계획입니다: admin, normal, reader. 사용자의 Azure AD group membership를 사용하여 권한 수준을 결정해야 합니다. authorization을 구성해야 합니다. 솔루션: ✑ 새 Azure AD application을 만듭니다. application의 manifest에서 application에 필요한 권한 수준과 일치하는 application roles를 정의합니다. ✑ 각 role에 적절한 Azure AD group을 할당합니다. 웹사이트에서 사용자의 JWT에 있는 roles claim 값을 사용하여 권한을 결정합니다. 이 솔루션이 목표를 충족합니까?

문제 10

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있고, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션에서 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 귀하는 Azure Web App으로 실행될 웹사이트를 개발하고 있습니다. 사용자는 자신의 Azure Active Directory (Azure AD) 자격 증명을 사용하여 인증합니다. 귀하는 웹사이트에 대해 사용자에게 다음 권한 수준 중 하나를 할당할 계획입니다: admin, normal, reader. 사용자의 Azure AD group membership를 사용하여 권한 수준을 결정해야 합니다. authorization을 구성해야 합니다. 솔루션: ✑ 새 Azure AD application을 만듭니다. application의 manifest에서 groupMembershipClaims 옵션의 값을 All로 설정합니다. ✑ 웹사이트에서 사용자의 JWT에 있는 groups claim 값을 사용하여 권한을 결정합니다. 이 솔루션이 목표를 충족합니까?

Practice Test #4

3중 AI 검증 답안 및 해설

연습 문제

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #3

Practice Test #5

지금 학습 시작하기