Microsoft AZ-204

Practice Test #3

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

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

기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

GPT Pro

Claude Opus

Gemini Pro

선택지별 상세 해설

심층 문제 분석

3개 모델 합의 정확도

기출 문제

문제 1

사용자 계약을 저장해야 합니다. 계약이 완료된 후 어디에 저장해야 합니까?

문제 분석

핵심 개념: 이 문제는 나중에 처리하기 위해 완료된 “사용자 계약” 아티팩트를 유지하는 데 어떤 Azure messaging/eventing 서비스가 적절한지 평가합니다. AZ-204에서 이러한 선택지는 서로 다른 messaging 패턴에 매핑됩니다: queue 기반 작업 분산(Storage queues), 엔터프라이즈 messaging(Service Bus), 고처리량 telemetry streaming(Event Hubs), 그리고 event routing(Event Grid). 이들 중 어느 것도 Blob Storage 또는 Cosmos DB와 같은 장기 문서 저장소는 아니므로, 의도는 일반적으로 보관용 저장이 아니라 “비동기 처리를 위해 완료된 계약을 저장”하는 것입니다. A가 정답인 이유: Azure Storage queue는 완료된 계약을 나타내는 작은 메시지(예: 계약 ID, 사용자 ID, 타임스탬프, 그리고 서명된 문서가 저장된 위치를 가리키는 포인터/URL)를 유지하는 가장 단순하고 비용 효율적인 방법입니다. 이는 durable한 at-least-once delivery를 제공하며 웹/API 계층을 다운스트림 프로세서(Functions/WebJobs/worker services)와 분리합니다. 이는 급증하는 부하를 완화하고 producer와 consumer의 독립적인 확장을 가능하게 함으로써 Azure Well-Architected Framework의 reliability 및 performance 원칙과 부합합니다. 주요 기능 / 모범 사례: Storage queues는 고가용성이며, visibility timeout, poison message 처리(dequeue count를 통해), 그리고 Azure Functions 트리거를 지원합니다. 메시지는 작게 유지하고(최대 약 64 KB), 실제 계약 문서는 다른 곳(일반적으로 Blob Storage)에 저장하며 queue에는 metadata/포인터만 넣으십시오. managed identity/SAS를 적절히 사용하고, 저장 시 암호화(기본값) 및 네트워크 격리를 위한 private endpoints를 고려하십시오. 일반적인 오해: “계약 완료”가 event처럼 들리기 때문에 Event Grid와 Event Hubs를 선택하는 경우가 많습니다. 그러나 이러한 서비스는 durable한 작업 항목 저장소나 competing consumers를 위한 것이 아니라 event 배포/streaming을 위한 것입니다. Service Bus topics는 강력하지만, 고급 엔터프라이즈 기능(sessions, transactions, duplicate detection, ordered delivery, 독립 subscription을 가진 여러 subscriber)이 필요한 경우가 아니라면 일반적으로 과한 선택입니다. 시험 팁: 시나리오가 “나중에 작업 수행” 또는 “버퍼링 후 비동기 처리”라면 Queue를 떠올리십시오(단순하고 저비용이면 Storage queue, 고급 엔터프라이즈 요구 사항이면 Service Bus queue/topic). “어떤 일이 발생했음을 여러 시스템에 알림”이라면 Event Grid를 떠올리십시오. “대규모 streaming 데이터 수집”이라면 Event Hubs를 떠올리십시오.

문제 2

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 귀하는 사진을 관리하기 위한 software as a service (SaaS) 서비스를 개발합니다. 사용자는 사진을 web service에 업로드하고, 그러면 web service가 사진을 Azure Storage Blob storage에 저장합니다. storage account 유형은 General-purpose V2입니다. 사진이 업로드되면, 이미지의 mobile-friendly 버전을 생성하고 저장하도록 처리되어야 합니다. 이미지의 mobile-friendly 버전을 생성하는 프로세스는 1분 이내에 시작되어야 합니다. 사진 처리를 시작하는 프로세스를 설계해야 합니다. 솔루션: Blob storage events에서 사진 처리를 트리거합니다. 이 솔루션이 목표를 충족합니까?

