Practice Test #1
50개 문제와 100분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
3중 AI 검증 답안 및 해설
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
기출 문제
webapp1이라는 Azure web app이 있습니다. Azure Repo를 사용하여 webapp1에 대한 continuous deployment를 구성해야 합니다. 가장 먼저 무엇을 만들어야 합니까?
Azure Application Insights는 web app에 대한 application performance monitoring(APM), logging 및 telemetry를 제공합니다. 관찰 가능성을 위한 모범 사례이며 App Service와 통합할 수 있지만, Azure Repos에서 continuous deployment를 구성하는 데 필수는 아닙니다. 모니터링 리소스 없이도 CI/CD를 활성화할 수 있으므로, 가장 먼저 만들어야 하는 것은 아닙니다.
Azure DevOps organization은 Azure DevOps Services의 선행 조건이 되는 컨테이너입니다. Azure Repos는 Azure DevOps project 내부에 존재하며, project 자체도 organization이 있어야 생성할 수 있습니다. Azure Repo에서 Azure Web App으로 continuous deployment를 구성하려면, 먼저 Azure DevOps organization이 있어야 project/repo를 만들고 이후 pipeline 또는 Deployment Center 통합을 Azure service connection과 함께 구성할 수 있습니다.
Azure Storage account는 build artifacts, diagnostics logs, deployment packages 또는 application data에 사용될 수 있지만, Azure Repos에서 App Service web app으로 continuous deployment를 설정하기 위한 선행 조건은 아닙니다. Azure DevOps는 자체 artifact storage에 artifacts를 저장할 수 있으며, App Service 배포는 기본적으로 고객 관리 Storage account를 요구하지 않습니다.
Azure DevTest Labs는 dev/test 환경(주로 VM 기반)을 생성하고 관리하며, 비용을 제어하고 auto-shutdown 같은 정책을 적용하도록 설계되었습니다. Azure Repos를 호스팅하거나 App Service continuous deployment를 구성하는 데 사용되지 않습니다. Azure Repos를 사용하여 Azure Web App에 CI/CD를 수행하는 경우, DevTest Labs는 관련이 없으며 필요하지 않습니다.
문제 분석
핵심 개념: 이 문제는 Azure Repos를 사용하여 Azure App Service Web App에 대한 continuous deployment(CI/CD)를 구성하는 내용을 테스트합니다. Azure Repos는 Azure DevOps Services의 일부이므로, 기본적인 선행 조건은 프로젝트와 repo를 호스팅할 수 있는 Azure DevOps organization을 보유하는 것입니다. 정답인 이유: Azure Repo에서 Azure Web App으로 continuous deployment를 설정하려면, Web App의 Deployment Center를 연결하거나 pipeline을 설정하여 Azure DevOps project에 있는 repository와 연결해야 합니다. Azure Repo를 만들기 전에 먼저 Azure DevOps organization(Azure DevOps의 최상위 컨테이너)을 만들어야 합니다. organization이 생성된 후 project를 만들고, 그다음 Azure Repo를 만들고, 이후 pipeline(classic release 또는 YAML)을 구성하거나 Deployment Center 통합을 사용하여 webapp1에 배포합니다. 주요 기능 및 모범 사례: 실무에서는 일반적으로 다음과 같이 진행합니다: 1) Azure DevOps organization과 project를 생성합니다. 2) Azure Repo를 생성하거나 가져옵니다. 3) 최소 권한 원칙에 따라 Azure에 대한 service connection(보통 service principal 사용)을 생성합니다(예: resource group 또는 특정 web app 범위로 제한). 4) Azure Key Vault 또는 pipeline secret variables에 안전하게 저장된 secret을 사용하여 build 및 release(YAML pipeline)를 구성합니다. Azure Well-Architected 관점에서 CI/CD는 반복 가능하고 감사 가능한 배포를 가능하게 하고 configuration drift를 줄여 operational excellence와 reliability를 향상시킵니다. AZ-500 관점에서는 governance와 access control도 고려해야 합니다. RBAC를 사용하고, service connection을 생성할 수 있는 사용자를 제한하며, approvals와 branch policies를 활성화해야 합니다. 일반적인 오해: Application Insights는 모니터링용이며 배포의 선행 조건이 아닙니다. Storage account는 일부 패턴에서 artifacts, logs 또는 app content에 사용되지만, Azure Repos 기반 배포를 활성화하는 데 필수는 아닙니다. DevTest Labs는 lab 환경 및 VM 기반 dev/test 시나리오를 관리하기 위한 것이며, App Service CI/CD용이 아닙니다. 시험 팁: 배포 문맥에서 “Azure Repo”를 보면 즉시 “Azure DevOps Services”와 연결해서 생각해야 합니다. 가장 먼저 필요한 것은 Azure DevOps organization입니다(그다음 project/repo/pipeline). 또한 보안 시험 관점도 기억하세요. service connection, 최소 권한, 그리고 pipeline secret 보호는 자주 출제됩니다.
다음 표에 표시된 virtual network를 포함하는 Azure subscription이 있습니다. Name Region Subnet VNET1 West US Subnet11 및 Subnet12 VNET2 West US 2 Subnet21 VNET3 East US Subnet31 이 subscription에는 다음 표에 표시된 virtual machine이 포함되어 있습니다.
NIC1에서 ASG1이라는 application security group을 구성합니다. ASG1을 구성할 수 있는 다른 network interface는 무엇입니까?
오답입니다. NIC2는 ASG1과 동일한 VNet(VNET1)에 있으므로 대상이 될 수 있지만, 유일한 대상은 아닙니다. NIC3도 VNET1 (Subnet12)에 있습니다. ASG 멤버십은 동일한 subnet으로 제한되지 않으며, 동일한 VNet 내의 서로 다른 subnet에 있는 NIC를 포함할 수 있습니다.
오답입니다. NIC4 (VNET2, West US 2)와 NIC5 (VNET3, East US)는 서로 다른 VNet/region에 있습니다. ASG는 VNet 범위로 제한되므로, VNet이 peered되어 있거나 동일한 subscription에 있더라도 다른 VNet의 NIC를 ASG1에 추가할 수 없습니다.
정답입니다. NIC2 (Subnet11)와 NIC3 (Subnet12)는 모두 ASG1이 구성된 동일한 VNet인 VNET1에 있습니다 (NIC1을 통해). ASG는 동일한 VNet 내의 모든 subnet에 있는 NIC를 포함할 수 있으므로, NSG 규칙이 subnet 전반의 애플리케이션 역할을 대상으로 지정할 수 있습니다.
오답입니다. NIC2와 NIC3는 유효하지만(동일한 VNet), NIC4는 아닙니다. NIC4는 VNET2 (West US 2)의 Subnet21에 연결되어 있습니다. ASG1은 subscription 멤버십이나 VNet 간 연결성과 관계없이 다른 VNet의 NIC를 포함할 수 없습니다.
문제 분석
핵심 개념: 이 문제는 Azure의 Application Security Group (ASG)을 테스트합니다. ASG는 Network Security Group (NSG)과 함께 사용되어 virtual machine network interface (NIC)를 애플리케이션 역할별로 그룹화한 다음, 해당 그룹을 NSG 보안 규칙에서 참조할 수 있게 합니다. ASG는 IP 주소를 사용하는 것보다 규칙 관리를 단순화합니다. 정답인 이유: ASG는 virtual network (VNet) 및 region 범위로 제한됩니다. 실제로는 NIC가 ASG와 동일한 VNet에 있는 경우에만 해당 NIC를 ASG에 추가할 수 있습니다. 이 시나리오에서 ASG1은 Subnet11 in VNET1 (West US)에 연결된 NIC1에 구성됩니다. 따라서 ASG1은 VNET1에 속합니다. ASG1에 추가할 수 있는 다른 NIC는 VNET1 내 subnet에 연결된 NIC뿐입니다. NIC2는 Subnet11 (VNET1)에 있고 NIC3는 Subnet12 (VNET1)에 있으므로 둘 다 ASG1을 사용하도록 구성할 수 있습니다. NIC4는 VNET2 (West US 2)에 있고 NIC5는 VNET3 (East US)에 있으므로 ASG1에 추가할 수 없습니다. 주요 기능 / 모범 사례: - ASG는 NSG 규칙에서 source/destination으로 사용되므로, IP를 추적하지 않고도 “allow web-to-app” 스타일 규칙을 사용할 수 있습니다. - 설계는 Azure Well-Architected Framework (Security + Operational Excellence)에 부합합니다: 규칙 복잡성과 구성 드리프트를 줄입니다. - ASG는 subnet에 직접 적용되는 것이 아니라 NIC에 적용되며, 일관된 역할 기반 그룹화와 함께 사용할 때 가장 효과적입니다. 일반적인 오해: 자주 나오는 함정은 ASG가 동일한 subscription의 여러 VNet에 걸칠 수 있거나 peered VNet/region 간에 사용할 수 있다고 가정하는 것입니다. VNet이 peered되어 있고 트래픽이 흐를 수 있더라도, ASG 멤버십은 여전히 ASG가 존재하는 VNet으로 제한됩니다. 시험 팁: AZ-500에서는 범위 규칙을 기억하세요: NSG는 subnet/NIC에 연결할 수 있지만, ASG 멤버십은 ASG와 동일한 VNet(및 region) 내 NIC로 제한됩니다. 여러 VNet/region이 보이면, ASG의 VNet 외부에 있는 NIC는 즉시 제외하세요.
Sub1이라는 Azure subscription이 있습니다. Sub1에는 Subnet1이라는 하나의 subnet을 포함하는 VNet1이라는 virtual network가 있습니다. Subnet1에는 Ubuntu Server 18.04를 실행하는 VM1이라는 Azure virtual machine이 있습니다. Subnet1에서 Microsoft.Storage에 대한 service endpoint를 만듭니다. Docker containers를 VM1에 배포할 때, containers가 service endpoint를 사용하여 Azure Storage 리소스에 액세스할 수 있도록 해야 합니다. container를 배포하기 전에 VM1에서 무엇을 해야 합니까?
application security group과 network security group을 만드는 것은 container가 service endpoint를 사용하게 만들지 않습니다. ASG와 NSG는 트래픽 필터링 및 그룹화 메커니즘인 반면, service endpoints는 source subnet ID에 연결된 subnet-to-PaaS connectivity 기능입니다. NSG rules가 Azure Storage로의 트래픽을 허용하더라도, VM에서 Docker container 트래픽이 시작되거나 라우팅되는 방식을 변경하지는 않습니다. 따라서 이러한 리소스는 container가 service endpoint를 사용하여 Storage에 액세스하도록 보장해야 한다는 요구 사항을 해결하지 못합니다.
docker-compose.yml 파일을 편집하는 것이 올바른 작업인 이유는 배포 전에 container가 host network mode를 사용하도록 구성할 수 있기 때문입니다. host networking을 사용하면 container가 VM1의 network namespace를 공유하므로, Azure Storage로 향하는 outbound 트래픽이 Microsoft.Storage service endpoint가 활성화된 Subnet1의 VM NIC를 통해 전송됩니다. 즉, Azure는 해당 트래픽을 service endpoint가 있는 subnet에서 시작된 것으로 인식하며, 이것이 service endpoints 기반 storage account network rules의 요구 사항입니다. 이 시나리오에서 container를 배포하기 전에 필요한 실질적인 Docker 수준 변경 사항입니다.
container network interface plug-in을 설치하는 것은 이 시험 시나리오에서 Ubuntu VM에서 직접 실행되는 표준 Docker containers에 필요한 단계가 아닙니다. CNI는 일반적으로 container orchestrator 및 고급 networking 통합과 관련이 있지만, Docker 자체는 보통 자체 networking 모델을 사용하며 host networking과 같은 compose 설정을 통해 구성할 수 있습니다. 문제는 container가 subnet의 service endpoint를 사용할 수 있도록 배포 전에 VM1에서 무엇을 해야 하는지를 묻고 있으며, 관련 작업은 CNI plug-in을 추가하는 것이 아니라 container의 network mode를 구성하는 것입니다. 따라서 이 선택지는 제시된 요구 사항에 대한 최선의 답이 아닙니다.
문제 분석
핵심 개념: Azure service endpoints는 virtual network의 subnet에서 시작되는 트래픽에 적용됩니다. Linux VM의 Docker container는 Azure가 VM의 NIC in Subnet1에서 오는 것으로 인식하는 방식으로 outbound 트래픽이 VM의 network stack을 사용할 때만 해당 subnet 수준 ID의 이점을 얻습니다. 정답인 이유: container가 host network를 사용하도록 구성하면 container의 트래픽이 VM1의 network interface를 통해 나가게 되어, Subnet1에서 활성화된 Microsoft.Storage service endpoint를 통해 Azure Storage에 액세스할 수 있습니다. 핵심 기능: service endpoints는 subnets에 구성되고, Docker bridge networking은 NAT와 내부 container network를 사용하며, host networking은 container가 VM의 network namespace를 공유하게 합니다. 흔한 오해: NSG와 ASG는 service endpoints를 작동하게 하지 않으며, CNI 설치는 일반적인 Docker-on-VM 배포보다는 Kubernetes와 같은 orchestrator와 관련이 있습니다. 시험 팁: VM의 containers가 subnet 기반 Azure networking 기능을 어떻게 사용할 수 있는지 묻는 문제에서는, Azure control-plane objects를 추가하는 것보다 container 트래픽이 host network를 사용하게 만드는 것을 떠올리십시오.
RG1이라는 resource group에 15개의 Azure virtual machine이 있습니다. 모든 virtual machine은 동일한 애플리케이션을 실행합니다. virtual machine에서 권한이 없는 애플리케이션과 malware가 실행되지 않도록 해야 합니다. 무엇을 해야 합니까?
Azure Policy는 Azure resource 속성(예: 허용된 SKU, 필수 tag, public IP 거부, extension 배포)을 평가하고 적용하는 governance 도구입니다. guest OS 내부에서 어떤 executable/process가 실행될 수 있는지를 직접 제어하지는 않습니다. Policy를 사용해 security agent나 구성을 배포할 수는 있지만, 보기의 내용만으로는 VM에서 권한이 없는 애플리케이션과 malware 실행을 방지한다는 요구 사항을 충족하지 못합니다.
Microsoft Defender for Cloud의 Adaptive application controls는 allowlist를 생성하고 적용하여(일반적으로 Windows에서는 AppLocker를 통해) VM에서의 애플리케이션 실행을 제어하도록 설계되었습니다. 유사한 머신 그룹의 정상적인 애플리케이션 동작을 학습하고, 알 수 없거나 권한이 없는 애플리케이션을 차단하기 위한 규칙을 권장하므로 malware 및 승인되지 않은 소프트웨어의 실행을 방지하는 데 도움이 됩니다. 이는 요구 사항과 정확히 일치합니다.
Azure AD Identity Protection은 유출된 자격 증명, 비정상적인 이동, risky sign-in과 같은 identity 기반 위험을 탐지하고 수정하는 데 중점을 둡니다. 사용자 인증과 액세스 결정(Conditional Access)을 보호하는 데 도움이 되지만, virtual machine에서 application allowlisting 또는 guest 내부 실행 방지를 제공하지는 않습니다. 따라서 VM에서 권한이 없는 애플리케이션/malware의 실행을 막는 요구 사항을 해결하지 못합니다.
Resource lock(ReadOnly 또는 CanNotDelete)은 VM 삭제나 resource group 수정과 같은 Azure resource에 대한 management-plane 변경이 실수로 또는 무단으로 수행되는 것을 방지합니다. 하지만 VM operating system 내부에서 무엇이 실행되는지에는 영향을 주지 않으며, malware나 권한이 없는 애플리케이션의 실행을 차단할 수 없습니다. 이는 리소스를 삭제로부터 보호하는 데는 유용하지만, workload 실행 제어를 위한 것은 아닙니다.
문제 분석
핵심 개념: 이 문제는 Microsoft Defender for Cloud(이전의 Azure Security Center)를 사용한 Azure VM의 workload protection을 테스트합니다. 구체적으로는 권한이 없는 소프트웨어와 malware의 실행을 막기 위한 application allowlisting을 다룹니다. 정답인 이유: Defender for Cloud의 Adaptive application controls는 유사한 VM 집합(RG1의 동일한 15개 VM과 같은)에서 알려진 정상 프로세스 및 애플리케이션 동작을 학습하고 allow 규칙(Windows VM의 경우 Windows AppLocker 기반)을 권장합니다. 이를 적용하면 승인된 애플리케이션만 실행할 수 있으므로 공격 표면이 크게 줄어들고 많은 malware 및 “living off the land” 방식의 실행을 차단할 수 있습니다. 이는 권한이 없는 애플리케이션과 malware가 실행되지 않도록 해야 한다는 요구 사항을 직접적으로 충족합니다. 주요 기능 / 동작 방식: - machine learning과 관찰된 telemetry를 사용하여 VM 그룹/workload별 allowlist 기준선을 구축합니다. - 권장 규칙을 생성하고 이를 적용하도록 구성할 수 있습니다(일반적으로 Windows에서는 AppLocker policy를 통해 적용). - Defender for Cloud 권장 사항 및 security posture management에 통합됩니다. - Azure Well-Architected Framework(Security pillar)와 부합합니다: 공격 표면 축소, 실행에 대한 least privilege 구현, posture의 지속적 개선. 흔한 오해: - Azure Policy는 구성 및 governance를 적용할 수 있지만(예: extension 요구, Defender plan 적용, public IP 거부), guest OS 내부에서 임의의 executable이 실행되는 것을 기본적으로 방지하지는 않습니다. - Azure AD Identity Protection은 risky sign-in 및 사용자 identity risk를 다루며, VM에서의 애플리케이션 실행 제어를 위한 것이 아닙니다. - Resource lock은 Azure resource management 작업(delete/modify)을 보호하지만, guest 내부의 malware 실행에는 아무런 영향을 주지 않습니다. 시험 팁: AZ-500에서 VM에서 “권한이 없는 애플리케이션이 실행되지 않도록 방지”라는 표현을 보면 allowlisting 기술을 떠올리세요: Defender for Cloud Adaptive Application Controls(또는 AppLocker/WDAC 개념). “resource configuration을 관리”는 Azure Policy, “삭제로부터 보호”는 lock, “risky sign-in”은 Identity Protection을 떠올리면 됩니다. 참고: Adaptive application controls를 사용하려면 Defender for Cloud 및 서버에 대한 적절한 plan/coverage가 필요합니다. 적용은 일반적으로 Windows에서 AppLocker를 통해 이루어지며, 문제에 설명된 동일한 VM과 같은 표준화된 workload에 가장 적합합니다.
Contoso.com이라는 Azure Active Directory (Azure AD) tenant와 AKS1이라는 Azure Kubernetes Service (AKS) cluster가 있습니다. AKS1에 Contoso.com의 계정을 사용하여 액세스할 수 없다는 것을 발견했습니다. Contoso.com의 계정을 사용하여 AKS1에 액세스할 수 있도록 해야 합니다. 솔루션은 관리 작업을 최소화해야 합니다. 가장 먼저 무엇을 해야 합니까?
AKS1을 다시 만드는 것은 과도한 조치이며, tenant 수준의 필수 조건이 실제 원인일 수 있는 상황에서 첫 번째 단계가 되어서는 안 됩니다. 문제에서는 관리 작업을 최소화하는 조치를 명시적으로 묻고 있으며, cluster를 다시 빌드하면 불필요한 운영 오버헤드, 마이그레이션 작업 및 잠재적 다운타임이 발생합니다. 이 시나리오에서는 cluster 재생성을 고려하기 전에 Azure AD 구성을 먼저 확인해야 합니다. 따라서 cluster를 다시 만드는 것은 가장 적절한 첫 번째 조치가 아닙니다.
Kubernetes 버전 업그레이드는 AKS control plane 및 node 소프트웨어 버전에 영향을 주지만, Azure AD tenant 필수 조건이나 인증 구성 문제를 해결하지는 않습니다. 기본 Azure AD 통합 요구 사항이 충족되지 않은 경우, 버전 업그레이드로는 Contoso.com 계정이 cluster에 액세스할 수 있게 되지 않습니다. 또한 문제에서 설명한 근본 원인을 해결하지 못한 채 운영 변경만 추가합니다. 따라서 이는 적절한 첫 번째 단계가 아닙니다.
Azure AD Premium P2는 Privileged Identity Management 및 Identity Protection과 같은 고급 ID 거버넌스 및 보호 기능을 제공합니다. 이러한 기능은 표준 통합 시나리오에서 Azure AD 계정을 사용한 AKS 인증을 허용하는 데 필요하지 않습니다. P2를 구매하거나 활성화하면 액세스 문제를 직접 해결하지 못한 채 비용과 복잡성만 증가합니다. 따라서 관리 작업을 최소화하지 못하며 정답이 아닙니다.
Azure AD User settings를 구성하는 것이 올바른 첫 번째 단계인 이유는, 기존 시험 시나리오의 AKS Azure AD 통합이 Azure AD 애플리케이션 등록 권한에 의존하기 때문입니다. 사용자가 애플리케이션 등록이 차단되어 있으면 통합 프로세스가 실패하거나 사용자가 Contoso.com 계정으로 예상대로 인증하지 못할 수 있습니다. 이 tenant 설정을 변경하는 것은 ID 필수 조건을 직접 해결하는 가벼운 관리 작업입니다. 또한 AKS cluster를 다시 빌드하거나 크게 수정하지 않으므로 관리 작업을 최소화해야 한다는 요구 사항에도 부합합니다.
문제 분석
핵심 개념: 이 문제는 사용자 인증을 위한 Azure Kubernetes Service (AKS)와 Azure Active Directory (Azure AD) 통합에 초점을 맞춥니다. AZ-500에서 일반적으로 출제되는 기존 AKS Azure AD 통합 시나리오에서는 AKS가 통합 과정에서 Azure AD 애플리케이션을 생성하거나 이에 의존하므로, 사용자가 애플리케이션을 등록할 수 있는 권한이 Azure AD에 필요합니다. AKS1에 Contoso.com의 계정을 사용하여 액세스할 수 없다면, 첫 번째 단계는 Azure AD tenant 설정이 필요한 앱 등록 동작을 허용하는지 확인하는 것입니다. 정답인 이유: Azure AD User settings를 구성하는 것은 cluster를 다시 빌드하지 않고도 AKS Azure AD 통합을 활성화하거나 완료하기 위한 일반적인 필수 조건을 해결하므로, 가장 영향이 적고 작업이 가장 적게 드는 첫 번째 조치입니다. 특히 AKS에 대해 Azure AD 인증을 설정할 때 사용자가 애플리케이션을 등록할 수 있도록 허용하는 것이 필요할 수 있습니다. 이는 불필요한 cluster 재생성을 피하면서 Contoso.com 계정의 액세스를 직접 지원합니다. 주요 기능: - AKS는 Azure AD와 통합될 수 있으므로 사용자는 조직 ID로 인증합니다. - Azure AD tenant의 User settings는 비관리자 사용자가 애플리케이션을 등록할 수 있는지 여부를 제어합니다. - 적절한 Azure AD 구성은 AKS Azure AD 인증을 활성화하거나 문제를 해결하기 전에 필요한 필수 조건인 경우가 많습니다. - 관리 작업 최소화 요구 사항에서는 인프라를 다시 빌드하는 것보다 tenant 설정을 변경하는 것이 더 적합합니다. 일반적인 오해: - 지원되는 구성 경로가 없고 해결해야 할 더 간단한 필수 조건도 없는 경우가 아니라면, AKS cluster를 다시 만드는 것이 첫 번째 단계는 아닙니다. - Kubernetes 버전을 업그레이드해도 Azure AD tenant 인증 필수 조건 문제는 해결되지 않습니다. - 표준 AKS 인증 통합에는 Azure AD Premium P2가 필요하지 않습니다. 시험 팁: Azure 서비스가 Azure AD 통합에 의존하는 경우, 먼저 tenant 필수 조건, 특히 앱 등록 권한 및 동의 관련 설정을 확인하십시오. Microsoft 시험에서는 일반적으로 운영 중단이 가장 적은 방식으로 문제를 해결하는 답이 선호됩니다. 항상 Azure AD의 ID 필수 조건과 리소스 재생성과 같은 인프라 수명 주기 작업을 구분하십시오.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Azure subscription에 4개의 Azure SQL managed instance가 포함되어 있습니다. managed instance의 SQL injection 공격에 대한 취약성을 평가해야 합니다. 가장 먼저 무엇을 해야 합니까?
Azure Sentinel workspace를 생성하면 로그 분석, 상관 분석 및 incident response를 위한 SIEM/SOAR 플랫폼이 설정됩니다. Sentinel은 Defender for Cloud 경고 및 SQL 로그를 수집하여 잠재적인 SQL injection 활동을 탐지하고 조사하는 데 도움을 줄 수 있지만, Azure SQL Managed Instance에 대한 초기 취약성 평가를 수행하지는 않습니다. 일반적으로 먼저 Defender for SQL/VA를 활성화한 다음 경고를 Sentinel에 통합합니다.
Advanced Data Security(기존 용어)를 활성화하면 Managed Instance를 포함한 Azure SQL resource에 대해 Vulnerability Assessment 및 threat detection과 같은 Microsoft Defender for SQL 기능이 활성화됩니다. 이는 잘못된 구성을 검사하고 의심스러운 쿼리 패턴 및 비정상적인 활동에 대한 탐지/경고를 활성화하여 SQL injection과 같은 공격에 대한 노출을 평가하는 올바른 첫 단계입니다. 보안 상태 평가를 직접적으로 다룹니다.
Azure Monitor의 SQL Health Check solution은 SQL injection에 대한 보안 vulnerability assessment보다는 모니터링 및 운영 인사이트(가용성, 성능, 구성 상태)에 중점을 둡니다. 성능 이상 징후를 식별하는 데는 도움이 될 수 있지만, injection 위험을 평가하거나 Defender for SQL Vulnerability Assessment 및 threat detection에 상응하는 보안 권장 사항/경고를 제공하도록 설계되지는 않았습니다.
Azure Advanced Threat Protection (ATP) instance를 생성하는 것은 Azure SQL Managed Instance 취약성 평가에 적용되지 않습니다. Azure ATP(현재 명칭: Microsoft Defender for Identity)는 Active Directory identity(주로 온-프레미스)와 관련된 의심스러운 활동 탐지에 중점을 둡니다. SQL threat protection은 Azure ATP instance를 배포하는 방식이 아니라 Defender for Cloud를 통한 Microsoft Defender for SQL(이전 명칭: SQL ATP)에서 제공됩니다.
문제 분석
핵심 개념: 이 문제는 Azure SQL Managed Instance를 포함한 Azure SQL에 대한 Microsoft Defender for SQL(이전 명칭: SQL Advanced Threat Protection) 및 vulnerability assessment 기능에 대한 지식을 평가합니다. SQL injection은 application-layer 공격이지만, Azure 보안 시험 관점에서는 Defender for Cloud의 데이터베이스 보호 기능인 Vulnerability Assessment (VA) 및 threat detection을 사용하여 노출과 잘못된 구성을 평가합니다. 정답이 맞는 이유: SQL injection 공격에 대한 취약성을 평가하려면 첫 번째 단계는 Advanced Data Security를 활성화하는 것입니다. (이는 Vulnerability Assessment 및 Advanced Threat Protection/threat detection과 같은 Defender for SQL 기능을 활성화하는 데 사용되는 많은 시험 문제의 기존 명칭입니다.) 활성화한 후에는 vulnerability assessment를 실행하고, 보안 권장 사항(예: 과도한 권한, 누락된 패치/구성, 취약한 인증)을 검토하며, SQL injection 시도를 나타낼 수 있는 의심스러운 데이터베이스 활동(예: 비정상적인 쿼리, 의심스러운 로그인)에 대한 경고를 활성화할 수 있습니다. 이는 Azure Well-Architected Framework의 Security pillar인 보안 상태를 지속적으로 평가 및 개선하고 탐지를 활성화하는 원칙과 일치합니다. 주요 기능 / 모범 사례: - Vulnerability Assessment는 일반적인 SQL 보안 잘못된 구성과 위험한 설정을 검사하고 수정 지침을 제공합니다. - threat detection(Defender for SQL)은 의심스러운 활동에 대한 경고를 생성하며 Defender for Cloud 및 선택적으로 Microsoft Sentinel과 통합됩니다. - 중앙 집중식 상태 관리: Defender for Cloud는 subscription 전체에서 여러 managed instance를 관리할 수 있습니다. - 모범 사례: subscription 수준(또는 해당되는 경우 resource 수준)에서 Defender plan을 활성화하고, 경고 수신자를 구성하며, 보호 기능이 활성화된 후 SIEM(Sentinel)과 통합합니다. 일반적인 오해: - Sentinel은 SIEM/SOAR 및 상관 분석용이며, 자체적으로 SQL Managed Instance의 vulnerability assessment를 수행하지는 않습니다. 일반적으로 먼저 Defender for SQL을 활성화한 다음 경고/로그를 Sentinel로 전달합니다. - Azure Monitor의 “SQL Health Check”는 injection 취약성이 아니라 운영 상태/성능에 중점을 둡니다. - “Azure ATP instance” 생성은 관련이 없습니다. Azure ATP(현재 명칭: Microsoft Defender for Identity)는 SQL injection이 아니라 온-프레미스 AD identity 신호를 대상으로 합니다. 시험 팁: - Azure SQL(Managed Instance 포함)의 경우 vulnerability assessment 및 SQL threat detection은 Microsoft Defender for Cloud/Defender for SQL을 통해 제공됩니다(이전 표현에서는 Advanced Data Security로 자주 언급됨). - 문제가 “취약성 평가” 또는 “구성 평가”를 묻는다면 Vulnerability Assessment/Defender for Cloud 권장 사항을 떠올리십시오. 여러 소스 전반에서 “상관 분석 및 대응”을 묻는다면 Sentinel을 떠올리십시오. - 명칭 변경을 기억하십시오: Advanced Data Security/SQL ATP -> Defender for Cloud의 Microsoft Defender for SQL.
HOTSPOT - Sub2의 VM1, VM2 및 VM3의 보안을 평가하고 있습니다. 다음 각 문장에 대해, 문장이 참이면 Yes를 선택하세요. 그렇지 않으면 No를 선택하세요. 참고: 각 정답 선택은 1점의 가치가 있습니다. Hot Area:
인터넷에서 HTTP를 사용하여 VM1의 web server에 연결할 수 있습니다.
예. VM1에는 Internet-facing entry point와 TCP/80에 대한 유효한 inbound allow path가 있으므로 Internet에서 HTTP를 통해 도달할 수 있습니다. Azure에서 이는 일반적으로 VM1의 NIC에 public IP가 할당되어 있거나(또는 public Load Balancer/App Gateway 뒤에 있거나), 적용되는 NSG(NIC-level 및/또는 subnet-level)에 Internet(또는 Any)에서 VM으로의 TCP port 80을 허용하는 inbound rule이 포함되어 있음을 의미합니다. 기본 NSG rules는 Internet으로부터의 inbound를 허용하지 않으므로 이러한 명시적 allow가 필요합니다. custom allow rule이 없으면 inbound HTTP는 거부됩니다. 질문은 특히 HTTP를 사용하여 web server에 연결하는 것에 관한 것이므로, 핵심은 TCP/80이 end-to-end로 허용되는지 여부입니다. 다른 rules(예: HTTPS/443만 허용)는 HTTP access를 충족하지 않습니다.
Internet에서 HTTP를 사용하여 VM2의 web server에 연결할 수 있습니다.
아니요. VM2는 TCP/80에 대해 Internet-to-VM inbound path가 유효하지 않기 때문에 Internet에서 HTTP를 통해 도달할 수 없습니다. 가장 일반적인 이유(그리고 일반적으로 AZ-500에서 테스트되는 내용)는 다음과 같습니다: VM2에 public IP가 없고 public Load Balancer/Application Gateway를 통해 게시되지 않았으며, 그리고/또는 NSG effective rules에 Internet에서 오는 TCP/80에 대한 inbound allow가 포함되어 있지 않습니다. VM2가 내부적으로 web server를 실행하더라도, public endpoint와 inbound HTTP를 허용하는 NSG rule이 없으면 Internet 클라이언트는 연결을 시작할 수 없습니다. 또한 기본 NSG rules는 virtual network 내부와 Azure Load Balancer로부터의 inbound만 허용하며, Internet으로부터의 inbound는 허용하지 않는다는 점에 유의하세요. 따라서 명시적인 allow와 public entry point가 없으면 Internet에서의 HTTP는 실패합니다.
Internet에서 HTTP를 사용하여 VM3의 web server에 연결할 수 있습니다.
아니요. VM3는 유효한 connectivity controls에 따라 Internet에서의 inbound TCP/80에 노출되어 있지 않기 때문에 Internet에서 HTTP를 통해 도달할 수 없습니다. VM2와 마찬가지로, Internet에서 도달 가능하려면 (1) Internet-facing IP(직접적으로 VM NIC에 있거나 간접적으로 public load-balancing/publishing service를 통해 제공됨)와 (2) 어떤 deny보다 더 높은 priority에서 Internet으로부터의 inbound TCP/80을 허용하는 NSG rule이 모두 필요합니다. VM3가 private subnet에만 있거나, public IP가 없거나, port 80에 대한 allow rule이 없는 NSG로 보호되거나(또는 우선 적용되는 deny가 포함된 경우) Internet으로부터의 HTTP 연결은 설정될 수 없습니다. 이는 secure networking best practices와 일치합니다. 즉, backend VM은 private하게 유지하고 필요할 때만 제어된 ingress(WAF/App Gateway/Front Door)를 통해 게시해야 합니다.
Azure subscription이 있습니다. S1 App Service plan을 사용하는 Contoso1812라는 Azure web app을 만듭니다.
다음 작업을 계획하고 있습니다. Contoso1812를 가리키는 www.contoso.com용 CNAME DNS record를 만듭니다. 사용자가 https://www.contoso.com URL을 사용하여 Contoso1812에 액세스할 수 있도록 해야 합니다. 어떤 두 가지 작업을 수행해야 합니까? 각 정답은 솔루션의 일부를 나타냅니다. 참고: 각 정답 선택에는 1점이 부여됩니다.
System-assigned managed identity는 web app이 비밀을 저장하지 않고 Azure 서비스(예: Key Vault, Azure SQL, Storage)에 인증할 수 있게 합니다. 이는 custom domain이나 TLS/SSL을 구성하지 않습니다. 일부 아키텍처에서는 managed identity를 사용해 Key Vault에서 certificate를 가져올 수 있지만, 단순히 이를 켠다고 해서 https://www.contoso.com이 작동하는 것은 아닙니다.
web app에 hostname(custom domain)을 추가하는 것은 App Service가 www.contoso.com에 대한 요청을 수락하고, Azure가 사용자가 해당 domain을 제어하고 있음을 검증할 수 있도록 하기 위해 필요합니다(일반적으로 CNAME/TXT validation 사용). hostname을 추가하지 않으면 CNAME만으로는 해당 host header에서 사이트를 안정적으로 제공하기에 충분하지 않습니다.
Scale out은 더 많은 부하를 처리하고 가용성을 향상시키기 위해 instance 수를 늘립니다. 이는 custom domain 매핑이나 HTTPS를 활성화하지 않습니다. instance가 많더라도 hostname이 추가되고 certificate가 바인딩되지 않으면 사용자는 여전히 https://www.contoso.com에 액세스할 수 없습니다.
Deployment slots는 staging/production 환경을 제공하고 다운타임을 줄인 swap 기반 배포를 가능하게 합니다. 이는 custom domain을 구성하거나 해당 domain에 대해 HTTPS를 활성화하는 것과는 관련이 없습니다. slot은 자체 hostname을 가질 수 있지만, https://www.contoso.com을 제공해야 하는 요구 사항을 해결하지는 못합니다.
Scale up은 더 많은 기능이나 리소스를 얻기 위해 App Service plan의 tier/size를 변경합니다. app은 이미 S1(Standard)에 있으므로 custom domain과 SSL binding을 이미 지원합니다. 이 시나리오에서 https://www.contoso.com을 활성화하기 위해 scale up은 필요하지 않습니다.
PFX file을 업로드하면 SSL/TLS certificate가 App Service에 제공되어 custom hostname(www.contoso.com)에 대한 SSL binding을 만들 수 있으므로 HTTPS가 활성화됩니다. 이는 public CA의 certificate가 있을 때 사용하는 표준적인 접근 방식입니다. 업로드 후 SNI SSL을 사용하여 hostname에 바인딩하면 HTTPS 구성이 완료됩니다.
문제 분석
핵심 개념: 이 문제는 Azure App Service에서 custom domain을 HTTPS로 보호하는 방법을 테스트합니다. App Service web app이 https://www.contoso.com에서 트래픽을 제공하려면 Azure가 (1) www.contoso.com을 app에 대한 유효한 host header로 인식해야 하고 (2) 해당 hostname에 바인딩된 SSL/TLS certificate를 가지고 있어야 합니다. 정답이 맞는 이유: CNAME record(www.contoso.com -> contoso1812.azurewebsites.net)를 만든 후에는 web app에 custom hostname을 추가해야 합니다(B). 이렇게 하면 domain 소유권을 검증하고(CNAME/TXT validation 사용) App Service가 해당 host header에 대한 요청을 수락하도록 구성합니다. 그렇지 않으면 www.contoso.com에 대한 요청이 app으로 올바르게 라우팅되지 않습니다. 다음으로, 해당 custom hostname에 대해 HTTPS를 사용하려면 app에서 사용할 수 있는 certificate가 있어야 하며, 그 certificate를 hostname에 바인딩해야 합니다. 보기 중에서는 PFX file 업로드(F)가 App Service에 certificate를 제공하여 www.contoso.com에 대한 SNI 기반 SSL binding을 만들 수 있게 하는 작업입니다. app은 이미 custom domain과 TLS/SSL binding을 지원하는 S1 plan에 있습니다. 주요 기능 / 구성 참고 사항: - App Service custom domain은 “Custom domains”에서 hostname을 추가하고 validation을 완료해야 합니다. - HTTPS에는 SSL certificate와 SSL binding이 필요합니다(SNI SSL이 일반적임). PFX 업로드는 일반적인 방법이며, 대안으로는 App Service Managed Certificate(일부 시나리오) 또는 Azure Key Vault 통합이 있지만 보기에는 없습니다. - S1은 TLS/SSL 및 SNI를 지원합니다. IP-based SSL은 일반적으로 더 높은 tier 또는 레거시 요구 사항을 위해 예약됩니다. 일반적인 오해: - Scale up/out(C/E)은 성능과 용량에 영향을 주지만, domain/HTTPS 활성화와는 관련이 없습니다. - Managed identity(A)는 Azure 리소스(Key Vault, Storage 등)에 안전하게 액세스하기 위한 것이며, HTTPS를 활성화하기 위한 것이 아닙니다. - Deployment slots(D)는 안전한 배포와 테스트에 도움이 되지만, custom domain HTTPS와는 관련이 없습니다. 시험 팁: App Service + custom domain + HTTPS 문제에서는 다음 순서로 생각하세요: DNS record -> App Service에서 hostname 추가/검증 -> certificate 제공(PFX/Key Vault/managed cert) -> certificate를 hostname에 바인딩. 또한 어떤 tier가 custom domain과 SSL을 지원하는지도 기억하세요(Basic 이상, S1이면 충분함).
HOTSPOT - 다음 그림에 표시된 Azure 리소스 계층 구조가 있습니다.
RG1, RG2 및 RG3는 resource group입니다. RG2에는 VM2라는 virtual machine이 포함되어 있습니다. 다음 표에 표시된 사용자에게 role-based access control (RBAC) 역할을 할당합니다.
다음 각 문장에 대해, 문장이 참이면 Yes를 선택하십시오. 그렇지 않으면 No를 선택하십시오. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:
User1은 RG1에 virtual machines를 배포할 수 있습니다.
예. User1은 Tenant Root Group 범위에서 Contributor role이 할당되어 있습니다. tenant root management group의 RBAC 할당은 tenant의 모든 하위 management groups, subscriptions, resource groups 및 resources에 상속됩니다. RG1은 Subscription1 아래에 있고, Subscription1은 ManagementGroup1 아래에 있으며, ManagementGroup1은 Tenant Root Group 아래에 있으므로 User1은 RG1에 대한 Contributor 권한을 가집니다. Contributor에는 RG1에 virtual machines를 배포(생성)하는 데 필요한 Microsoft.Compute/virtualMachines/write 및 관련 권한이 포함됩니다. VM 생성을 차단할 deny assignment 또는 policy에 대한 언급이 없으므로, RBAC 관점에서 User1은 RG1에 VMs를 배포할 수 있습니다.
User2는 VM2를 삭제할 수 있습니다.
예. User2에는 Subscription2 범위에서 Virtual Machine Contributor 역할이 할당되어 있습니다. VM2는 RG2에 있고, RG2는 Subscription2 내에 있으므로 역할 할당은 상속을 통해 VM2에 적용됩니다. Virtual Machine Contributor는 virtual machine 관리(삭제 포함)를 허용합니다(Microsoft.Compute/virtualMachines/delete와 같은 작업 포함). 이 역할은 VNet 또는 storage account와 같은 관련 리소스에 대한 전체 제어 권한을 부여하지는 않지만, 기존 VM 리소스 자체를 삭제하는 것은 이 역할의 범위에 포함됩니다. 따라서 User2는 VM2를 삭제할 수 있습니다(리소스 잠금 또는 deny assignment가 없는 경우이며, 문제에서는 이에 대한 언급이 없습니다).
User3는 VM2의 기본 제공 Administrator 계정의 비밀번호를 재설정할 수 있습니다.
아니요. User3에는 RG2 범위에서 Virtual Machine Administrator Login이 할당되어 있습니다. 이 역할은 OS 수준 액세스를 위한 것으로, 사용자가 Azure AD 기반 로그인(해당 VM이 AAD 로그인용으로 구성되어 있고 OS가 이를 지원하는 경우)을 사용하여 administrator로 VM에 로그인할 수 있도록 합니다. 이는 Azure 리소스 구성을 변경하기 위한 management-plane 역할이 아닙니다. 기본 제공 로컬 Administrator 계정의 비밀번호 재설정은 일반적으로 management-plane 작업(예: VMAccess extension/Reset password 기능 사용)을 통해 수행되며, 이를 위해서는 Microsoft.Compute/virtualMachines/extensions/write 및 관련 compute 작업과 같은 권한이 필요합니다. Virtual Machine Administrator Login에는 이러한 management 권한이 포함되지 않으므로, User3는 Azure를 통해 기본 제공 Administrator 비밀번호를 재설정할 수 없습니다.
HOTSPOT - 다음 표에 표시된 Azure virtual networks가 있습니다.
다음 표에 표시된 Azure virtual machines가 있습니다.
모든 virtual machines의 firewall은 ping 트래픽을 허용합니다. NSG1은 다음 그림과 같이 구성되어 있습니다.
Inbound security rules -
Outbound security rules - Priority Name Port Protocol Source Destination Action 65000 AllowVnetOutBound Any Any VirtualNetwork VirtualNetwork Allow 65001 AllowInternetOutBound Any Any Any Internet Allow 65500 DenyAllOutBound Any Any Any Any Deny 다음 각 문장에 대해, 문장이 참이면 Yes를 선택하십시오. 그렇지 않으면 No를 선택하십시오. 참고: 각 정답 선택에는 1점이 부여됩니다. Hot Area:
Allow_RDP는 포트 3389와 작업 Allow를 가집니다.
예. NSG1의 inbound rules 예시에서 Allow_RDP라는 이름의 custom rule은 포트 3389에서 Remote Desktop 트래픽을 허용하도록 구성되어 있습니다. 이는 해당 작업이 Allow이고 대상 포트가 3389임을 의미합니다. 이는 default inbound rules와는 구별되며, default inbound rules만으로는 인터넷에서 오는 RDP를 자체적으로 열지 않습니다.
Rule1에는 source ASG1과 action Allow가 있습니다.
예. NSG1에 대해 표시된 inbound rules에는 source가 ASG1로 설정되고 action이 Allow로 설정된 Rule1이 포함됩니다. NSG rules는 Application Security Groups를 source 또는 destination object로 사용할 수 있으므로, 이는 유효한 구성입니다. 따라서 이 문장은 제시된 화면과 일치하므로 예로 표시해야 합니다.
Rule2에는 소스 ASG2와 Allow 작업이 있습니다.
예. 제시된 화면에는 Rule2가 사용자 지정 인바운드 NSG 규칙으로 포함되어 있으며, 소스로 ASG2를 사용하고 Allow 작업을 사용합니다. 이는 ASG2의 VM에서 시작되는 트래픽이 destination 및 port와 같은 다른 규칙 필드의 적용을 받는 조건하에 해당 규칙에 의해 명시적으로 허용된다는 의미입니다. 문장이 규칙 정의와 일치하므로 정답은 예입니다.
Rule3에는 소스 ASG4와 작업 Allow가 있습니다.
아니요. inbound rules 도표를 기준으로 보면, Rule3는 소스 ASG4와 작업 Allow를 가진 것으로 정의되어 있지 않습니다. 표시된 custom rules는 특정 ASG 기반 소스를 식별하며, 이 진술은 실제 Rule3 구성과 일치하지 않습니다. 따라서 이 진술은 아니요로 표시해야 합니다.
Rule4에는 Deny action이 있습니다.
예. inbound rules exhibit에는 Rule4가 포함되어 있으며 해당 action은 Deny입니다. NSG의 custom deny rule은 더 낮은 priority의 default rule보다 우선하며, 더 광범위한 default allow가 그렇지 않았다면 적용될 수 있는 경우에도 트래픽을 차단할 수 있습니다. 이 설명은 rule definition과 일치하므로 정답은 예입니다.
AllowVnetInBound는 source와 destination이 VirtualNetwork이고 action이 Allow입니다.
예. AllowVnetInBound는 Source가 VirtualNetwork로 설정되고, Destination이 VirtualNetwork로 설정되며, Action이 Allow로 설정되는 기본 inbound NSG rule입니다. 이 질문은 rule 정의 자체에 대해 묻고 있으며, 그 정의는 모든 NSG에서 표준입니다. 더 높은 priority를 가진 다른 inbound rule이 특정 트래픽에 대한 그 효과를 재정의할 수는 있지만, 기본 rule의 구성된 속성 자체를 변경하지는 않습니다.
AllowAzureLoadBalancer는 source가 AzureLoadBalancer이고 action이 Allow입니다.
예. 또 다른 기본 inbound NSG rule은 AllowAzureLoadBalancerInBound입니다. 이 rule은 Source = AzureLoadBalancer이고 Action = Allow인 트래픽을 허용합니다(destination은 일반적으로 해당 scope 내의 Any입니다). 이 기본 rule은 Azure Load Balancer health probe 및 관련 platform 트래픽을 지원합니다. 이 rule은 더 높은 priority(더 낮은 숫자)를 가진 custom rule로 대체되지 않는 한 모든 NSG에 기본적으로 존재합니다. 제시된 화면에는 inbound rule이 표시되지 않지만, 질문은 기본 rule이 해당 source와 action을 가지는지 묻고 있으며, 이는 맞습니다.
DenyAllInBound에는 Deny action이 있습니다.
예. 기본 inbound NSG rule인 DenyAllInBound는 Action = Deny입니다. 이 rule은 AllowVNetInBound와 AllowAzureLoadBalancerInBound 이후에 평가되며, 더 높은 priority의 custom allow rule이 존재하지 않는 한 다른 모든 inbound traffic(Internet으로부터의 traffic 포함)을 차단합니다. 이것이 public IP가 VM에 있다고 해서 management port에 자동으로 도달할 수 있는 것이 아닌 핵심 이유입니다. NSG에서 이를 명시적으로 허용해야 하며(그리고 OS firewall에서도 이를 허용하는지 확인해야 합니다). 따라서 DenyAllInBound가 deny rule이라는 설명은 참입니다.
VM1은 VM3에 성공적으로 ping할 수 있습니다.
예. VM1과 VM3은 peered virtual networks에 있으므로 Subnet1과 Subnet3 사이에 network reachability가 있습니다. VM firewall은 ICMP를 허용하며, 표시된 inbound NSG rule은 관련 traffic path를 차단하는 대신 허용합니다. 따라서 VM1은 VM3에 성공적으로 ping할 수 있습니다. 이는 default rule만으로 결정되는 것이 아니라 custom inbound rule도 함께 고려해야 합니다.
VM2는 VM4에 성공적으로 ping할 수 있습니다.
아니요. VM2는 VNET2의 Subnet2에 있습니다. VM4는 VNET4의 Subnet4에 있습니다. VNET4에는 peering이 구성되어 있지 않습니다(Peered network = None). VNet peering, VPN gateway, ExpressRoute 또는 기타 routing connectivity가 없으면 VNET2와 VNET4 사이에 network path가 없습니다. NSG rules는 connectivity를 생성할 수 없으며, 이미 route가 있는 traffic만 allow/deny할 수 있습니다. VM4에 public IP가 있더라도, routing이 없기 때문에 VM2는 VM4의 private IP에 도달할 수 없고, VM4의 public IP에 도달하는 것은 “Internet” traffic이 되며 VM4가 적절하게 응답해야 합니다. 또한 Internet에서 VM4로의 inbound는 기본적으로 거부됩니다(DenyAllInBound). 따라서 VM2는 VM4에 성공적으로 ping할 수 없습니다.
VM3는 인터넷에서 Remote Desktop을 사용하여 액세스할 수 있습니다.
아니요. VM3에는 public IP address가 있지만, 인터넷으로부터의 inbound access는 TCP/3389 (RDP)에 대해 Internet(또는 특정 source IP range)에서의 명시적인 inbound allow rule이 없는 한 NSG inbound rule DenyAllInBound에 의해 기본적으로 차단됩니다. 제시된 자료에는 outbound rules만 표시되어 있으며, Allow_RDP와 같은 inbound rule은 표시되어 있지 않습니다. 따라서 인터넷에서 VM3로의 RDP는 NSG에서 거부됩니다. 이는 보안 모범 사례(Azure Well-Architected Framework)와도 일치합니다. RDP/SSH를 직접 노출하지 말고, Azure Bastion, Just-In-Time VM access (Defender for Cloud)를 사용하거나, NSG를 통해 알려진 admin IP들로 제한해야 합니다.
지금 학습 시작하기
Cloud Pass를 다운로드하고 모든 Microsoft AZ-500 기출 문제를 풀어보세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
앱 받기
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.