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

Practice Test #2

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

귀하는 Azure Blob storage를 사용하는 애플리케이션을 개발하고 있습니다. 이 애플리케이션은 감사 목적을 위해 storage account에서 blobs 및 blob metadata에 발생하는 모든 변경 사항의 transaction logs를 읽어야 합니다. 변경 사항은 발생한 순서대로 있어야 하며, create, update, delete 및 copy 작업만 포함해야 하고, 규정 준수 이유로 보존되어야 합니다. transaction logs를 비동기적으로 처리해야 합니다. 어떻게 해야 합니까?

Event Grid + Azure Functions는 비동기 처리 및 blob events에 대한 near-real-time 반응에 적합합니다. 그러나 compliance를 위한 권위 있는 transaction log는 아닙니다. 전달은 at-least-once이며, events가 중복될 수 있고, 모든 events에 대해 순서가 보장되지 않습니다. 보존도 본질적으로 제공되지 않으므로 events를 직접 저장해야 하며, 잘못 구성하면 여전히 events를 놓칠 수 있습니다.

Blob Storage Change Feed를 활성화하면 create, update, delete 및 copy 작업을 포함하여 blob 및 blob metadata 변경 사항에 대한 변경 불가능한 append-only log가 제공됩니다. 이는 auditing 및 compliance 시나리오를 위해 설계되었으며, feed files를 읽어 비동기 처리를 지원합니다. 또한 feed에 기록된 변경 사항의 순서를 보존하므로, 순서가 있는 transaction log 요구 사항에 가장 잘 부합합니다.

Storage Analytics logging(classic)은 request 수준의 logs를 캡처하지만, legacy 접근 방식이며 특히 blob 및 metadata 변경 사항에 대한 순서 있는 간결한 change log 요구 사항에 최적화되어 있지 않습니다. 많은 작업 유형으로 인해 noisy할 수 있고, parsing이 필요하며, Blob Change Feed 및 Azure Monitor diagnostic settings와 비교할 때 change tracking/auditing을 위한 권장되는 최신 솔루션이 아닙니다.

Azure Monitor HTTP Data Collector API는 custom logs를 Log Analytics로 보내는 데 사용됩니다. 이는 storage transaction history에 대한 기본 액세스를 제공하지 않습니다. 여전히 blob operations에 대한 source of truth가 필요하며, request bodies를 스캔하는 것은 blobs 및 metadata에 대한 순서 있는 create/update/delete/copy 변경 사항을 재구성하는 지원되거나 신뢰할 수 있는 방법이 아닙니다.

문제 분석

핵심 개념: 이 문제는 blobs 및 blob metadata의 변경 사항에 대한 변경 불가능하고 순서가 보장된 로그를 제공하는 Azure Blob Storage Change Feed를 테스트합니다. 이는 create/update/delete/copy 작업에 대한 내구성 있는 기록이 필요한 auditing, compliance 및 downstream processing 시나리오를 위해 설계되었습니다. 정답인 이유: 요구 사항은 blobs 및 blob metadata에 대한 모든 변경 사항의 transaction logs를, 발생한 순서대로, create, update, delete 및 copy로 제한하고, 규정 준수를 위해 보존하며, 비동기적으로 처리하는 것입니다. Blob Change Feed는 이를 위해 특별히 만들어졌습니다. 이는 storage account에 저장되는 append-only log files로 변경 사항을 기록하고, feed 내에서 순서를 유지하며, 정확히 관련된 변경 유형(create, update, delete 및 copy)을 포함합니다. feed가 Blob Storage에 저장되므로 batch jobs, Functions, Databricks/Synapse 또는 custom workers를 사용하여 비동기적으로 처리할 수 있으며, storage lifecycle management 및 immutability policies를 사용하여 compliance 요구 사항에 따라 보존할 수 있습니다. 주요 기능 / 구성 참고 사항: - storage account 수준에서 Change Feed를 활성화합니다. - change feed segments 및 events를 읽는 SDKs/APIs를 통해 feed를 사용합니다. - 보존/compliance: 필요한 기간 동안 보존하려면 lifecycle management를 사용하고, 규제 요구 사항에 변조 방지가 필요하다면 immutable blob policies (WORM)도 고려합니다. - Azure Well-Architected Framework(Reliability 및 Security)와 부합: durable하고 replayable한 log, 분리된 비동기 처리. 일반적인 오해: Event Grid는 near-real-time notifications에는 매우 적합하지만, compliance 등급의 완전하고 순서가 보장된 transaction log는 아닙니다. events는 at-least-once로 전달될 수 있고, 순서가 뒤바뀌어 도착할 수 있으며, 권위 있는 audit trail로 설계되지 않았습니다. Storage Analytics logs는 legacy 방식이며 blob metadata 변경 사항의 순서 있는 변경 추적에 그렇게 특화되어 있지 않습니다. Azure Monitor HTTP Data Collector는 custom log ingestion용이지, 권위 있는 storage transaction history를 추출하기 위한 것이 아닙니다. 시험 팁: “blob changes의 ordered log”, “auditing/compliance”, “create/update/delete/copy”를 보면 “Blob Change Feed”를 떠올리십시오. “events에 반응” 또는 “serverless processing 트리거”를 보면 “Event Grid”를 떠올리되, 엄격한 순서의 audit logs 용도는 아닙니다.

