CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Microsoft AZ-204
Microsoft AZ-204

Practice Test #4

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

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

'예'라고 답하는 것은 Event Grid가 디바이스 telemetry 수집을 직접 수신하고 관리할 수 있다고 가정하기 때문에 잘못되었습니다. Event Grid는 이벤트를 필터링하고 라우팅할 수 있지만, 디바이스 수집 게이트웨이가 아니며 전 세계에 분산된 수천 개의 디바이스에 일반적으로 필요한 연결, authentication, 수집 의미 체계를 제공하지 않습니다. 또한 디바이스 식별자에 대한 filtering은 라우팅만 결정할 뿐이며, 내구성 있는 수집 및 상관관계/저장소 구성을 본질적으로 제공하지 않습니다. IoT Hub 또는 Event Hubs가 이러한 유형의 워크로드를 위해 의도된 서비스이며, 이후 Blob storage에 저장됩니다.

Azure Event Grid는 수천 개의 디바이스로부터 지속적인 디바이스 telemetry를 수신하는 기본 서비스로 설계되지 않았기 때문에 이 솔루션은 목표를 충족하지 않습니다. Event Grid는 개별 이벤트를 라우팅하고 핸들러를 트리거하는 데 최적화되어 있으며, 디바이스별 identity, 디바이스 authentication, telemetry 지향 수집 패턴과 같은 핵심 IoT 수집 기능이 부족합니다. Event Grid가 event filtering을 지원하더라도, filtering은 Blob storage에 저장하기 전에 대규모에서 디바이스 데이터를 안정적으로 수집하고 상관관계를 설정해야 한다는 요구 사항을 해결하지 못합니다. 더 적절한 접근 방식은 Azure IoT Hub(또는 Event Hubs)를 사용하여 디바이스 데이터를 수집한 다음, 이를 디바이스 식별자별로 구성된 Blob storage로 라우팅/처리하는 것입니다.

문제 분석

핵심 개념: 이 문제는 대규모 디바이스 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
문제 2

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

오답입니다. Azure Cosmos DB .NET SDK v3+에서 Container는 EndpointUri와 PrimaryKey로 직접 인스턴스화되지 않습니다. Container 객체는 CosmosClient에서 얻습니다(예: cosmosClient.GetContainer(databaseId, containerId)). client는 authentication, connection management, retries 및 기타 request pipeline behaviors를 처리하며, Container constructor는 이러한 기능을 이런 방식으로 제공하지 않습니다.

오답입니다. Cosmos DB .NET SDK v3+에서 Database는 EndpointUri와 PrimaryKey를 사용하는 constructor 호출로 생성되지 않습니다. 먼저 CosmosClient를 생성한 다음 Database 참조를 얻거나(예: cosmosClient.GetDatabase(databaseId)) CreateDatabaseIfNotExistsAsync를 통해 생성합니다. credentials 및 endpoint configuration은 Database가 아니라 CosmosClient에 속합니다.

정답입니다. CosmosClient는 Azure Cosmos DB에 대한 connectivity를 구성하고 요청을 실행하는 데 사용되는 기본 .NET SDK 객체입니다. account endpoint와 key(또는 다른 credentials)로 생성되며 application의 lifetime 동안 재사용되도록 설계되었습니다. CosmosClient에서 Database 및 Container 참조를 얻고 CRUD operations를 수행합니다.

문제 분석

핵심 개념: 이 문제는 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
문제 3

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

파트 1:

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

question-image

정답: A (정답). 올바른 작업 순서(유효한 순서 중 하나): 1) web app을 Standard App Service tier로 구성합니다. 2) web app에서 autoscaling을 활성화합니다(실질적으로는 App Service plan에서). 3) Scale condition을 구성합니다. 4) Scale rule을 추가합니다. 정답인 이유: D1 (Shared)는 autoscale을 지원하지 않습니다. Standard로 변경하는 것은 autoscale을 지원하는 가장 저렴한 tier이므로, “비용 최소화” 요구 사항을 충족합니다. 업그레이드 후 autoscale을 활성화한 다음 metric 기반 로직을 정의할 수 있습니다. “scale condition”은 metric(CPU Percentage)과 threshold 컨텍스트를 선택하는 곳이고, “scale rule”은 작업을 정의합니다(CPU가 약 85%일 때 scale out). 오답인 이유: Premium도 가능하지만 필요 이상으로 비용이 듭니다. “Azure App Services consumption plan으로 전환”은 유효한 App Service Web Apps plan이 아닙니다(consumption은 Azure Functions용). 따라서 시나리오를 충족하지 않습니다.

