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

Practice Test #3

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

여러 번의 동일하게 구성된 Azure virtual machines 배포를 수행하기 위해 Azure Resource Manager templates를 사용할 계획입니다. 각 배포의 administrator account에 대한 password는 서로 다른 Azure key vaults에 secret으로 저장되어 있습니다. 각 배포 중 적절한 secret을 포함하는 key vault를 지정할 resource ID를 동적으로 구성하는 방법을 식별해야 합니다. key vault의 이름과 secret의 이름은 inline parameters로 제공됩니다. resource ID를 구성하기 위해 무엇을 사용해야 합니까?

Key Vault access policy는 user, service principal 또는 managed identity가 vault에서 secrets를 읽을 수 있는지 여부를 제어합니다. 이는 authorization에는 필요하지만, ARM deployment에 resource ID를 빌드하거나 전달하는 메커니즘을 제공하지는 않습니다. 올바른 access policy가 있더라도, deployment는 여전히 어떤 vault와 secret을 사용할지 지정할 방법이 필요합니다. 따라서 access policy는 permissions와 관련이 있을 뿐, Key Vault resource ID의 동적 구성이나 지정과는 관련이 없습니다.

Linked template는 배포를 재사용 가능한 modules 또는 별도의 template files로 분할하는 데 사용됩니다. linked template도 parameters를 받아 내부적으로 functions를 사용할 수는 있지만, secure parameter value에 대한 Key Vault secret reference를 제공하는 표준 메커니즘은 아닙니다. 문제는 이름이 parameters로 제공될 때 각 배포 중 적절한 Key Vault를 지정하기 위해 무엇을 사용해야 하는지를 묻고 있으며, 이는 일반적으로 다른 template를 도입하는 것이 아니라 deployment parameters를 통해 처리됩니다. linked template를 사용하면 불필요한 복잡성만 추가되며 요구 사항에 직접적으로 답하지 못합니다.

Parameters file이 정답인 이유는 ARM templates가 일반적으로 Azure Key Vault secret references를 포함한 환경별 값을 제공하기 위해 deployment parameters를 사용하기 때문입니다. secret이 배포마다 서로 다른 vaults에 저장되어 있는 경우, parameters file은 Key Vault resourceId와 secretName을 포함하는 reference object를 포함할 수 있습니다. 이를 통해 동일한 ARM template을 재사용하면서 각 배포 중 적절한 vault를 동적으로 대상으로 지정할 수 있습니다. template 자체는 변경되지 않고, 환경마다 parameter 값만 달라집니다.

Automation Account는 scripts를 실행하거나 deployment workflows를 오케스트레이션할 수 있지만, Key Vault secret references를 전달하기 위한 ARM template 구성 요소는 아닙니다. 요구 사항은 ARM deployments 중 올바른 Key Vault를 지정하는 방법에 관한 것이며, 이는 template parameters와 parameter files를 통해 기본적으로 처리됩니다. Automation이 deployment를 호출할 수는 있지만, secret resolution을 위한 ARM 메커니즘을 대체하지는 않습니다. 따라서 직접적인 해결책의 범위를 벗어납니다.

문제 분석

핵심 개념: 이 문제는 ARM template 배포가 배포마다 vault가 달라질 때 Azure Key Vault에서 secrets를 검색하는 방법에 관한 것입니다. ARM에서 secure parameter reference에 사용되는 Key Vault의 resource ID는 일반적으로 deployment parameters에서 제공되며, parameters file은 vault의 resourceId와 secretName을 포함하는 reference block을 지원합니다. 정답인 이유: vault 이름과 secret 이름이 배포마다 달라지므로, parameters file은 배포 시점에 이러한 값과 Key Vault reference를 template에 전달하는 표준 메커니즘입니다. 주요 특징: Parameters files는 환경별 값을 외부화하고, secure secret references를 지원하며, template logic을 수정하지 않고도 동일한 template을 반복 배포할 수 있게 합니다. 흔한 오해: Linked templates는 배포를 모듈화하는 데 도움이 되지만, Key Vault secret parameterization을 본질적으로 해결하지는 않습니다. access policies는 authorization만 제어합니다. Automation Accounts는 작업을 오케스트레이션하지만 ARM secret references를 정의하지는 않습니다. 시험 팁: 서로 다른 환경별 값이 포함된 ARM template 문제에서는 Key Vault secret references를 포함한 배포별 입력을 제공하는 위치로 parameters files를 떠올리십시오.

2
문제 2

HOTSPOT - 다음 표와 같이 East US 2 region에 두 개의 Azure virtual machine이 있습니다. 이름 Operating system Type Tier VM1 Windows Server 2008 R2 A3 Basic VM2 Ubuntu 16.04-DAILY-LTS L4s Standard Azure Key vault를 배포하고 구성합니다. VM1 및 VM2에서 Azure Disk Encryption을 활성화할 수 있도록 해야 합니다. 각 virtual machine에서 무엇을 수정해야 합니까? 답하려면, 답변 영역에서 적절한 옵션을 선택하세요. 참고: 각 정답 선택에는 1점이 주어집니다. Hot Area:

파트 1:

VM1 ______

Windows용 Azure Disk Encryption은 지원되는 Windows Server 버전이 필요하며, Windows Server 2008 R2는 ADE에서 지원되지 않습니다. 따라서 디스크 암호화를 활성화하기 전에 VM1을 지원되는 운영 체제 버전으로 변경해야 합니다. 여기서 결정적인 문제는 티어가 아니며, VM이 지원되는 OS에서 실행되고 필요한 extension을 사용할 수 있는 한 VM size/type 자체가 차단 요인은 아닙니다.

파트 2:

VM2 ______

Linux의 Azure Disk Encryption은 특정 승인된 배포판과 이미지들을 지원하며, Ubuntu 16.04-DAILY-LTS는 ADE에서 지원되는 프로덕션 이미지가 아닙니다. 암호화를 활성화하려면 VM2를 공식적으로 지원되는 Ubuntu LTS marketplace image와 같은 지원되는 운영 체제 버전/image로 변경해야 합니다. tier는 이미 Standard이므로 문제가 아니며, 이 시나리오에서 L4s VM type은 ADE의 차단 요인이 아닙니다.

3
문제 3

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. Azure 구독이 있습니다. 이 구독에는 Windows Server 2012 R2 또는 Windows Server 2016을 실행하는 50개의 가상 머신이 포함되어 있습니다. 가상 머신에 Microsoft Antimalware를 배포해야 합니다. 해결 방법: 각 가상 머신에 extension을 추가합니다. 이것이 목표를 충족합니까?

예. Azure 가상 머신용 Microsoft Antimalware는 대상 VM에 설치되는 VM extension을 통해 제공됩니다. 각 Windows Server 2012 R2/2016 VM에 Microsoft Antimalware extension을 추가하면 antimalware 에이전트가 배포되고 실시간 보호 및 예약 검사와 같은 구성이 활성화됩니다. 따라서 각 VM에 extension을 설치하는 것은 50개의 가상 머신에 Microsoft Antimalware를 배포한다는 목표를 충족합니다.

아니요. 이는 올바르지 않습니다. Microsoft Antimalware VM extension을 추가하는 것은 Azure IaaS 가상 머신에 antimalware를 배포하는 지원되고 의도된 방법이기 때문입니다. VM extension은 antimalware와 같은 보안 도구를 포함하여 배포 후 VM 내부에 소프트웨어를 설치하고 구성하도록 특별히 설계되었습니다. automation 없이 VM별로 수동 수행하는 것은 운영상 번거로울 수 있지만, 여전히 Microsoft Antimalware를 배포해야 한다는 명시된 요구 사항은 충족합니다.

문제 분석

핵심 개념: 이 문제는 Azure 가상 머신에 Microsoft Antimalware(Microsoft Antimalware extension)를 배포하는 방법과 VM extension을 사용하는 것이 적절한 배포 방법인지 여부를 테스트합니다. 정답인 이유: Azure VM용 Microsoft Antimalware는 각 가상 머신에 Microsoft Antimalware VM extension(또는 IaaS Antimalware extension이라고도 함)을 설치하여 배포됩니다. VM extension은 보안 에이전트를 포함하여 배포 후 VM 내부에 에이전트와 소프트웨어를 설치하고 구성하는 Azure의 기본 메커니즘입니다. 환경이 지원되는 Windows Server 버전(2012 R2/2016)을 실행하는 Azure IaaS VM으로 구성되어 있으므로, 각 VM에 antimalware extension을 추가하면 해당 VM에 Microsoft Antimalware를 배포해야 한다는 요구 사항을 직접 충족합니다. 주요 기능 / 구성: - Azure VM Extensions: 프로비저닝 후 VM에 소프트웨어를 설치/구성하는 데 사용됩니다. - Microsoft Antimalware extension: 실시간 보호, 예약 검사 및 제외 구성 기능을 제공합니다. - 배포 방법: Azure portal, ARM templates, PowerShell, Azure CLI 또는 Azure Policy/automation을 사용하여 대규모로 적용할 수 있습니다. - VM별 설치: 적용 범위를 보장하기 위해 extension은 각 VM에 적용됩니다(수동 또는 automation 사용). 일반적인 오해: - Microsoft Antimalware가 기본적으로 모든 Azure VM에 자동으로 활성화된다고 가정하는 것; 명시적으로 설치/구성하지 않으면 그렇지 않습니다. - Microsoft Antimalware extension을 Microsoft Defender for Cloud 플랜과 혼동하는 것; Defender for Cloud는 권장/지원할 수 있지만, extension은 여전히 VM 수준 배포 메커니즘입니다. - extension 또는 automation을 사용하지 않고 단일 구독 수준 설정으로 모든 VM에 antimalware가 배포된다고 생각하는 것. 시험 팁: - VM extension은 Azure IaaS VM에 에이전트(antimalware, monitoring, DSC 등)를 배포하는 표준 방법입니다. - 요구 사항이 “VM에 배포”라면, Microsoft Antimalware extension이 포함된 답을 예상해야 합니다. - 많은 수의 VM의 경우 automation(Policy/ARM/PowerShell)을 고려할 수 있지만, 핵심 메커니즘은 여전히 extension입니다.