문제 3

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

문제 분석

핵심 개념: 이 문제는 Azure Blob storage에 저장되기 전에 디바이스 식별자를 기준으로 라우팅/상관관계 지정되어야 하는 대규모 디바이스 telemetry에 적합한 Azure 수집 서비스를 선택하는지를 평가합니다. 정답인 이유: correlation filter가 있는 Azure Service Bus topic은 대규모 디바이스 telemetry 수집이 아니라 엔터프라이즈 메시징 패턴(애플리케이션 간 명령/이벤트)과 subscription 기반 라우팅을 위해 설계되었습니다. correlation filter는 속성(예: deviceId)을 기준으로 메시지를 라우팅할 수 있지만, Service Bus는 전 세계에 분산된 수천 개 디바이스를 위한 권장 진입점이 아니며, 디바이스 ID 관리, 디바이스별 연결 패턴 또는 telemetry에 최적화된 수집을 기본적으로 제공하지 않습니다. 향후 성장까지 고려한 글로벌 규모의 POS/IoT 스타일 디바이스 데이터의 경우, Azure IoT Hub(또는 순수 스트리밍용 Event Hubs)가 일반적인 수집 계층이며, 이후 데이터는 routing, capture 또는 다운스트림 처리를 통해 Blob Storage에 저장됩니다. 주요 기능 / 구성: - Service Bus Topics/Subscriptions: pub-sub 메시징, 메시지 속성에 대한 correlation filter, 순서가 보장된 처리를 위한 sessions. - IoT Hub: 디바이스별 ID, 디바이스 인증, device-to-cloud telemetry, Blob/Storage endpoint로의 message routing. - Event Hubs: 고처리량 이벤트 수집; Event Hubs Capture는 Azure Blob Storage/ADLS에 자동으로 쓸 수 있습니다. 일반적인 오해: - “correlation filter”를 “대규모 디바이스 상관관계 지정”과 동일시하는 것: 이는 메시지를 subscription으로 라우팅할 뿐이며 IoT 디바이스 관리나 telemetry 수집 최적화를 제공하지 않습니다. - Service Bus를 IoT 수집 서비스로 사용하는 것: Service Bus는 대규모 디바이스 fan-in이 아니라 애플리케이션 메시징 신뢰성과 워크플로에 최적화되어 있습니다. - Blob storage 요구 사항이 Service Bus를 의미한다고 믿는 것: storage는 sink이며, 핵심은 올바른 수집 서비스를 선택하는 것입니다. 시험 팁: - 디바이스가 관련되어 있고 디바이스별 ID/인증 및 확장 가능한 device-to-cloud 수집이 필요한 경우 IoT Hub를 우선 고려하세요. - 고처리량 스트리밍 수집에는 Event Hubs를 우선 고려하고, Blob/ADLS에 저장하려면 Capture를 사용하세요. - 원시 telemetry 수집보다는 엔터프라이즈 메시징(명령, 워크플로, 서비스 분리)에 Service Bus를 사용하세요.

문제 4

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 명시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 귀하는 Azure 솔루션을 개발합니다. Azure Resource Manager에서 특정 resource group에 대한 virtual machine (VM) 액세스 권한을 부여해야 합니다. Azure Resource Manager access token을 획득해야 합니다. 솔루션: X.509 certificate를 사용하여 VM을 Azure Resource Manager에 인증합니다. 이 솔루션이 목표를 충족합니까?

문제 분석