4
문제 4

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

파트 1:

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

question-image

정답. 활성 Azure AD tenant에 애플리케이션을 등록하기 위한 올바른 세 가지 작업 순서는 다음과 같습니다: 1) Azure AD 인스턴스를 선택합니다. (등록을 생성하기 전에 올바른 directory/tenant에 있어야 합니다.) 2) App Registrations에서 New registration을 선택합니다. (애플리케이션 객체를 생성하기 위한 portal 진입점입니다.) 3) 새 애플리케이션을 만들고 이름, account type, redirect URI를 제공합니다. (이들은 web app 등록에 필요한 핵심 입력값입니다.) 다른 선택지가 틀린 이유: - Enterprise Applications > New application은 주로 gallery/SaaS 앱을 추가하거나 기존 앱에 대한 service principal을 생성하는 데 사용되며, 자체 앱을 등록하는 표준 흐름이 아닙니다. - cryptographic key (certificate/secret) 추가는 선택 사항이며 일반적으로 등록 후 Certificates & secrets에서 수행합니다. - Manifest 선택은 등록 후의 고급 구성 단계입니다. - access token 사용은 런타임 단계이며 등록의 일부가 아닙니다.

5
문제 5

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

파트 1:

Client certificate 위치: ______

정답: A. HTTP request header. client certificates (mTLS)가 활성화된 Azure App Service에서는 플랫폼이 TLS를 종료하고 client certificate를 HTTP request header(일반적으로 X-ARR-ClientCert header로 노출됨)를 통해 애플리케이션에 전달합니다. 애플리케이션은 이 header를 읽고 검증/권한 부여 결정을 수행합니다. 다른 선택지가 틀린 이유: - B. Client cookie: Cookies는 클라이언트가 제어할 수 있으므로 certificate와 같은 TLS 인증 identity artifact를 전달하는 데 적절하지 않습니다. App Service는 certificate를 cookie에 넣지 않습니다. - C. HTTP message body: body는 애플리케이션 데이터이며 GET requests에는 존재하지 않을 수 있습니다. 또한 TLS client identity를 전달하는 표준 메커니즘도 아닙니다. - D. URL query string: query strings는 쉽게 로깅, 캐싱, 수정될 수 있습니다. App Service는 client certificate 전달에 이를 사용하지 않으며, 큰 certificate payload를 다루기에도 안전하지 않고 비실용적입니다.

파트 2:

인코딩 유형: ______

정답: D. Base64. X.509 certificate는 binary data(DER)입니다. 이를 HTTP header에서 전송하려면 ASCII-safe text로 표현되어야 합니다. Azure App Service는 request header 값에서 client certificate를 Base64를 사용해 인코딩합니다. 웹 앱은 Base64 string을 다시 bytes로 디코딩한 다음, thumbprint, issuer, expiration, chain trust와 같은 속성을 검증하기 위해 X509Certificate2(또는 유사한 것)를 생성합니다. 다른 선택지가 틀린 이유: - A. HTML: HTML은 markup language이며 binary certificate bytes를 안전하게 전송하는 데 사용되는 인코딩이 아닙니다. - B. URL: URL encoding은 URL/query string에서 문자를 escape하도록 설계되었으며, header에서 임의의 binary blob을 효율적으로 표현하기 위한 것이 아닙니다. - C. Unicode: Unicode는 text를 위한 character set/encoding이며, HTTP header용 binary certificate를 serialize하는 표준 방식이 아닙니다.

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

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