4
문제 4

Azure Container Registry에 연결할 Azure Kubernetes Service (AKS) 클러스터를 구성하고 있습니다. auto-generated service principal을 사용하여 Azure Container Registry에 인증해야 합니다. 무엇을 만들어야 합니까?

Azure AD group은 여러 user 또는 service principal의 권한을 집합적으로 관리하는 데 사용됩니다. AKS service principal을 group에 추가한 다음 해당 group에 role을 할당할 수도 있지만, 문제는 auto-generated service principal이 ACR에 인증/권한 부여할 수 있도록 무엇을 만들어야 하는지를 묻고 있습니다. 직접적이고 필수적인 제어는 group이 아니라 RBAC role assignment입니다.

Azure AD role assignment(Azure RBAC)는 AKS의 auto-generated service principal에 ACR 리소스에 대한 권한을 부여하는 방법입니다. AKS가 container image를 pull할 수 있도록 ACR 범위에서 기본 제공 role인 AcrPull을 할당합니다. 이것이 표준적이고 최소 권한 원칙에 맞는 접근 방식이며, AKS의 “attach ACR” 작업으로 일반적으로 자동화됩니다.

Azure AD user는 사람의 identity이며 AKS 클러스터와 registry 간 인증에는 적절하지 않습니다. AKS는 Azure 리소스에 액세스할 때 user account가 아니라 service principal(application identity) 또는 managed identity를 사용합니다. user를 생성하면 좋지 않은 보안 관행(shared credentials)이 도입되며, 최소 권한 원칙이나 자동화 요구 사항에도 부합하지 않습니다.

Azure Key Vault의 secret은 민감한 값(password, key, certificate)을 저장하는 데 사용됩니다. auto-generated service principal을 사용하여 AKS가 ACR에서 pull하는 경우, 권장되는 접근 방식은 registry 자격 증명을 저장하고 주입하는 것이 아니라 Azure RBAC(AcrPull)입니다. Key Vault를 사용하면 불필요하게 복잡해지고, identity 기반 액세스 대신 정적 자격 증명 사용을 조장할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 AKS가 클러스터의 auto-generated service principal(또는 최신 클러스터에서는 managed identity)을 사용하여 Azure Container Registry (ACR)에 인증하는 방식과, Azure RBAC가 해당 identity에 이미지 pull 권한을 부여하는 방식을 테스트합니다. ACR 액세스는 registry 범위로 지정된 Azure role assignment(예: AcrPull)를 통해 제어됩니다. 정답인 이유: AKS가 service principal과 함께 생성되면, Azure는 Azure AD에 app registration/service principal을 생성합니다(또는 사용자가 제공함). 해당 identity는 ACR에 액세스할 수 있도록 권한이 부여되어야 합니다. 올바른 방법은 service principal에 ACR 리소스에 대한 필요한 권한을 부여하는 Azure AD role assignment를 만드는 것입니다. 일반적으로 AKS 노드가 이미지를 pull할 수 있도록 ACR 범위에서 기본 제공 role인 AcrPull을 할당합니다. 이 RBAC assignment가 없으면 인증은 성공할 수 있어도 권한 부여는 실패합니다(401/403과 같은 image pull 오류). 주요 기능 / 모범 사례: - 최소 권한 원칙 사용: 이미지 pull에는 AcrPull이면 충분하며, AcrPush는 build pipeline에만 필요합니다. - assignment 범위를 subscription 전체가 아니라 특정 registry(또는 resource group)로 좁게 지정합니다. - 이는 Azure Well-Architected Framework의 security pillar와 일치합니다: 최소 권한 및 중앙 집중식 액세스 제어를 적용합니다. - 실제로는 Azure CLI(az role assignment create)를 통해 수행하거나, ACR을 AKS에 연결하는 방식(az aks update --attach-acr)으로 수행할 수 있으며, 이는 사실상 클러스터 identity에 대한 role assignment를 생성합니다. 일반적인 오해: - Azure AD user/group를 생성하는 것은 도움이 되지 않습니다. AKS는 ACR에 액세스할 때 사람의 identity가 아닌 identity(service principal)를 사용하기 때문입니다. - 이 시나리오에서는 auto-generated service principal과 Azure RBAC를 사용하는 것이 목표이므로, Key Vault에 자격 증명을 저장하는 것은 불필요하며 보안 측면에서도 덜 적절합니다. 시험 팁: AKS-to-ACR의 경우 다음과 같이 생각하세요: “identity + RBAC role assignment.” 문제에 service principal/managed identity와 ACR이 언급되면, 기대되는 작업은 거의 항상 registry 범위에서 Azure role assignment를 통해 AcrPull(또는 AcrPush)을 할당하는 것입니다.

5
문제 5

Subscription1이라는 Azure subscription이 있습니다. Subscription1에 VM1이라는 Linux virtual machine을 배포합니다. VM1의 metrics와 logs를 모니터링해야 합니다. 무엇을 사용해야 합니까?