2
문제 2

HOTSPOT - 한 회사가 Java web app을 개발하고 있습니다. web app 코드는 https://github.com/Contoso/webapp에 있는 GitHub repository에 호스팅되어 있습니다. web app은 production으로 이동되기 전에 평가되어야 합니다. 초기 코드 릴리스를 staging이라는 deployment slot에 배포해야 합니다. web app을 만들고 코드를 배포해야 합니다. 명령을 어떻게 완성해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:

파트 1:

az ______ create --location centralus --name $resourcegroupname

정답: A (group). 명령 `az group create --location centralus --name $resourcegroupname` 는 Azure Resource Group을 생성하며, 이는 App Service plan, web app, deployment slot을 위한 논리적 컨테이너입니다. Resource group은 lifecycle, RBAC, billing 경계를 구성하고 관리하는 데 필요합니다. 다른 선택지가 틀린 이유: - B (webapp)는 App Service Web App을 생성하며, resource group은 생성하지 않습니다. - C (appservice plan)는 hosting plan을 생성하지만, 기존 resource group 내에 배치되어야 합니다. - D (webapp deployment slot)는 기존 web app 아래에 slot을 생성합니다. - E (webapp deployment source)는 기존 web app/slot에 대한 source control deployment를 구성합니다. Azure CLI에서 `az group`은 항상 resource group 작업에 사용되며, resource group에는 region metadata 값이 있기 때문에 `--location`이 필요합니다.

파트 2:

az ______ create --name $webappname --resource-group $resourcegroupname --sku S3

정답: C (`appservice plan`). `az appservice plan create --name $webappname --resource-group $resourcegroupname --sku S3` 명령은 web app을 호스팅할 App Service plan을 생성합니다. web app을 생성하기 전에 반드시 App Service plan이 존재해야 하며, Standard-tier SKU는 deployment slot을 지원합니다. 다른 옵션이 틀린 이유는 서로 다른 resource type을 생성하기 때문입니다. `group`은 resource group을 생성하고, `webapp`은 app 자체를 생성하며, `webapp deployment slot`은 app이 이미 존재한 후에만 slot을 생성할 수 있고, `webapp deployment source`는 호스팅 용량이 아니라 source control deployment를 구성합니다.

파트 3:

az ______ create --name $webappname --resource-group $resourcegroupname --plan $webappname

정답: B (webapp). 명령 `az webapp create --name $webappname --resource-group $resourcegroupname --plan $webappname` 는 App Service web app을 생성하고, 앞서 생성한 App Service plan에 연결합니다. `--plan` 파라미터는 web app을 compute resources 및 pricing tier에 바인딩합니다. 다른 선택지가 틀린 이유: - A (group)는 관련이 없습니다. resource group은 이미 존재합니다. - C (appservice plan)은 plan을 생성/수정하는 데 사용되지만, 여기서는 plan에서 실행될 web app을 생성하고 있습니다. - D (webapp deployment slot)은 기존 web app이 필요합니다. main app 자체를 생성하지는 않습니다. - E (webapp deployment source)는 deployment를 구성하는 것이지, web app 자체를 생성하는 것은 아닙니다. 실무 참고: Java의 경우 runtime stack(예: `--runtime "JAVA|11-java11"`)을 추가로 설정하거나 `az webapp config set`을 사용하는 경우가 많지만, 이 문제는 app + slot + GitHub deployment를 위한 최소 명령에 초점을 맞추고 있습니다.

파트 4:

az ______ create --name $webappname --resource-group $resourcegroupname --slot staging

정답: D (`webapp deployment slot`). 명령 `az webapp deployment slot create --name $webappname --resource-group $resourcegroupname --slot staging`는 기존 web app에 대해 `staging`이라는 이름의 deployment slot을 생성합니다. 이는 초기 코드 릴리스를 production에 직접 배포하는 대신 staging slot에 배포해야 하기 때문에 필요합니다. 다른 옵션들은 slot을 생성하지 않습니다. `group`은 resource group을 생성하고, `appservice plan`은 hosting plan을 생성하며, `webapp`은 기본 app을 생성하고, `webapp deployment source`는 slot이 이미 존재한 후에만 repository 기반 deployment를 구성합니다.