핵심 개념: 이 문제는 Azure VM에서 실행되는 workload에 대해 Azure Resource Manager (ARM) access token을 획득하는 방법과, Azure AD identity 및 Azure RBAC를 사용하여 해당 workload에 범위가 지정된 권한(예: 특정 resource group)을 부여하는 방법을 테스트합니다. 정답인 이유: X.509 certificate 자체를 사용하는 것은 Azure VM이 ARM에 인증하여 token을 획득하는 권장되거나 의도된 방법이 아닙니다. VM-to-ARM 액세스의 표준 접근 방식은 managed identity(system-assigned 또는 user-assigned)를 사용하는 것이며, 이를 통해 VM에 secret/certificate를 저장하지 않고 Azure Instance Metadata Service (IMDS)에서 token을 요청할 수 있습니다. 그런 다음 필요한 resource group 범위로 해당 managed identity에 Azure RBAC role assignment를 부여합니다. 따라서 제안된 certificate 기반 접근 방식은 이 시나리오에서 명시된 목표를 충족하지 않습니다. 주요 기능 / 구성: - VM의 workload identity를 위한 Azure resource용 managed identity(system-assigned 또는 user-assigned). - Azure Instance Metadata Service (IMDS) token endpoint: http://169.254.169.254/metadata/identity/oauth2/token. - resource group 수준으로 범위가 지정된 Azure RBAC role assignment(최소 권한). - Azure AD app registration 및 certificate credential은 일반적으로 service principal에 사용되며, 기본적인 VM workload identity 패턴으로 사용되지는 않습니다. 일반적인 오해: - Azure compute에서 ARM으로의 비대화형 인증에 certificate가 기본/필수 방법이라고 가정하는 것. - “certificate가 있는 service principal”(app registration credential)과 “VM identity”(managed identity), 그리고 token 획득 방식의 차이를 혼동하는 것. - 목표에 특정 resource group에 대한 액세스 권한 부여가 포함되어 있으며, 이는 managed identity에 대한 RBAC assignment를 통해 가장 깔끔하게 수행된다는 점을 간과하는 것. 시험 팁: - Azure VM이 ARM 또는 다른 Azure service를 호출해야 할 때는 Azure resource용 Managed Identity를 우선적으로 사용하십시오. - 권한을 제한하려면 RBAC scope(subscription/resource group/resource)를 사용하고, managed identity에 role을 할당하십시오. - certificate는 Azure AD app registration(service principal)과 함께 일반적으로 사용되지만, VM에서 credential 관리 부담을 초래합니다. - VM에서 ARM token을 획득할 때는 IMDS가 일반적인 token 획득 메커니즘임을 기억하십시오.

문제 5

귀하는 microservice architecture를 사용하는 e-commerce 솔루션을 개발하고 있습니다. 솔루션의 여러 부분 간에 transactional message를 통신하기 위한 communication backplane을 설계해야 합니다. 메시지는 first-in-first-out (FIFO) 순서로 전달되어야 합니다. 무엇을 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 microservices에서 communication backplane으로 사용되는 Azure messaging services를 테스트하며, 특히 first-in-first-out (FIFO) 전달이 필요한 transactional messaging을 요구합니다. Azure에서 서비스 간의 신뢰할 수 있고 순서가 보장되는 transactional messaging을 위해 설계된 서비스는 Azure Service Bus (queues/topics)이며, 특히 sessions를 사용할 때 그렇습니다. 정답인 이유: Azure Service Bus는 microservice architecture에 필요한 enterprise messaging pattern을 지원합니다: durable message storage, competing consumers, dead-lettering, duplicate detection, scheduled delivery, 그리고—이 문제에서 특히 중요한—message sessions (SessionId)를 사용할 때의 FIFO ordering입니다. queue 또는 subscription에서 sessions를 활성화하면, Service Bus는 session 내에서 ordered processing을 보장하고 주어진 session은 한 번에 하나의 consumer만 처리하도록 하여 해당 message stream의 FIFO semantics를 유지합니다. Service Bus는 또한 transactions (transaction scope 내에서 send/complete/defer/dead-letter)도 지원하므로, “transactional messages” 요구 사항과 일치합니다. 주요 기능 및 best practices: point-to-point command에는 Service Bus Queue를 사용하고, pub-sub events/commands에는 Topic/Subscription model을 사용합니다. FIFO ordering(세션별)을 달성하려면 Sessions를 활성화하고 partitioning strategy를 설계해야 합니다: ordering boundary를 나타내는 SessionId(예: OrderId 또는 CustomerId)를 선택하십시오. poison messages를 위해 retry policies, max delivery count, dead-letter queues를 구성하십시오. 예측 가능한 latency와 dedicated resources를 위해 Premium tier를 고려하십시오. Standard도 sessions를 지원하지만, 중요한 backplane에는 Premium이 자주 권장됩니다. 이는 Azure Well-Architected Framework의 reliability principles(durable messaging, backpressure, failure isolation)와 일치합니다. 흔한 오해: Storage Queues는 더 단순하고 저렴하지만, Service Bus sessions와 같은 방식의 strict FIFO guarantees를 제공하지 않으며 많은 enterprise messaging 기능(transactions across operations, topics/subscriptions, advanced dead-lettering controls)도 부족합니다. Event Hubs는 high-throughput telemetry streaming용이지 transactional command messaging용이 아닙니다. Event Grid는 at-least-once delivery를 사용하는 event routing용이며 FIFO guarantee가 없습니다. 시험 팁: “transactional messaging,” “FIFO,” “commands,” “microservices backplane,” 또는 “enterprise messaging”을 보면 Azure Service Bus를 떠올리십시오. “telemetry/streaming”이 언급되면 Event Hubs, “Azure resource events에 반응”이 언급되면 Event Grid, “basic features를 갖춘 simple queueing”이 언급되면 Storage Queues를 떠올리십시오.

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

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