AzurePerformanceDiagnostics는 performance troubleshooting 및 diagnostics(종종 VM 속도 저하 조사, traces 수집, performance issues 분석에 사용됨)를 목적으로 합니다. Linux guest metrics와 logs를 지속적으로 수집하고 라우팅하는 표준 extension은 아닙니다. 시험 시나리오에서 VM metrics와 logs의 모니터링을 구체적으로 묻는 경우, 일반적으로 가장 적합한 선택은 아닙니다.

Azure HDInsight는 managed big data analytics service(Hadoop, Spark, Kafka 등)입니다. 대규모 datasets를 처리하고 분석하는 데 사용되며, VM guest metrics와 logs를 수집하는 용도가 아닙니다. logs를 big data platform으로 수집할 수는 있겠지만, 단일 Linux VM의 metrics와 logs를 모니터링하기 위한 올바르거나 직접적인 Azure service/extension은 아닙니다.

Linux Diagnostic Extension (LAD) 3.0은 Linux virtual machine에서 guest-level diagnostic data를 수집하도록 설계된 Azure VM extension입니다. performance 관련 metrics와 syslog 같은 Linux logs를 캡처할 수 있으므로, VM1의 metrics와 logs를 모두 모니터링해야 한다는 요구 사항에 정확히 부합합니다. extension으로서 guest context 내부에서 실행되기 때문에, platform-level signals만이 아니라 operating system telemetry를 수집하는 데 적합합니다. 제공된 옵션 중 Linux VM diagnostics를 위해 특별히 만들어진 service 또는 extension은 이것뿐입니다.

Azure Analysis Services는 semantic modeling(tabular models) 및 business intelligence workloads를 위한 PaaS analytics service입니다. VM monitoring, metrics collection 또는 log collection 기능을 제공하지 않습니다. 모니터링 시스템에서 생성된 데이터를 소비할 수는 있지만, Linux VM을 모니터링하는 데 사용되지는 않습니다.

문제 분석

핵심 개념: 이 문제는 Azure에서 Linux VM의 platform/guest metrics와 logs를 수집하고 모니터링하는 방법을 묻습니다. IaaS VM의 경우 Azure Monitor가 상위 서비스이며, VM guest telemetry(syslog, performance counters, custom logs)는 일반적으로 agent/extension을 통해 수집됩니다. 역사적으로 Linux의 경우 해당 agent는 Linux Diagnostic Extension (LAD)입니다. 시험 관점에서 “Linux VM의 metrics와 logs를 모니터링”은 직접적으로 LAD에 해당합니다. 정답인 이유: Linux Diagnostic Extension (LAD) 3.0은 Linux VM에서 guest-level diagnostics를 수집하도록 특별히 설계되었습니다. 여기에는 performance metrics(CPU, memory, disk, network counters)와 logs(특히 syslog)가 포함되며, 구성에 따라 이를 storage account 및/또는 Azure Monitor backend로 라우팅할 수 있습니다. 이는 Linux VM diagnostics를 위한 목적 전용 extension이며, 목록의 옵션 중 Linux VM에서 metrics와 logs를 모두 직접 수집하는 요구 사항을 충족하는 유일한 선택지입니다. 주요 기능 / 구성 포인트: - Linux guest에서 performance counters와 syslog를 수집합니다. - 무엇을 수집하고 어디로 보낼지 정의하는 JSON settings file(public/protected settings)을 통해 구성됩니다. - 일반적으로 Azure Monitor/Log Analytics 시나리오와 함께 사용됩니다(최신 지침에서는 Azure Monitor Agent를 자주 사용하지만, 여기서는 선택지에 없습니다). - secrets의 안전한 처리(protected settings)를 지원하며, observability와 alerting을 가능하게 함으로써 Azure Well-Architected Framework의 operational excellence와도 부합합니다. 일반적인 오해: - AzurePerformanceDiagnostics는 일반적인 모니터링과 혼동되는 경우가 많습니다. 이는 주로 troubleshooting/diagnostics toolset이며, Linux metrics + logs 수집을 위한 표준적인 지속 모니터링 파이프라인은 아닙니다. - HDInsight와 Analysis Services는 analytics platform이지, VM telemetry 수집기가 아닙니다. 시험 팁: “Linux VM” + “metrics and logs”가 보이고 선택지에 LAD가 있다면 LAD를 선택하십시오. 만약 Azure Monitor Agent (AMA) 또는 Log Analytics agent가 선택지에 있다면 그것들도 검토해야 하겠지만, 이 선택지들 중에서는 LAD 3.0이 Linux guest diagnostics를 위한 올바른 telemetry 수집 메커니즘입니다.

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

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

6
문제 6

Azure resource group에 100개의 virtual machine이 포함되어 있습니다. 여러 policy definition을 포함하는 Initiative1이라는 initiative가 있습니다. Initiative1은 resource group에 할당되어 있습니다. policy definition과 일치하지 않는 리소스를 식별해야 합니다. 어떻게 해야 합니까?