파트 5:

az ______ config --name $webappname --resource-group $resourcegroupname --slot staging --repo-url $gitrepo --branch master --manual-integration

정답: E (webapp deployment source). 명령 `az webapp deployment source config --name $webappname --resource-group $resourcegroupname --slot staging --repo-url $gitrepo --branch master --manual-integration` 는 staging slot에 대해 specifically GitHub 기반 deployment를 구성합니다. `deployment source config`, `--repo-url`, `--branch`의 존재는 source control integration을 나타냅니다. 다른 선택지가 틀린 이유: - A (group), C (appservice plan), D (webapp deployment slot)는 repository integration을 관리하지 않습니다. - B (webapp)는 app resource를 관리하지만 deployment source configuration subcommand는 아닙니다. 핵심 시험 포인트: `--slot staging`은 code가 production이 아니라 staging slot에 배포되도록 보장합니다. `--manual-integration`은 Azure가 webhook을 통해 모든 commit마다 자동으로 pull하지 않음을 의미합니다. 대신 수동으로 sync합니다(제어된 평가에 유용). production CI/CD에서는 일반적으로 GitHub Actions 또는 Azure DevOps pipelines를 더 자주 사용하지만, 이 CLI 방식도 유효하며 자주 출제됩니다.

3
문제 3

귀사는 Azure API를 개발하고 있습니다. Azure API에 대한 인증을 구현해야 합니다. 다음 요구 사항이 있습니다: 모든 API 호출은 보안되어야 합니다.

✑ API 호출자는 API에 credentials를 전송해서는 안 됩니다. 어떤 인증 메커니즘을 사용해야 합니까?

파트 1:

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

question-image

요구 사항에 의해 올바른 authentication mechanism이 명확하게 정의되어 있으므로 “Pass”라고 답하는 것이 적절합니다. API 호출을 안전하게 유지하면서 호출자가 API에 credentials를 보내지 않도록 하려면, Microsoft Entra ID (Azure AD)가 access tokens (JWTs)를 발급하는 OAuth 2.0/OpenID Connect를 사용해야 합니다. 호출자는 Entra ID에 authenticate하고, access token을 획득한 다음, 해당 token (Bearer)으로 API를 호출합니다. API는 token을 검증하고 scopes/roles를 기반으로 authorize합니다. 대안이 틀린 이유: API keys, shared access signatures 또는 basic authentication은 호출자가 secret/credential를 API에 보내야 하므로 요구 사항을 위반합니다. Mutual TLS/client certificates 역시 API endpoint에 credential를 제시하는 방식입니다. Entra ID의 token-based auth는 API에서 credential 처리를 피하고, short-lived tokens를 지원하며, 중앙 집중식 policy controls (conditional access, MFA, app roles/scopes)를 가능하게 하므로 exam best practices에 부합합니다.

4
문제 4

HOTSPOT - 귀하는 조직 내 팀과 관련된 프로젝트 데이터에 액세스하기 위한 웹사이트를 구축하고 있습니다. 이 웹사이트는 anonymous access를 허용하지 않습니다. 인증은 internal이라는 이름의 Azure Active Directory (Azure AD) app을 사용하여 수행됩니다. 이 웹사이트에는 다음과 같은 인증 요구 사항이 있습니다: ✑ Azure AD 사용자는 웹사이트에 로그인할 수 있어야 합니다. ✑ 웹사이트의 personalization은 Active Directory groups의 멤버십을 기반으로 해야 합니다. 인증 요구 사항을 충족하도록 애플리케이션의 manifest를 구성해야 합니다. manifest를 어떻게 구성해야 합니까? 답하려면, 답안 영역에서 적절한 구성을 선택하십시오. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:

파트 1:

"optionalClaims" ______

optionalClaims는 Azure AD group membership claims를 활성화하는 데 사용되지 않습니다. 이는 ID, access 또는 SAML tokens에서 특정 user attributes와 같은 추가 token claims를 요청하기 위한 것입니다. 요구 사항은 AD groups를 기반으로 사이트를 개인화하는 것이므로, 관련 manifest 설정은 groupMembershipClaims입니다. 따라서 이 요구 사항에 대해 optionalClaims를 "All"로 설정해서는 안 됩니다.

파트 2:

"groupMembershipClaims" ______

groupMembershipClaims는 토큰에 어떤 group membership을 포함할지와 포함 여부를 제어하며, "None", "SecurityGroup", "DirectoryRole", 또는 "All"과 같은 string 값을 사용합니다. Active Directory groups를 기반으로 개인화하는 웹사이트의 경우, 이 속성을 "All"로 설정하면 필요한 group claims가 포함되도록 보장합니다. true 값은 이 속성에 대한 올바른 manifest 형식이 아닙니다. optionalClaims는 group claims를 활성화하는 것과 관련이 없으므로, 이 요구 사항에 대한 올바른 메커니즘이 아닙니다.

