Exam AZ-300 topic 1 question 72 discussion

"A monitoring solution on a different network will need access to the VMs inside the scale set." Only deploying a VM with a public IP will not be a solution. It would need to be configured as a router, proxy or whatever, and I guess the monitoring solution needs direct access to the VM in the Scale Set, there would be a need to deploy an agent on the monitored VM's etc. So, answer B should be correct.

Answer is A: • Connect to VM instances using RDP or SSH: To connect to VM instances using RDP or SSH, you can configure a scale set to automatically assign a public IP address. This option is turned off by default. The VMs are inside a virtual network, making it impossible to connect to them using RDP or SSH. Connect to VM instances using a jumpbox: You can create a standalone VM inside the same virtual network to act as a jumpbox to connect to another scale set instance in the set. The standalone VM gets a public IP address, which can be connected using RDP or SSH. Once connected to the VM, you can use it to connect to other instances using the internal

Answer will be A. The new Machine will work as a Jump server.

Not enough info in the question to answer properly, IMO. It does not say which network you are deploying the standalone machine in. Are we deploying in the VNET with the monitoring application or the VNET with the scale set.

Question is specifically asking to monitoring NOT accessing. Jumphost unless redirecting probes will not assist in monitoring for a remote location.

Answer is A, by default when you deploy a VM in the same VNET you can connect to the other VM´s by private IP, so you connect to the isolated VM with RDP or SSH and then to the other private VM´s via private IP

Answer A is correct. See Public IPv4 section at https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-networking

Answer is Yes (A) Instead, deploy a standalone VM that has a public IP address to the virtual network.

Correct Answer : A There is a concept many organizations use. Its called as a Bastion or an OMS(especially in AWS). We use it regularly at our work place. The only purpose it serves is to sit in a DMZ (public IP Address subnet) and give any kind of access to VMs inside the network. The exact requirement that is being asked here. So answer is A

Guys. It says it very clearly: "You need to define public access TO the VMs." The solution does not define public access to the VMs. It defines public access TO another VM (the one with public access). You can route that traffic towards the VMSS VMs, making the VMs on the scale publicly accessible. But they would not have public access defined. It would be a correct answer for an statement such "You need to made the VMs reachable from a public network."

This question is not Azure specific - it is about general Infra Architecture and best practices for Monitoring solutions. What they are asking here is not about accessing VMs inside Scale Set - instead we need to provide solution that will be used by Monitoring Tool for ongoing polling data from these VMs and sending it to the main Monitoring hub. Jump Box can be used for accessing VMs inside Scale Set (RDP/SSH) but Jump Servers are designed for performing admin tasks on VMs, not for providing ongoing access between multiple monitored VMs and the main Monitoring app. Using 'standalone' Jump Box for monitoring would also create a single-point-of-failure solution (if Jump Box goes down, and it can - these are usually small VMs), we will lose Monitoring and will have no clue what is going on with our VMs inside Scale Set) We all agree it is possible to use standalone VM with Public access to reach to VMs inside Scale Set but this is not suitable solution for Monitoring I believe answer to this question is 'No', as this solution does not meet Monitoring objective

Answer A is Lab tested. - I created a scale set at VNET01 / Subnet01, and assign a Network Security Group that allow RDP, and by default all VNET inbound traffic. - I can access from a vm at VNET01 / Subnet02 (as it said "different network") through RDP, to each VM in VMSS. So ... I guess that, if I can do that, is possible to monitor a VMSS from another VM that belongs to diffent network. Can anyone tell me if I'm doing something wrong?

Answer A is Lab tested. - I just created a vm01 with scale set, no access to internet in vnet01, subnet01. - Create vm02, no scale set, with public IP, in vnet01 but subnet02. - Related to the question "VM that will need to be monitoring from other VM in another network", so same vnet. I connected through RDP from vm02 to vm01 with no problem. Scale Set is about SLA, not functionality, right?

LAB TESTED Answer should be A. If you create a VM in scale set, with no Public IP access, you're ensuring a SLA, but this doesn't means that works different that a VM with no Scale Set. - I created a VM01 with Scale Set, and no internet access at vnet01 - subnet01. - After that, I created a VM02, with no Scale Set, internet access (Public IP), at vnet01 - subnet02. - Connected to VM02 through RDP (Public IP). - Inside VM02 get access with no problem to VM01 from VM02 through RDP. At the question said that VM01 need to be monitoring from VM02 in other Network (not different VNET). So . . . I'm a rookie, and I'm sure that maybe could be another options, but this is what I tried, and this is what I get.

The jump box solutions works provided it is in the same VNet as the scale set. The proposed solution is very vague, "...... to the vivrtual network". Question is, which virtual network is the question referring to? This is a trick question you can easily fail under exam conditions. In my honest opinion, it is a NO.

A is answer. new VM is jump box or bastion host.

also agree with B. Key item in question - does not specify which network requires access, so it may be another internal network.