Defender for Cloud의 Regulatory compliance는 규정 벤치마크 및 보안 control과 같은 compliance standard 및 framework와의 정렬을 보여주기 위한 것입니다. policy 기반 assessment를 표시할 수는 있지만, resource group의 특정 initiative assignment에 대해 어떤 리소스가 non-compliant인지 확인하는 가장 직접적인 도구는 아닙니다. 이 문제는 구체적으로 Azure Policy initiative compliance에 관한 것이므로 Azure Policy Compliance 보기가 더 적절하고 기대되는 답입니다. 이 옵션을 선택하면 standards reporting과 policy assignment evaluation을 혼동하게 됩니다.

Azure Policy 아래의 Compliance 보기는 할당된 initiative에 대해 어떤 리소스가 non-compliant인지 확인하는 올바른 위치입니다. initiative의 평가 결과를 보여주며 assignment를 자세히 확인하여 어떤 virtual machine이 어떤 policy definition에 실패했는지 정확히 볼 수 있습니다. 이는 policy definition과 일치하지 않는 리소스를 식별해야 한다는 요구 사항에 직접적으로 부합합니다. 이것은 resource group 범위에서 Azure Policy compliance 추적을 위한 기본 governance 인터페이스입니다.

Secure Score는 전반적인 보안 상태 측정값을 제공하고 해당 점수를 향상시키는 recommendation의 우선순위를 정합니다. 특정 Azure Policy initiative assignment를 위반하는 리소스 목록을 보여주는 데 초점을 두지 않습니다. 일부 recommendation이 policy 결과와 관련되어 있더라도 Secure Score는 initiative compliance 결과를 검토하기 위한 올바른 인터페이스가 아닙니다. 따라서 문제의 요구 사항을 직접 충족하지 않습니다.

Assignments는 policy와 initiative가 어디에 할당되었는지를 보여주지만, non-compliant 리소스를 식별하는 데 필요한 compliance 결과 자체를 제공하지는 않습니다. 어떤 virtual machine이 policy definition과 일치하지 않는지 찾으려면 assignment의 존재 여부가 아니라 compliance 상태를 검토해야 합니다. 이 옵션은 assignment 관리에 해당하며 평가 결과를 보여주지 않습니다. 따라서 문제의 요구 사항에 대한 답이 아닙니다.

문제 분석

핵심 개념: 이 문제는 일반적인 보안 상태가 아니라 Azure Policy initiative compliance에 관한 것입니다. initiative가 resource group에 할당되면 Azure Policy는 해당 범위의 리소스를 평가하고 각 리소스가 포함된 policy definition을 준수하는지 또는 비준수인지 기록합니다. 어떤 virtual machine이 policy definition과 일치하지 않는지 식별하려면 policy assignment의 compliance 결과를 사용해야 합니다. 정답인 이유: 올바른 작업은 Policy 영역을 열고 Compliance를 검토하는 것입니다. 이 보기는 policy assignment와 initiative의 compliance 상태를 보여주며, 어떤 리소스가 non-compliant인지 포함합니다. initiative assignment를 자세히 확인하여 영향을 받는 리소스와 위반한 특정 policy definition을 볼 수 있습니다. 이것이 initiative compliance를 확인하는 기본 Azure Policy 워크플로입니다. 주요 기능: Azure Policy initiative는 여러 policy definition을 하나의 assignment로 그룹화합니다. Compliance 보기는 평가 결과를 집계하고 선택한 범위에서 compliant, non-compliant, exempt 리소스를 보여줍니다. assignment, resource type, resource group, compliance state로 필터링하여 평가에 실패한 정확한 VM을 찾을 수 있습니다. 일반적인 오해: Defender for Cloud Regulatory compliance는 표준 중심이며 control을 compliance framework에 매핑하지만, 특정 initiative assignment에 대한 resource-level non-compliance를 검사하는 기본 위치는 아닙니다. Secure Score는 보안 상태를 측정하고 개선 우선순위를 정하지만, 자세한 initiative compliance를 위한 것은 아닙니다. 또 다른 일반적인 함정은 Azure AD policy 환경과 Azure Resource Manager policy governance를 혼동하는 것입니다. 시험 팁: 문제에서 initiative, policy definition, assignment scope, non-compliant resource 식별이 언급되면 먼저 Azure Policy Compliance를 떠올리십시오. 더 광범위한 보안 및 규정 준수 상태에는 Defender for Cloud를 사용하지만, 직접적인 initiative-assignment 평가에는 Azure Policy compliance 결과를 사용하십시오. 시험에서는 governance 도구와 상태 dashboard를 구분해야 합니다.

7
문제 7

HOTSPOT - 다음 그림에 표시된 alert를 포함하는 Azure subscription이 있습니다.

그래픽에 제시된 정보를 기반으로 각 문장을 완성하는 정답을 선택하려면 드롭다운 메뉴를 사용하세요. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:

파트 1:

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

question-image