5
문제 5

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

예. Event Grid system topics는 Azure 서비스의 이벤트를 확장 가능하고 관리형 방식으로 수집합니다. Advanced Filters는 관련 이벤트만 전달되도록 보장합니다. Event Grid trigger가 있는 Azure Functions는 serverless 처리 요구 사항을 충족하며 자동으로 확장됩니다. Event Grid의 retry 정책과 subscription dead-lettering은 실패한 전달이 조용히 손실되지 않고 재처리될 수 있도록 하는 강력한 reliability 패턴을 제공합니다.

아니요는 틀렸습니다. 제안된 솔루션은 HTTP-triggered function이 time out되는 것을 방지한다는 목표를 충족합니다. 작업을 Service Bus로 오프로드하면 function은 요청을 빠르게 확인 응답하고 별도의 queue-triggered function이 백그라운드에서 blob 데이터를 처리하도록 할 수 있습니다. 이렇게 하면 장시간 실행되는 처리가 HTTP 실행 경로에서 제거되며, 이것이 바로 여기서 필요한 것입니다. 문제에서 HTTP 응답 내에서 동기적 완료를 명시적으로 요구하지 않는 한, 이러한 비동기 설계는 적절합니다.

문제 분석

핵심 개념: 이 시나리오는 여러 Azure 서비스 전반에서 이벤트 라우팅/필터링을 위한 Azure Event Grid와 serverless 처리를 위한 Azure Functions (Event Grid trigger)를 테스트합니다. 또한 dead-lettering 및 retry 동작과 같은 reliability 패턴도 다룹니다. 정답인 이유: 서비스별 Event Grid system topics를 사용하는 것은 Blob Storage 및 Azure Resource Manager와 같은 Azure 서비스의 이벤트를 인프라를 관리하지 않고 거의 실시간으로 수집하는 적절한 방법입니다. Advanced Filters(이벤트 유형, subject, 데이터 필드 또는 리소스 패턴 기준)를 사용하는 event subscriptions는 애플리케이션이 관련 이벤트만 수신하도록 보장하여 다운스트림 처리와 사용자 지정 라우팅 코드를 최소화합니다. Event Grid trigger가 있는 Azure Functions는 “인프라 없음” 요구 사항을 충족하는 완전 관리형 auto-scaling 컴퓨팅 옵션을 제공합니다. 이벤트 누락 방지: Event Grid는 정의된 retry 기간 동안 기본 제공 retries와 함께 at-least-once delivery를 제공합니다. Function endpoint를 일시적으로 사용할 수 없거나 실패를 반환하면 Event Grid는 전달을 retry합니다. subscription에서 dead-lettering을 활성화하면(Storage account container로) retries 후에도 전달/처리할 수 없었던 이벤트를 캡처하여 나중에 재처리할 수 있게 하고 조용한 손실을 방지합니다. 이는 Azure Well-Architected Framework의 reliability 모범 사례(실패를 고려한 설계, asynchronous messaging 사용, poison/dead-letter 처리 구현)와 일치합니다. 주요 기능 및 모범 사례: - System topics: Azure 리소스 이벤트(예: Storage, ARM)를 위한 관리형 통합. - Advanced Filters: broker 수준에서 필터링하여 노이즈와 비용을 줄입니다. - Azure Functions Event Grid trigger: serverless이며 이벤트 볼륨에 따라 확장됩니다. - Dead-lettering: 전달할 수 없는 이벤트를 위한 운영상 안전장치. - idempotency 고려: Event Grid는 at-least-once이므로 Functions는 중복 이벤트를 안전하게 처리해야 합니다. 일반적인 오해: 일부는 Event Grid가 queue처럼 이벤트를 “저장”한다고 생각합니다. 그렇지 않습니다. 장기 보존을 제공하지 않으며, reliability는 retries와 dead-lettering 그리고 재처리 전략에서 나옵니다. 장시간 중단에 대비한 내구성 있는 버퍼링이 필요하다면 중간 계층으로 Service Bus/Storage Queue를 추가할 수 있지만, 제안된 설계는 여전히 dead-lettering과 retries를 통해 명시된 요구 사항을 충족합니다. 시험 팁: Azure 서비스의 거의 실시간 이벤트 처리와 필터링이 필요하면 Event Grid를 선택하십시오. serverless 처리가 필요하면 Azure Functions triggers와 함께 사용하십시오. 문제에서 “이벤트 누락 없음”을 강조하면 retries + dead-lettering을 떠올리고 idempotent handlers를 언급하는 것을 기억하십시오.

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

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

6
문제 6