6
문제 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는 AZ-204 시나리오에서 FIFO 스타일 queueing 요구 사항에 가장 잘 맞는 Azure 메시징 서비스이기 때문입니다. Service Bus queue는 구성된 최대 크기로 생성할 수 있으며, Standard tier에서는 80 GB가 지원되는 queue 크기 옵션입니다. 또한 Service Bus trigger가 있는 Azure Function App을 사용하면 메시지가 도착할 때만 함수가 실행되므로 compute 비용을 최소화할 수 있으며, 이는 모바일 메시지가 불규칙하게 전송될 때 이상적입니다. 이 queue와 trigger의 조합은 시나리오에 명시된 순서, 용량, 비용 목표를 모두 충족합니다.

아니요는 오답입니다. 제안된 설계는 시험 목적상 제시된 요구 사항을 충분히 충족하기 때문입니다. Azure Service Bus queue는 80 GB를 포함한 구성 가능한 최대 queue 크기를 지원하므로 용량 요구 사항을 충족할 수 있습니다. 또한 Service Bus는 FIFO가 보장되지 않는 Azure Storage Queue와 달리, 순서 있는 전달이 필요할 때 적절한 Azure queueing 서비스입니다. 마지막으로 Azure Functions는 불규칙한 워크로드에 대해 비용 최소화에 도움이 되는 serverless consumption 모델을 제공하므로, 이 솔루션을 부정하는 것은 타당하지 않습니다.

문제 분석

핵심 개념: 이 문제는 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
문제 7

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

오답입니다. Put Blob은 요청 본문의 콘텐츠를 업로드하여 blob을 생성하거나 교체하는 데 사용됩니다. 이는 container 간 server-side copy 메커니즘이 아닙니다. Put Blob을 사용하려면 원본 blob 콘텐츠를 다운로드한 후 다시 업로드해야 하거나(또는 client가 다시 전송해야 하므로), 비효율적이며 event-driven 방식도 아닙니다.

정답입니다. Event Grid를 사용하여 Container1의 BlobCreated event를 구독하고(선택적으로 비디오에 대해 파일 확장자로 filtering 가능), event handler(일반적으로 Azure Function 또는 Automation runbook)가 Start-AzureStorageBlobCopy / Start Copy를 호출하여 Container2로 server-side copy를 수행할 수 있습니다. 이는 불규칙한 업로드와 새 비디오 생성 시 자동 복사라는 요구 사항에 부합합니다.

오답입니다. AzCopy는 대량 또는 ad-hoc 전송에 적합한 command-line tool이며 실행 환경(VM, container, pipeline agent)과 orchestration이 필요합니다. 본질적으로 event-driven이 아닙니다. Snapshot switch는 snapshot 작업용이지, 새 업로드에 자동으로 반응하여 생성 시 선택된 blob을 복사하기 위한 것이 아닙니다.

오답입니다. VM에 다운로드한 후 다시 업로드하면 불필요한 compute, storage I/O, latency 및 비용이 발생하고 운영 복잡성과 장애 지점이 증가합니다. 또한 Azure Storage 내에서 server-side copy를 사용할 수 있을 때의 모범 사례에도 어긋납니다. 이 접근 방식은 event-driven이고 확장 가능한 설계에 적합하지 않습니다.

문제 분석

핵심 개념: 이 문제는 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
문제 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 설정을 사용하도록 설정합니다. 이 솔루션이 목표를 충족합니까?

예. Consumption plan에서 실행되는 Azure Functions는 실행 timeout 제한의 적용을 받으며, 이는 장시간 실행되는 처리에서 일반적으로 실패를 유발합니다. Function App을 App Service (Dedicated) plan에서 호스팅하면 엄격한 Consumption 실행 제한이 제거되고 app이 blob 데이터를 처리할 만큼 충분히 오래 실행될 수 있습니다. Always On을 사용하도록 설정하는 것도 Dedicated plan에서 적절한데, 이는 Functions host가 계속 실행되도록 유지하고 유휴 기간 동안 app이 언로드되는 것을 방지하여 트리거된 function의 안정적인 실행에 중요하기 때문입니다.