정답: A (통과). 보기에서 허용되는 state 전환을 결정하는 데 필요한 관련 세부 정보를 확인할 수 있습니다. Alerts 목록에는 Alert state 값(New, Acknowledged, Closed)이 표시되고, toolbar에는 “Change state” 작업이 포함되어 있습니다. 이는 특정 alert 인스턴스의 state를 변경할 수 있는지, 그리고 어떤 값으로 변경할 수 있는지에 대한 하위 질문에 답하기에 충분한 정보입니다. 이는 표준 Azure Monitor alerts 관리 시나리오이며(classic alerts와 새 alerts를 혼동하게 만드는 문제가 아님), grid에 여러 state가 존재하고 명시적인 “Change state” 컨트롤이 있다는 점은 portal이 선택한 alerts의 alert state 수정을 지원함을 나타냅니다. 따라서 실패를 선택하기보다 답변을 진행하는 것이 타당합니다. B가 아닌 이유: Fail을 선택한다는 것은 정답을 판단할 수 없다는 의미이지만, screenshot은 질문에 필요한 핵심 필드(Alert state 및 Fired time)를 제공합니다.

파트 2:

11:23:52에 발생한 Alert1의 상태는 ______

11:23:52에 발생한 Alert1 인스턴스는 현재 Acknowledged 상태입니다. Azure Monitor에서 alert processing state는 workflow state이며, acknowledged된 alert는 다시 New로 되돌리거나(처리를 재개/초기화하기 위해) 앞으로 Closed로 변경할 수 있습니다. 따라서 정답은 New 또는 Closed로 변경할 수 있다는 것입니다. 다른 선택지는 alert 상태를 편집할 수 있고, Acknowledged는 다음 상태가 하나로만 제한되지 않기 때문에 올바르지 않습니다.

파트 3:

11:23:24에 발생한 Alert2의 상태는 ______

11:23:24에 발생한 Alert2 인스턴스는 현재 Closed 상태입니다. Azure Monitor에서 closed alert는 terminal 상태가 아니며, New로 변경하여 다시 열거나 누군가가 다시 담당하는 경우 Acknowledged로 변경할 수 있습니다. 따라서 정답은 New 또는 Acknowledged입니다. 다른 선택지는 너무 제한적입니다. Closed alert는 portal에서 workflow state를 계속 업데이트할 수 있기 때문입니다.

8
문제 8

다음 표에 표시된 Azure virtual machines가 있습니다.

어떤 virtual machines에 대해 Update Management를 활성화할 수 있습니까?

파트 1:

VM1이 실행 중입니다.

예. VM1은 표에 표시된 대로 지원되는 범용 OS(Windows 또는 지원되는 Linux distribution)를 실행하고 있으므로 Update Management를 사용하도록 설정할 수 있습니다. Update Management를 사용하도록 설정하는 것은 주로 온보딩/구성 단계입니다. 즉, VM이 Automation account 및 Log Analytics workspace에 연결되고 필요한 agent/extension이 설치/구성됩니다. VM1이 실행 중이므로 agent 설치를 즉시 완료하고 update compliance 보고를 시작할 수도 있습니다. 대안인 (아니요)는 VM1이 지원되지 않는 OS/image 유형(예: network appliance 또는 필요한 agent/extension을 실행할 수 없는 image)이거나, 시나리오에서 필요한 Azure endpoint에 대한 outbound connectivity가 차단되었다고 명시적으로 언급한 경우에만 정답이 됩니다. 여기서는 VM1에 대해 어느 조건도 적용되지 않습니다.

파트 2:

VM2가 실행 중입니다.

아니요. VM2는 VM2에 대해 표에 표시된 OS/image 유형이 Azure Update Management (classic)에서 지원되지 않기 때문에 Update Management를 활성화할 수 없습니다. Update Management는 Microsoft Monitoring Agent/Log Analytics agent를 실행할 수 있는 지원되는 Windows/Linux OS(또는 솔루션에서 사용하는 필수 VM extension 경로)를 필요로 하며, Azure Automation/Log Analytics와 통신할 수 있어야 합니다. VM2가 특수한 appliance/잠금된 marketplace image인 경우(이러한 문제에서 흔함), 평가 및 patch orchestration에 필요한 agent/extension 모델을 지원하지 않습니다. VM2가 실행 중이더라도 전원 상태가 OS 지원 요구 사항을 무시하지는 않습니다. 따라서 플랫폼은 지원되지 않는 OS를 Update Management에 온보딩할 수 없으므로 “예”는 올바르지 않습니다.

파트 3:

VM3는 중지되었습니다.

예. VM3는 중지된 상태이더라도 Update Management를 사용하도록 설정할 수 있습니다. 이것은 자주 출제되는 시험의 미묘한 포인트입니다: Update Management를 활성화/온보딩하는 것은 control-plane 구성으로, 현재 실행 중인지 여부와 관계없이 Azure VM에 적용할 수 있습니다. 중지된 동안 할 수 없는 것은 실시간 평가 완료, agent/extension 설치(아직 없는 경우), 또는 update deployment 실행입니다. 이러한 작업은 VM의 전원이 켜져 있고 Azure endpoints와 outbound 통신이 가능해야 합니다. 표에 있는 VM3의 OS가 지원되는 Windows/Linux OS라면, 사용 설정에 대한 정답은 예입니다. “아니요”가 정답이 되는 경우는 OS가 지원되지 않거나, 질문이 중지된 상태에서 updates를 배포할 수 있는지를 물었을 때뿐입니다.