HOTSPOT - Azure App Service에서 Azure web app 및 관련 서비스를 생성하는 CLI 스크립트를 만들고 있습니다. web app은 다음 변수를 사용합니다: 변수 이름 | 값 $gitrepo | https://github.com/Contos/webapp $webappname | Webapp1103 새로 생성된 web app에 GitHub의 코드를 자동으로 배포해야 합니다. 스크립트를 어떻게 완성해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하세요. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:

파트 1:

az group create --location westeurope --name myResourceGroup ______ --name $webappname --resource-group myResourceGroup --sku FREE

빈칸은 "--name $webappname --resource-group myResourceGroup --sku FREE"로 끝나며, 이는 App Service plan을 생성하는 구문과 일치합니다: "az appservice plan create --name <planName> --resource-group <rg> --sku <tier>". Web app은 plan에서 실행되어야 하므로(특정한 specialized offering을 사용하는 경우 제외) Web app을 생성하기 전에 plan이 필요합니다. 다른 선택지가 틀린 이유: - A (az webapp)는 Web app을 생성할 때 사용되지만, "--sku FREE"가 있다는 것은 Web app 속성이 아니라 plan SKU를 나타냅니다. - C (az webapp deployment)는 deployment 관련 작업용이며, plan 생성과는 관련이 없습니다. - D (az group delete)는 resource group을 삭제하는 명령으로, provisioning과 관련이 없습니다.

파트 2:

______ --repo-url $gitrepo --branch master --manual-integration

이 fragment는 "--repo-url", "--branch", "--manual-integration"과 같은 repository 관련 인수를 포함하고 있으므로 web app의 source control 구성과 관련되어 있습니다. plan parameter는 app을 App Service plan과 연결하기 위해 "az webapp create" 중에만 사용되며, deployment source configuration 단계에서는 유효하지 않습니다. 제공된 선택지 중에서 "git clone $gitrepo"만이 repository 관련 옵션이지만, 실제 Azure CLI script에서는 올바른 command가 로컬 Git clone이 아니라 "az webapp deployment source config"의 일부가 됩니다. 현재 explanation은 이 fragment를 잘못된 command context에 배치하고 있으므로 부정확합니다.

파트 3:

______ source config --name $webappname --resource-group myResourceGroup

Azure CLI는 App Service web app에 대해 GitHub 또는 기타 source control deployment를 구성하기 위해 "az webapp deployment source config" 명령을 사용합니다. 문제에 이미 "source config"가 포함되어 있으므로, 빠진 접두사는 "az webapp deployment"여야 합니다. 옵션 A인 "az webapp"은 불완전하며 이 구문에서 유효한 명령을 형성하지 않습니다. 나머지 옵션은 plan 생성 또는 resource group 삭제용이므로 해당되지 않습니다.

파트 4:

______ --repo-url $gitrepo --branch master --manual-integration

"az webapp deployment source config" 뒤에는 repository 설정을 제공합니다. 올바른 이어지는 부분은 "--repo-url $gitrepo --branch master --manual-integration"입니다. 이는 web app이 지정된 GitHub repository와 branch에서 pull하도록 구성합니다. "--manual-integration"은 App Service가 GitHub webhook integration을 자동으로 생성/관리하지 않음을 의미합니다(CLI session에서 GitHub에 authenticate하지 않을 때 자주 사용됨). 하지만 여전히 deployment source를 설정합니다. 다른 옵션이 틀린 이유: - B (--plan $webappname)는 web app을 생성할 때만 관련이 있습니다(App Service plan에 바인딩). 이는 "deployment source config"에 대한 유효한 parameter가 아닙니다.

7
문제 7

HOTSPOT - Azure Storage Client library for .NET을 사용하는 솔루션을 개발하고 있습니다. 다음 코드가 있습니다: (줄 번호는 참조용으로만 포함되어 있습니다.)

CloudBlockBlob src = null;
try
{
    src = container.ListBlobs().OfType().FirstOrDefault();
    var id = await src.AcquireLeaseAsync(null);
    var dst = container.GetBlockBlobReference(src.Name);
    string cpid = await dst.StartCopyAsync(src);
    await dst.FetchAttributeAsync();
    return id;
}
catch (Exception e)
{
    throw;
}
finally
{
    if (src != null)
        await src.FetchAttributesAsync();
    if (src.Properties.LeaseState != LeaseState.Available)
        await src.BreakLeaseAsync(new TimeSpan(0));
}

다음 각 문장에 대해, 문장이 참이면 Yes를 선택하세요. 그렇지 않으면 No를 선택하세요. 참고: 각 정답 선택은 1점의 가치가 있습니다. Hot Area:

파트 1:

이 코드는 무기한 lease를 생성합니다