아니요는 올바르지 않습니다. 제안된 변경은 Consumption plan으로 인해 발생하는 timeout 문제에 대한 유효한 완화 방법이기 때문입니다. Always On만으로는 실행 시간을 연장하지 않지만, 이 솔루션은 Always On만에 의존하지 않습니다. 또한 핵심 해결책인 hosting plan을 App Service로 변경합니다. Azure certification 시나리오에서 Always On을 사용하도록 설정한 Dedicated plan으로 이동하는 것은 장시간 실행되는 Azure Functions가 완료될 수 있도록 보장하는 인정된 답변입니다. Durable Functions 또는 queue 기반 설계도 좋은 아키텍처 선택일 수 있지만, 이 특정 솔루션이 제시된 목표를 충족하는 데 필수는 아닙니다.

문제 분석

핵심 개념: 이 문제는 Azure Functions hosting plan 동작, 특히 실행 timeout 제한과 non-Consumption plan에서의 Always On 역할을 테스트합니다. 핵심 포인트는 장시간 실행되는 Azure Functions가 Consumption plan에서 timeout될 수 있는 반면, App Service (Dedicated) plan은 적절히 구성되면 훨씬 더 길거나 사실상 무제한의 실행을 지원한다는 것입니다. 이 시나리오에서 App Service hosting plan으로 전환하고 Always On을 사용하도록 설정하는 것은 더 오래 실행되는 blob 처리 작업을 지원하는 인정된 방법입니다. 흔한 오해는 Always On 자체를 timeout 해결책으로 보는 것이지만, 실제로 엄격한 Consumption timeout 제한을 제거하는 것은 hosting plan 변경이며, Dedicated plan에서는 Functions runtime이 활성 상태를 유지하도록 Always On이 필요합니다. 시험 팁: function이 Consumption에서 허용하는 시간보다 더 오래 실행되어야 하는 경우, Dedicated 또는 Premium plan은 유효한 솔루션이며, Dedicated-hosted Function Apps에는 일반적으로 Always On이 요구됩니다.

9
문제 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 값을 사용하여 권한을 결정합니다. 이 솔루션이 목표를 충족합니까?

예. 이 솔루션은 웹사이트의 권한 수준을 Azure AD application roles로 올바르게 모델링하며, 이는 application authorization에 권장되는 접근 방식입니다. Azure AD는 이러한 app roles에 groups를 할당할 수 있도록 허용하므로, 사용자의 group membership가 개별적으로 권한을 할당하지 않고도 사용자가 받는 role을 결정할 수 있습니다. sign-in 후 application은 JWT의 roles claim을 검사하고 할당된 app role을 기반으로 사용자를 admin, normal 또는 reader로 authorization할 수 있습니다. 이는 authorization 로직을 깔끔하고 application 중심적으로 유지하면서 Azure AD group membership를 사용해 권한 수준을 결정해야 한다는 요구 사항을 충족합니다.

아니요는 틀렸습니다. 제안된 설계는 명시된 목표를 충족하기 때문입니다. 요구 사항은 단순히 app에서 Azure AD group membership를 직접 읽는 것이 아니라, 해당 membership를 사용해 권한 수준을 결정하는 것이며, groups를 app roles에 할당하면 정확히 이를 수행할 수 있습니다. 이 접근 방식은 Azure AD에서 지원되며, 디렉터리 group membership를 token에 노출되는 application별 roles로 변환하는 데 일반적으로 사용됩니다. 따라서 이 솔루션을 거부하는 것은 유효하고 권장되는 authorization 패턴을 무시하는 것입니다.

문제 분석

