Practice Test #1

예. 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를 충족하지 않습니다.

아니요. 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는 실패합니다.

아니요. 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)를 통해 게시해야 합니다.

예. 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에는 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에는 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 비밀번호를 재설정할 수 없습니다.

예. NSG1의 inbound rules 예시에서 Allow_RDP라는 이름의 custom rule은 포트 3389에서 Remote Desktop 트래픽을 허용하도록 구성되어 있습니다. 이는 해당 작업이 Allow이고 대상 포트가 3389임을 의미합니다. 이는 default inbound rules와는 구별되며, default inbound rules만으로는 인터넷에서 오는 RDP를 자체적으로 열지 않습니다.

예. NSG1에 대해 표시된 inbound rules에는 source가 ASG1로 설정되고 action이 Allow로 설정된 Rule1이 포함됩니다. NSG rules는 Application Security Groups를 source 또는 destination object로 사용할 수 있으므로, 이는 유효한 구성입니다. 따라서 이 문장은 제시된 화면과 일치하므로 예로 표시해야 합니다.

예. 제시된 화면에는 Rule2가 사용자 지정 인바운드 NSG 규칙으로 포함되어 있으며, 소스로 ASG2를 사용하고 Allow 작업을 사용합니다. 이는 ASG2의 VM에서 시작되는 트래픽이 destination 및 port와 같은 다른 규칙 필드의 적용을 받는 조건하에 해당 규칙에 의해 명시적으로 허용된다는 의미입니다. 문장이 규칙 정의와 일치하므로 정답은 예입니다.

아니요. inbound rules 도표를 기준으로 보면, Rule3는 소스 ASG4와 작업 Allow를 가진 것으로 정의되어 있지 않습니다. 표시된 custom rules는 특정 ASG 기반 소스를 식별하며, 이 진술은 실제 Rule3 구성과 일치하지 않습니다. 따라서 이 진술은 아니요로 표시해야 합니다.

예. inbound rules exhibit에는 Rule4가 포함되어 있으며 해당 action은 Deny입니다. NSG의 custom deny rule은 더 낮은 priority의 default rule보다 우선하며, 더 광범위한 default allow가 그렇지 않았다면 적용될 수 있는 경우에도 트래픽을 차단할 수 있습니다. 이 설명은 rule definition과 일치하므로 정답은 예입니다.

예. AllowVnetInBound는 Source가 VirtualNetwork로 설정되고, Destination이 VirtualNetwork로 설정되며, Action이 Allow로 설정되는 기본 inbound NSG rule입니다. 이 질문은 rule 정의 자체에 대해 묻고 있으며, 그 정의는 모든 NSG에서 표준입니다. 더 높은 priority를 가진 다른 inbound rule이 특정 트래픽에 대한 그 효과를 재정의할 수는 있지만, 기본 rule의 구성된 속성 자체를 변경하지는 않습니다.

예. 또 다른 기본 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을 가지는지 묻고 있으며, 이는 맞습니다.

예. 기본 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은 peered virtual networks에 있으므로 Subnet1과 Subnet3 사이에 network reachability가 있습니다. VM firewall은 ICMP를 허용하며, 표시된 inbound NSG rule은 관련 traffic path를 차단하는 대신 허용합니다. 따라서 VM1은 VM3에 성공적으로 ping할 수 있습니다. 이는 default rule만으로 결정되는 것이 아니라 custom inbound rule도 함께 고려해야 합니다.

아니요. 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에는 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들로 제한해야 합니다.