문제 6

HOTSPOT - App Service on Linux에 web app을 배포할 계획입니다. App Service plan을 만듭니다. web app이 포함된 custom Docker image를 만들어 Azure Container Registry에 push합니다. container 내부에서 생성되는 console logs에 실시간으로 액세스해야 합니다. Azure CLI 명령을 어떻게 완성해야 합니까? 답하려면 답안 영역에서 적절한 옵션을 선택하세요. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:

파트 1:

az webapp log ______ --name Contosoweb --resource-group ContosoDevRG

파트 2:

______ filesystem

파트 3:

az ______ log ______ --name ContosoWeb --resource-group ContosoDevRG

파트 4:

az webapp log ______ --name ContosoWeb --resource-group ContosoDevRG

문제 7

DRAG DROP - Azure Blob storage를 사용하기 위한 애플리케이션을 개발하고 있습니다. Azure Blob storage가 change feeds를 포함하도록 구성했습니다. 스토리지 계정의 복사본을 다른 region에 만들어야 합니다. 데이터는 현재 스토리지 계정에서 새 스토리지 계정으로 스토리지 서버 간에 직접 복사되어야 합니다. 다른 region에 스토리지 계정의 복사본을 만들고 데이터를 복사해야 합니다. 어떤 순서로 작업을 수행해야 합니까? 답하려면 작업 목록의 모든 작업을 답 영역으로 이동하고 올바른 순서로 정렬하세요. 선택 후 배치:

파트 1:

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

question-image

문제 8

DRAG DROP - 당신은 microservices 솔루션을 개발하고 있습니다. 이 솔루션을 multinode Azure Kubernetes Service (AKS) cluster에 배포할 계획입니다. 다음 기능이 포함된 솔루션을 배포해야 합니다: ✑ reverse proxy 기능 ✑ 구성 가능한 트래픽 라우팅 ✑ 사용자 지정 인증서를 사용한 TLS 종료 어떤 구성 요소를 사용해야 합니까? 답하려면 적절한 구성 요소를 올바른 요구 사항에 끌어다 놓으세요. 각 구성 요소는 한 번, 여러 번 또는 전혀 사용되지 않을 수 있습니다. 내용을 보려면 창 사이의 분할 막대를 끌거나 스크롤해야 할 수도 있습니다. 참고: 각 정답 선택에는 1점이 부여됩니다. 선택 및 배치:

파트 1:

솔루션을 배포합니다.

파트 2:

클러스터 및 외부 IP addressing을 확인합니다.

파트 3:

여러 microservices로 라우팅되는 단일 public IP endpoint를 구현합니다.

문제 9