예. 이 코드는 다음을 호출합니다: - line 06: var id = await src.AcquireLeaseAsync(null); Azure Storage .NET client library에서 AcquireLeaseAsync는 lease duration에 대해 nullable TimeSpan?을 받습니다. blob의 경우, duration에 null을 지정하면 무기한 lease를 요청합니다(15–60초의 고정 기간 lease와 반대). 무기한 lease는 명시적으로 해제될 때까지(lease ID와 함께 ReleaseLeaseAsync) 또는 중단될 때까지(BreakLeaseAsync) 유지됩니다. “아니요”가 틀린 이유: 유한한 lease는 허용된 범위 내의 특정 duration 값이 필요합니다. 이 코드에서는 null을 전달하므로, 무기한 lease 동작을 명시적으로 요청하는 것입니다.

파트 2:

06행의 코드는 항상 새로운 blob을 생성합니다

아니요. 06행의 코드는 새로운 blob을 생성하지 않습니다. 06행은 기존 source blob(src)에 대해 AcquireLeaseAsync를 호출합니다. 해당 작업은 기존 blob의 lease 상태만 변경할 뿐, 어떤 blob도 생성하지 않습니다. 질문의 의도가 “07행” (GetBlockBlobReference)을 의미한 것이었다고 하더라도, 그것 역시 service에서 blob을 생성하지는 않습니다. 그것은 단지 blob 이름을 가리키는 로컬 object를 생성할 뿐입니다. destination blob은 아직 존재하지 않는 경우 나중에 StartCopyAsync(08행)에 의해 생성될 수 있습니다. 따라서 “항상 새로운 blob을 생성한다”라는 진술은 올바르지 않습니다. leasing은 절대 blob을 생성하지 않으며, destination reference 생성 역시 server-side create 작업이 아닙니다.

파트 3:

finally 블록은 lease를 해제합니다

아니요. finally 블록은 lease를 “release”하지 않습니다. 대신 break를 시도합니다. 구체적으로: - src.Properties.LeaseState != LeaseState.Available를 확인합니다 - 그런 다음 BreakLeaseAsync(TimeSpan.Zero)를 호출합니다 Release vs Break: - ReleaseLeaseAsync는 lease를 해제하는 일반적인 방법이며 AcquireLeaseAsync에서 반환된 lease ID가 필요합니다. - BreakLeaseAsync는 lease ID 없이 lease를 강제로 종료하며, lease를 Broken을 거쳐 결국 Available 상태로 전환합니다. 또한 로직 문제가 있습니다: src.Properties.LeaseState는 FetchAttributesAsync 이후에만 채워지지만, 코드는 src != null 블록 밖에서 LeaseState를 확인합니다. src가 null이면 예외가 발생합니다. src가 null이 아니라고 가정하더라도, 이 작업은 여전히 release가 아니라 break이므로, 해당 문장은 거짓입니다.

8
문제 8
(2개 선택)

GitHub repository에서 Azure Web App으로 웹사이트를 배포할 준비를 하고 있습니다. 웹사이트에는 스크립트로 생성된 정적 콘텐츠가 포함되어 있습니다. Azure Web App continuous deployment 기능을 사용할 계획입니다. 웹사이트가 트래픽을 제공하기 시작하기 전에 정적 생성 스크립트를 실행해야 합니다. 이 목표를 달성할 수 있는 두 가지 가능한 방법은 무엇입니까? 각 정답은 완전한 솔루션을 제시합니다. 참고: 각 정답 선택에는 1점이 부여됩니다.

오답입니다. WEBSITE_RUN_FROM_PACKAGE는 앱이 마운트된 ZIP/package(또는 URL)에서 실행되도록 지시하는 App Service application setting입니다. 이것은 host.json에 구성되지 않으며(host.json은 Azure Functions용), 정적 생성 도구를 실행하지도 않습니다. 이 선택지는 관련 없는 개념들(Functions 구성 + App Service setting)을 혼합하고 있으며 어떤 스크립트도 실행하지 못합니다.

정답입니다. Web App의 .csproj에 있는 PreBuild(또는 유사한) MSBuild target은 build/publish output이 생성되기 전에 스크립트/명령을 실행할 수 있습니다. continuous deployment에서는 deployment 중에 build가 수행되므로 생성된 정적 콘텐츠가 배포된 artifact의 일부가 됩니다. 이렇게 하면 앱이 트래픽을 제공하기 시작하기 전에 콘텐츠가 존재하도록 보장합니다.

오답입니다. App Service는 설명된 방식으로 deployment 사용자 지정을 위해 /run 폴더의 run.cmd라는 특별한 메커니즘을 사용하지 않습니다. Windows App Service가 일부 시나리오에서 startup commands를 실행할 수는 있지만, 그것은 runtime startup 동작이며 GitHub continuous deployment를 사용자 지정하는 표준 메커니즘이 아닙니다. Kudu 사용자 지정을 위한 인식된 접근 방식은 .deployment + deploy.cmd입니다.