파트 4:

VM4가 실행 중입니다.

예. VM4는 표에 따라 지원되는 OS를 실행하고 있으므로 Update Management를 활성화할 수 있습니다. VM이 실행 중인 상태에서는 onboarding이 필요한 agent/extension을 설치/구성하고 update compliance 데이터를 즉시 수집하기 시작할 수 있습니다. Update Management는 지속적인 patch governance 및 reporting을 위해 설계되었으며, 이는 Secure Compute pillar를 지원합니다: OS patch 수준 유지, vulnerability exposure 감소, auditability 제공. “아니요” 옵션은 VM4가 지원되지 않는 OS/appliance image인 경우이거나 prerequisites가 명시적으로 누락된 경우에만 적용됩니다(예: Azure Automation/Log Analytics endpoints에 대한 connectivity 없음, 또는 extension 설치를 방지하는 policy restrictions). 표에서 지원되는 VM OS임을 나타내고 있으므로, Update Management를 활성화하는 것은 유효합니다.

9
문제 9

HOTSPOT - 다음 표에 표시된 리소스를 포함하는 Azure subscription이 있습니다.

diagram

다음 표에 표시된 Azure Storage account를 생성합니다.

SQL1에 대한 auditing을 구성해야 합니다. audit log 대상지로 사용할 수 있는 Storage account와 Log Analytics workspace는 무엇입니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하세요. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:

파트 1:

이름: Storage1, Region: East US, Resource group: RG1, Storage account type: Blob, Access tier (default): Cool

Storage1은 사용할 수 없습니다. Storage1은 올바른 Region(East US)에 있지만, Storage account type이 “Blob”으로 표시되어 있습니다. Azure에서 BlobStorage account(레거시 “Blob” type)는 Azure SQL Database auditing에 대해 지원되는 대상 type이 아닙니다. SQL auditing에는 standard performance의 General-purpose v1 (Storage) 또는 General-purpose v2 (StorageV2)와 같은 지원되는 Azure Storage account type이 필요합니다. Access tier(Cool)는 여기서 결정 요인이 아닙니다. tiering은 blob data lifecycle/cost에 적용되며 그 자체로 auditing을 차단하지는 않습니다. 핵심 문제는 account kind/type입니다. 따라서 올바른 Region과 Resource group이 있더라도 Storage1은 audit log 대상지로 적합하지 않습니다.

파트 2:

이름: Storage2, 지역: East US, Resource group: RG2, Storage account 유형: General purpose V1, Access tier (기본값): 해당 없음

Storage2는 사용할 수 있습니다. Storage2는 East US에 있으며, 이는 SQL1의 지역(East US)과 일치합니다. Azure SQL Database auditing에서 Storage로 감사 로그를 보내려면 지역이 일치해야 합니다. 또한 Storage2는 General purpose v1 account이며, 이는 SQL auditing에서 지원되는 storage account 유형입니다. Storage2가 다른 resource group(RG2)에 있다는 사실은 auditing 대상지로 사용하는 것을 막지 않습니다. Auditing 구성은 resource group의 동일 위치 여부가 아니라 권한 및 지원되는 대상지 특성(지역/유형)을 기반으로 합니다. 또한 “Access tier (기본값): 해당 없음”은 GPv1 account에서 예상되는 사항이며 auditing 적격성에 영향을 주지 않습니다. 따라서 Storage2는 유효한 audit log 대상지입니다.

파트 3:

이름: Storage3, Region: West Europe, Resource group: RG1, Storage account type: General purpose V2, Access tier (default): Hot

Storage3는 사용할 수 없습니다. Storage3는 General purpose v2 account(지원되는 유형)이지만, West Europe에 있습니다. SQL1은 East US에 있습니다. Azure SQL Database auditing에서 Storage account를 사용하려면, 해당 Storage account는 감사 대상 SQL 리소스와 동일한 region에 있어야 합니다. Storage3가 SQL1과 동일한 Resource group(RG1)에 있더라도, Resource group 일치는 regional requirement를 대체하지 않습니다. SQL auditing에서는 cross-region storage 대상이 지원되지 않으며, 이를 구성하려고 하면 실패하거나 차단됩니다. Access tier(Hot)는 문제가 아닙니다. 문제는 region 불일치입니다. 따라서 Storage3는 적합하지 않습니다.

파트 4:

감사 로그 대상지로 사용할 수 있는 Storage account: ______

감사 로그 대상지로는 Storage2만 사용할 수 있습니다. 각 storage account를 두 가지 주요 요구 사항인 지원되는 storage account 유형과 동일한 region 배치 기준으로 평가합니다. - Storage1 (East US)은 account 유형이 “Blob”(BlobStorage)이므로 실패합니다. 이 유형은 Azure SQL auditing 대상지로 지원되지 않습니다. - Storage2 (East US)는 통과합니다. General purpose v1(지원됨)이며 SQL1과 동일한 region에 있습니다. - Storage3는 GPv2이지만 region이 일치하지 않으므로 실패합니다(West Europe vs East US). 따라서 정답은 “Storage2만”입니다.