핵심 개념: 이 문제는 app roles와 Azure AD groups를 사용한 Azure AD application authorization을 테스트합니다. 목표는 Azure AD group membership를 기반으로 Azure Web App 사용자를 authorization하고, 해당 groups를 admin, normal, reader와 같은 권한 수준에 매핑하는 것입니다. 정답인 이유: Azure AD app registration에서 application roles를 정의하는 것은 application별 권한 수준을 나타내는 올바른 방법입니다. Azure AD는 enterprise application에서 security groups를 app roles에 할당하는 것을 지원하므로, 사용자는 group membership를 통해 해당 roles를 상속받을 수 있습니다. 사용자가 sign in하면 발급된 token에 roles claim으로 app roles가 포함될 수 있으며, web app은 authorization 결정을 위해 해당 claim을 사용할 수 있습니다. 주요 기능: App roles는 단순한 identity가 아니라 application authorization을 위해 설계되었습니다. Group-to-role assignment는 Azure AD에서 access management를 중앙 집중화하고 application에 group ID를 하드코딩하는 것을 방지합니다. roles claim을 사용하는 것은 특히 권한 수준이 application별인 경우 group claims를 직접 파싱하는 것보다 더 깔끔하고 확장성이 좋습니다. 일반적인 오해: 일반적인 실수는 요구 사항이 실제로는 application 권한 수준에 관한 것인데도 authorization을 위해 원시 group claims에만 의존하는 것입니다. 또 다른 오해는 app roles를 사용자에게만 직접 할당할 수 있다고 생각하는 것인데, Azure AD에서는 groups도 enterprise applications의 app roles에 할당할 수 있습니다. 응시자는 authentication과 authorization을 혼동할 수도 있지만, 이 시나리오는 Azure AD sign-in 이후의 authorization에 관한 것입니다. 시험 팁: AZ-204에서 admin 또는 reader와 같은 application 권한 수준을 묻는 문제에서는 일반적으로 app roles가 가장 적합합니다. 요구 사항에 group membership가 권한을 결정해야 한다고 명시되어 있다면, Azure AD groups를 app roles에 할당하는 것은 표준적이고 지원되는 패턴입니다. application이 사용하는 authorization 메커니즘으로 token의 roles claim 사용 여부를 확인하세요.

10
문제 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 값을 사용하여 권한을 결정합니다. 이 솔루션이 목표를 충족합니까?

예. Azure AD application이 group claims를 내보내도록 구성하는 것은 sign-in 시점에 Azure AD group membership를 web app에서 사용할 수 있게 하는 유효한 방법입니다. groupMembershipClaims를 All로 설정하면 Azure AD가 사용자의 관련 group identifier를 JWT에 포함할 수 있고, application은 해당 group ID를 admin, normal, reader 권한에 매핑할 수 있습니다. 이는 authorization이 사용자 지정 membership 저장소가 아니라 Azure AD group membership를 기반으로 해야 한다는 요구 사항을 충족합니다. 주요 주의 사항은 app이 많은 group에 속한 사용자의 group overage 시나리오를 처리해야 한다는 점이지만, 제안된 접근 방식은 여전히 목표를 충족합니다.

아니요는 올바르지 않습니다. 제안된 구성은 잘 알려진 Azure AD authorization 패턴이기 때문입니다. app registration은 group claims를 포함하도록 구성할 수 있으며, web app은 groups claim을 평가하여 사용자의 권한 수준을 결정할 수 있습니다. claim에 display name이 아니라 group object ID가 포함되더라도, app이 해당 ID를 roles에 매핑할 수 있으므로 authorization을 방해하지 않습니다. token 크기 제한과 가능한 overage 처리의 존재가 이 솔루션을 무효로 만들지는 않습니다.

문제 분석

핵심 개념: 이 문제는 Azure Web App에서 app authorization을 위해 Azure AD group claims를 테스트합니다. 제안된 솔루션은 token에 group ID를 포함시켜 admin, normal, reader와 같은 application roles를 Azure AD group membership로 제어합니다. 올바른 이유: app registration manifest 속성 groupMembershipClaims를 All로 설정하면, 해당되는 경우 Azure AD가 사용자의 security group 및 directory role membership를 token에 포함하고, app은 JWT의 groups claim을 검사하여 사용자를 권한 수준에 매핑할 수 있습니다. 주요 기능: group claims를 사용하면 app에서 별도의 user-role 저장소를 유지하지 않고도 authorization 결정을 내릴 수 있으며, 이는 Azure AD와 통합된 applications의 표준 패턴입니다. 일반적인 오해: group claims에는 친숙한 group 이름이 아니라 group object ID가 포함되며, 매우 많은 group membership는 Microsoft Graph 조회가 필요한 overage 동작을 유발할 수 있습니다. 시험 팁: Azure AD group membership를 기반으로 사용자를 authorize해야 하는 문제에서는 app registration에서 group claims를 활성화하고 groups claim을 읽는 것이 유효한 접근 방식입니다.

다른 모의고사

Practice Test #1

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

Practice Test #2

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

Practice Test #3

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

Practice Test #5

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

지금 학습 시작하기

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

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