정답입니다. repository 루트의 .deployment 파일은 Kudu가 custom deployment script(일반적으로 deploy.cmd)를 가리키도록 할 수 있습니다. 해당 스크립트에서 먼저 정적 생성 단계를 실행한 다음 일반적인 deployment 단계를 수행할 수 있습니다. 이는 App Service continuous deployment와 직접 통합되며 트래픽이 제공되기 전에 생성된 콘텐츠가 준비되도록 보장합니다.

문제 분석

핵심 개념: 이 문제는 GitHub에서 Azure App Service (Web Apps)로의 continuous deployment와 앱이 트래픽을 제공하기 전에 build-time 단계(정적 사이트 생성)를 실행하는 방법을 테스트합니다. App Service에서 일반적인 build engine은 Kudu/Oryx이며, MSBuild targets(.NET 앱의 경우) 또는 .deployment 파일을 통한 Kudu custom deployment scripts를 사용하여 deployment pipeline을 사용자 지정할 수 있습니다. 정답이 맞는 이유: B가 정답인 이유는 project의 .csproj에 PreBuild target을 추가하면 정적 생성 스크립트가 build process에 통합되기 때문입니다. continuous deployment에서는 App Service가 deployment 중에 앱을 build합니다. PreBuild는 compilation/publish output이 생성되기 전에 실행됩니다. 이렇게 하면 생성된 정적 asset이 배포된 artifact에 포함되므로 사이트가 시작될 때 콘텐츠가 이미 존재하게 됩니다. D가 정답인 이유는 repo 루트의 .deployment 파일이 Kudu에 custom deployment script(예: deploy.cmd)를 실행하도록 지시할 수 있기 때문입니다. 해당 스크립트에서 먼저 정적 생성 단계를 실행한 다음 일반적인 deployment 단계를 진행할 수 있습니다. 이는 기본 제공 continuous deployment를 사용할 때 CI/CD 동작을 사용자 지정하는 표준적인 App Service 기법입니다. 주요 기능 / 모범 사례: - Kudu custom deployment: .deployment + deploy.cmd를 사용하면 pre/post 단계, environment variables, tooling installation을 제어할 수 있습니다. - MSBuild targets: PreBuild/BeforeBuild/AfterBuild targets는 .NET 기반 Web Apps에 신뢰할 수 있으며 build logic을 코드와 함께 버전 관리할 수 있게 합니다. - Azure Well-Architected 관점에서 generation을 runtime이 아닌 build/deploy 시점에 수행하면 reliability와 performance가 향상되고(런타임 생성 지연 없음) 반복 가능한 deployment를 지원합니다. 일반적인 오해: - runtime startup scripts와 deployment-time build steps를 혼동하는 것. 요구 사항은 “트래픽을 제공하기 전에”이며, 이는 첫 요청 시점이 아니라 deployment/build 중에 콘텐츠를 생성함으로써 가장 잘 충족됩니다. - WEBSITE_RUN_FROM_PACKAGE 같은 app settings를 잘못 사용하는 것. 이것은 package mounting 동작을 제어할 뿐, 도구를 실행하지는 않습니다. 시험 팁: AZ-204에서는 App Service 기본 제공 CI/CD가 Kudu를 사용한다는 점을 기억하세요. deployment를 사용자 지정하려면 .deployment/deploy.cmd를 사용합니다. .NET build의 경우 .csproj의 MSBuild targets는 pre-build 작업을 실행하여 asset이 published output에 포함되도록 하는 깔끔한 방법입니다.

9
문제 9

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 귀하는 의료 기록 문서 관리 웹사이트를 개발하고 있습니다. 이 웹사이트는 환자 접수 양식의 스캔 사본을 저장하는 데 사용됩니다. 저장된 접수 양식이 제3자에 의해 스토리지에서 다운로드되더라도, 양식의 내용이 손상되어서는 안 됩니다. 요구 사항에 따라 접수 양식을 저장해야 합니다. 솔루션:

  1. skey라는 이름의 Azure Key Vault key를 만듭니다.
  2. skey의 public key 부분을 사용하여 접수 양식을 암호화합니다.
  3. 암호화된 데이터를 Azure Blob storage에 저장합니다. 이 솔루션이 목표를 충족합니까?

예는 오답입니다. 제안된 설계는 Key Vault key를 직접 파일 암호화에 잘못 사용하고 있기 때문입니다. Public-key encryption은 payload 크기 제한이 있으며, 스캔된 의료 양식과 같은 대형 blob에 대해 계산적으로 비효율적입니다. 다운로드된 파일을 보호하려는 의도는 타당하지만, 설명된 구체적인 구현은 암호화된 문서를 대규모로 저장하기 위한 올바른 Azure 접근 방식이 아닙니다.