파트 5:

감사 로그 대상지로 사용할 수 있는 Log Analytics workspace: ______

Analytics1만 사용할 수 있습니다. Analytics1은 이 auditing 구성 시나리오에서 SQL1과 일치하는 Log Analytics workspace입니다. Analytics3는 West Europe에 있으므로 SQL1의 East US 지역과 일치하지 않습니다. Analytics2는 이 문제에서 유효한 대상지로 선택되지 않았으므로, 정답은 Analytics1만입니다.

10
문제 10

다음 표에 표시된 Azure virtual machines가 있습니다.

diagram

각 virtual machine에는 단일 network interface가 있습니다. VM1의 network interface를 ASG1이라는 application security group에 추가합니다. ASG1에 추가할 수 있는 virtual machines의 network interfaces를 식별해야 합니다. 무엇을 식별해야 합니까?

이 옵션은 VM2만 포함하지만, 다른 유효한 후보를 누락합니다. VM3도 West US 2에 있으므로 다른 subnet에 있더라도 추가할 수 있습니다. VM5도 West US 2에 있으므로 다른 virtual network에 있더라도 추가할 수 있습니다. A는 유효한 NIC를 누락하므로 오답입니다.

이 옵션은 VM2와 VM3를 올바르게 포함하지만, VM5를 잘못 제외합니다. 이 오답 선택지는 ASG가 단일 VNet으로 제한된다는 흔하지만 잘못된 가정을 반영합니다. 실제로 ASG 멤버십은 virtual network가 아니라 region에 의해 제한됩니다. VM5도 West US 2에 있으므로 해당 NIC를 ASG1에 추가할 수 있습니다.

이 옵션은 VM4를 잘못 포함합니다. VM4는 East US에 있는 반면, ASG1은 해당 region의 VM1 NIC를 포함하고 있으므로 West US 2에 있습니다. Application Security Groups는 서로 다른 regions의 NIC를 포함할 수 없습니다. VM2, VM3, VM5는 유효하지만, VM4가 포함되어 있으므로 이 선택지 전체는 오답입니다.

VM2, VM3, VM5는 모두 West US 2에 있으며, 이는 VM1의 NIC가 이미 멤버이므로 ASG1의 region과 일치합니다. Application Security Groups는 regional resource이므로 동일한 region의 NIC는 서로 다른 subnets 또는 서로 다른 virtual networks에 속해 있더라도 추가할 수 있습니다. VM2와 VM3는 VNET1에 있고 VM5는 VNET5에 있지만, 이러한 VNet 차이는 ASG 멤버십을 막지 않습니다. 따라서 D는 동일한 region에 있는 모든 적격 VM을 포함하고 다른 region에 있는 VM은 제외하므로 정답입니다.

문제 분석

핵심 개념: 이 문제는 Azure Application Security Groups (ASGs)의 범위 및 멤버십 규칙을 테스트합니다. ASG는 트래픽 필터링을 단순화하기 위해 Network Security Group (NSG) 규칙에서 참조하는 virtual machine network interfaces의 논리적 그룹입니다. 정답인 이유: ASG1에는 이미 West US 2에 있는 VM1의 NIC가 포함되어 있습니다. Application Security Groups는 regional resource이므로 동일한 region의 NIC만 추가할 수 있지만, 동일한 virtual network 또는 subnet에 있을 필요는 없습니다. 즉, VM2, VM3, VM5는 모두 West US 2에 있으므로 추가할 수 있지만, VM4는 East US에 있으므로 추가할 수 없습니다. 주요 특징: ASG는 IP addresses가 아니라 NIC 멤버십을 기준으로 source 및 destination groups를 정의하기 위해 NSG 규칙과 함께 사용됩니다. ASG는 subnet 또는 VNet에 직접 연결되는 것이 아니라 NIC와 연결됩니다. 중요한 범위 경계는 region이며, 이는 시험에서 자주 나오는 포인트입니다. 일반적인 오해: 자주 하는 실수는 ASG 범위를 VNet 범위와 혼동하여 모든 NIC가 동일한 virtual network에 속해야 한다고 가정하는 것입니다. 또 다른 오해는 ASG가 subnet별이라는 것인데, 이것도 틀렸습니다. 실제 제한 사항은 NIC와 ASG가 동일한 region에 있어야 한다는 것입니다. 시험 팁: AZ-500에서는 NSGs, ASGs, subnets, VNets의 차이를 기억하세요. 어떤 NIC가 ASG에 참여할 수 있는지 묻는 문제라면, 다른 요소를 확인하기 전에 먼저 region을 확인하세요. 같은 Azure region에 있다면 다른 subnet 또는 VNet에 있다는 이유만으로 VM을 제외하지 마세요.

다른 모의고사

Practice Test #1

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

Practice Test #2

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

Practice Test #4

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

Practice Test #5

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

지금 학습 시작하기

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

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