당신은 웹사이트를 개발합니다. 웹사이트를 Azure에서 호스팅할 계획입니다. 웹사이트가 게시된 후 높은 트래픽을 경험할 것으로 예상합니다. 비용을 최소화하면서도 웹사이트가 계속 사용 가능하고 응답성을 유지하도록 해야 합니다. 웹사이트를 배포해야 합니다. 어떻게 해야 합니까?

문제 분석

핵심 개념: 이 문제는 높은 트래픽이 예상되는 웹 앱에 대해, 가용성/응답성을 유지하면서 비용을 최소화할 수 있는 올바른 Azure compute 호스팅 모델을 선택하는지를 평가합니다. 핵심 서비스는 autoscale을 지원하는 Azure App Service (PaaS)와 IaaS 옵션(VMs/VM Scale Sets)입니다. 정답이 맞는 이유: Standard tier의 Azure App Service는 CPU, memory 또는 HTTP queue length와 같은 메트릭을 기반으로 autoscale(scale out/in)을 지원합니다. 이는 부하가 증가할 때 instance를 추가하고 부하가 감소할 때 instance를 제거함으로써 “게시 후 높은 트래픽”에 직접 대응하고, 비용을 최적화합니다. 또한 App Service는 instance 전반에 걸친 기본 제공 load balancing, 관리되는 OS/runtime patching, 그리고 App Service plan 내의 고가용성을 제공합니다. VMs를 실행하고 관리하는 것과 비교하면, App Service는 운영 오버헤드를 줄이고 Azure Well-Architected Framework(Operational Excellence, Reliability, Cost Optimization)에 부합합니다. 주요 기능 및 모범 사례: - Standard tier(이상)는 Azure Monitor Autoscale을 통한 autoscale 규칙을 지원합니다. - Scale out은 더 많은 instance를 추가하고, scale up은 SKU를 변경합니다. 트래픽 급증의 경우 일반적으로 scale out이 주요 수단입니다. - 기본 제공 플랫폼 기능: health monitoring, deployment slots(Standard+), 통합 load balancing. - 비용 최적화: 과도한 프로비저닝을 방지하기 위해 최소/최대 instance 수와 scale 규칙을 구성하고, 예측 가능한 피크에 대해서는 scheduled scaling을 고려합니다. 흔한 오해: - “Shared tier + autoscale”은 더 저렴해 보일 수 있지만, Shared는 autoscale을 지원하지 않으며 dev/test용의 리소스 제약이 있습니다. - “autoscale이 있는 단일 VM”은 유효한 접근 방식이 아닙니다. autoscale에는 여러 instance(VM Scale Sets) 또는 instance를 추가할 수 있는 PaaS가 필요합니다. - VM Scale Sets도 scale할 수 있지만, OS patching, web server 구성, 그리고 종종 외부 load balancer/application gateway까지 관리해야 하므로 일반적인 웹 앱에서는 보통 더 높은 운영 비용과 복잡성이 발생합니다. 시험 팁: AZ-204에서는 요구 사항이 IaaS(custom OS, 특수 networking, legacy dependencies)를 강제하지 않는 한 웹 앱에는 기본적으로 App Service를 선택하세요. 기억할 점: autoscale에는 적격 tier가 필요합니다(App Service의 경우 Standard 이상). 문제가 웹 호스팅에 대해 관리 오버헤드와 비용 최소화를 강조한다면, autoscale이 있는 App Service가 일반적으로 가장 적합합니다.

문제 10

(2개 선택)

클라이언트에게 Azure API Management 관리형 웹 서비스를 제공합니다. 백엔드 웹 서비스는 HTTP Strict Transport Security (HSTS)를 구현합니다. 백엔드 서비스에 대한 모든 요청에는 유효한 HTTP authorization header가 포함되어야 합니다. 인증 정책을 사용하여 Azure API Management 인스턴스를 구성해야 합니다. 사용할 수 있는 두 가지 정책은 무엇입니까? 각 정답은 완전한 솔루션을 제시합니다. 참고: 각 정답 선택에는 1점이 부여됩니다.