아니요. 이 솔루션은 접수 양식을 Azure Key Vault key의 public key 부분으로 직접 암호화하도록 제안하므로 요구 사항을 적절하게 충족하지 못합니다. RSA key와 같은 Azure Key Vault asymmetric key는 소량의 데이터를 암호화하거나 symmetric key를 래핑하는 용도로 설계되었으며, 전체 스캔 문서와 같은 대량 암호화용이 아닙니다. 문서 저장의 올바른 설계는 파일 내용에는 symmetric encryption을 사용하고, 해당 symmetric key는 Key Vault로 보호하는 것으로, 이는 표준 envelope encryption 패턴입니다.

문제 분석

핵심 개념: 이 문제는 민감한 문서를 저장 시 보호하여, 권한이 없는 제3자가 blob을 다운로드하더라도 문서 내용을 읽을 수 없게 하는 것에 관한 것입니다. Azure에서는 일반적으로 암호화를 통해 이를 달성하지만, Azure Key Vault asymmetric key는 스캔된 접수 양식과 같은 대용량 파일을 직접 암호화하는 용도로 설계되지 않았습니다. 정답인 이유: 제안된 솔루션은 Key Vault key의 public key 부분을 사용하여 접수 양식을 암호화한 후 Blob Storage에 저장하라고 하지만, asymmetric encryption은 작은 payload 및 key-wrapping 시나리오에만 적합하며 전체 문서 암호화에는 적합하지 않습니다. 주요 특징: 올바른 패턴은 envelope encryption으로, symmetric key가 문서를 암호화하고 asymmetric key 또는 Key Vault가 그 symmetric key를 보호합니다. 흔한 오해: 많은 응시자는 어떤 Key Vault key든 임의의 파일을 직접 암호화하는 데 사용할 수 있다고 생각하지만, RSA key 작업에는 크기 제한이 있으며 대량 데이터 암호화를 위해 설계되지 않았습니다. 시험 팁: 문서 또는 blob 암호화가 포함된 문제에서는 전체 파일에 대한 직접 asymmetric encryption보다 client-side encryption 또는 envelope encryption을 우선 고려하십시오.

10
문제 10

HOTSPOT - 인증을 위해 API Management를 구성해야 합니다. 어떤 policy 값을 사용해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하세요. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:

파트 1:

정책 ______

정답: D. JWT 검증. validate-jwt 정책은 OAuth 2.0/OpenID Connect access token (JWT)을 사용하여 호출자를 인증/권한 부여하기 위한 전용 APIM 메커니즘입니다. 이 정책은 token signature(신뢰), token lifetime(exp/nbf), 그리고 intended recipient(aud)를 검증하며, issuer(iss) 및 필요한 claims/scopes/roles도 강제할 수 있습니다. 프롬프트가 인증을 위해 APIM을 구성하는 것에 관한 경우, 이것이 기대되는 정답입니다. 다른 선택지가 틀린 이유: A. HTTP header 확인은 header가 존재하는지 또는 값이 일치하는지만 확인하며, token을 cryptographically 검증하거나 identity를 증명하지는 않습니다. B. 호출자 IP 제한은 network control(노출 범위를 좁히는 데 유용함)이지만 user/app을 인증하지 않으며 roaming clients/NAT 환경에서는 실패합니다. C. key별 호출 속도 제한은 throttling/abuse protection입니다. subscription key를 사용할 수는 있지만 이는 강력한 인증이 아니며, 일반적으로 primary auth라기보다 추가적인 control로 간주됩니다.

파트 2:

Policy 섹션 ______

정답: A. Inbound. 인증은 요청이 backend service로 전송되기 전에 강제되어야 합니다. inbound policy 섹션은 요청이 APIM에 들어올 때 실행되므로, credentials/tokens를 검증하고 권한이 없는 요청을 즉시 401/403으로 거부하기에 올바른 위치입니다. 이는 backend 부하를 줄이고, 보안 상태를 개선하며, best practices(게이트웨이에서 fail fast)와도 일치합니다. 왜 outbound가 아닌가: B. Outbound policies는 backend가 요청을 처리한 후 APIM이 client에 응답을 반환할 때 실행됩니다. 그 시점에는 backend가 이미 business logic을 실행하고 data에 접근했을 수 있으므로, 인증 강제의 목적에 어긋납니다. Outbound는 response transformations, response headers 추가/제거, response caching directives, 그리고 이와 유사한 post-processing 작업을 위한 것입니다.

다른 모의고사

Practice Test #1

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

Practice Test #3

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

Practice Test #4

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