Question : You have created a Virtual Network in Azure named QuickNet, You design the virtual network to include two subnets, one named Quick1-subnet and one named Quick2-subnet.
Quick1-subnet : (Starting IP : 10.0.0.0, CIDR Address Count : /27(32) , Usable Address Range : 10.0.0.0-10.0.0.31) Quick2-subnet : (Starting IP : 10.0.0.32, CIDR Address Count : /29(8) , Usable Address Range : 10.0.0.32-10.0.0.39)
identify the number of IP addresses that will be available for virtual machines (VMs) or cloud services in each subnet. 1. 3 for Quick1-subnet and 3 for Quick2-subnet
Correct Answer : Get Lastest Questions and Answer : Explanation: Quick2-subnet 32-39 = 7 (AZure reserve first 4 IPs) = 3 available IPs Quick1-subnet 0-31 = 31 (AZure reserve first 4 IPs) = 27 available
Within each subnet, the first three IP addresses and the last IP address are reserved, and you cannot use them for VMs or cloud services. The smallest subnets that are supported use a 29-bit subnet mask. VMs that are configured with IP addresses from one subnet can be moved to another subnet of the same virtual network and receive different IP configurations.
Question : You administer an Azure solution that uses a virtual network named QuickVNet. QuickVNet has a single subnet named QuickSubnet-. You discover a high volume of network traffic among four virtual machines (VMs) that are part of QuickSubnet-1. You need to isolate the network traffic among the four VMs. You want to achieve this goal with the least amount of downtime and impact on users. What should you do? 1. Create a new subnet in the existing virtual network and move the four VMs to the new subnet.
2. Create a site-to-site virtual network and move the four VMs to your datacenter.
4. Create an availability set and associate the four VMs with that availability set.
Correct Answer : Get Lastest Questions and Answer : Explanation: You want to achieve this goal with the least amount of downtime and impact on users". That's why not B. And the cost of that wouldn't make sense. By moving them to a separate subnet in the same VNet you *can* isolate them. I say *can* because you'd still have to configure the Windows firewall to block/allow traffic on the machines in the new subnet.
Currently, Windows Azure provides routing across subnets within a single virtual network, but does not provide any type of network ACL capability with respect to internal DIP addresses. So in order to restrict access to machines within a single virtual network, those machines must leverage Windows Firewall with Advanced Security" Machine Isolation Options
There are three basic options to be discussed in this paper where machine isolation may be implemented on the Windows Azure platform:
Between machines deployed to a single virtual network Between machines deployed to distinct virtual networks Between machines deployed to distinct virtual networks where a VPN connection has been established from on-premises with both virtual networks These options will be detailed in the sections that follow.
By default, Windows Server virtual machines created from the gallery will have two public endpoints, specifically RDP and Remote PowerShell connections. There will be no other public endpoints except additional endpoints that are added by the administrator. These endpoints and any others created by the administrator may be secured with access control lists (ACLs) on any given IaaS virtual machine. As of this writing ACLs are available for IaaS virtual machines, but not for PaaS web or worker roles.
How Network ACLs Work
An ACL is an object that contains a list of rules. When you create an ACL and apply it to a virtual machine endpoint, packet filtering takes place on the host node of your virtual machine. This means the traffic from remote IP addresses is filtered by the host node for matching ACL rules instead of on your virtual machine. This prevents your virtual machine from spending the precious CPU cycles on packet filtering.
When a virtual machine is created, a default ACL is put in place to block all incoming traffic. However, if an input endpoint is created (for example, port 3389), then the default ACL is modified to allow all inbound traffic for that endpoint. As discussed above, when a virtual machine is created from the Azure gallery, a PowerShell endpoint and an RDP endpoint are created using standard private ports but randomly generated public ports, as seen in the portal below. Inbound traffic from any remote subnet is then restricted to those endpoints and no firewall provisioning is required. All other ports are blocked for inbound traffic unless endpoints are created for those ports. Outbound traffic is allowed by default.
Using Network ACLs, you can do the following:
Selectively permit or deny incoming traffic based on remote subnet IPv4 address range to a virtual machine input endpoint. Blacklist IP addresses Create multiple rules per virtual machine endpoint Specify up to 50 ACL rules per virtual machine endpoint Use rule ordering to ensure the correct set of rules are applied on a given virtual machine endpoint (lowest to highest) Specify an ACL for a specific remote subnet IPv4 address. So network ACLs are the key to protecting virtual machine public endpoints and controlling that type of access to them. Currently, you can specify network ACLs for IaaS virtual machines input endpoints, which allow you to control access from the internet to each virtual machine. Unless you specify endpoints, the virtual machines in a virtual network do not get incoming traffic and this is equivalent to having a default deny ACL at the network level which you can override on a per virtual machine basis. You cannot currently specify an ACL on a specific subnet contained in a virtual network, and we are looking into this for the future.
Option 1: Subnets within a Single Virtual Network
Currently, Windows Azure provides routing across subnets within a single virtual network, but does not provide any type of network ACL capability with respect to internal DIP addresses. So in order to restrict access to machines within a single virtual network, those machines must leverage Windows Firewall with Advanced Security, as depicted simply in the diagram below.
In order to secure the server, Windows Firewall could be configured to block all inbound connections, and inbound rules would be setup to determine:
1) what local ports will accept connections,
2) what remote ports from which connections will be accepted,
3) what remote IP addresses will be accepted,
4) what authorized users can make connections, and
5) what authorized computers can make connections
In this case, the firewall exceptions would include local Dynamic IP (DIP) addresses within its own subnet and across other subnets configured for the virtual network. Any public endpoints would be secured with network ACLs. Firewall exceptions should, of course, include the private ports for public endpoints established with network ACLS.
Option 2: Subnets in Different Virtual Networks
In order to protect virtual machines from other machines deployed in other Azure virtual networks, or machines in other Azure cloud services not associated with a virtual network, or machines outside the Windows Azure platform, the Windows Azure network ACL feature would be used to provide access control to virtual machines. This is the most natural scenario in Windows Azure for application isolation, since by default the only access allowed on virtual machines are the default provided RDP and Remote PowerShell public endpoints. For any Azure virtual machine (PaaS or IaaS) that wishes to access another virtual machine in a different virtual network, its virtual IP (VIP) address will be considered as opposed to its DIP addresses within a single virtual network. So when a permit ACL is set on a given virtual machine endpoint, that ACL will consider the public VIP of the machine that desires to make a connection. We can see this in the diagram below.
We can selectively permit or deny network traffic (in the management portal or from PowerShell) for a virtual machine input endpoint by creating rules that specify "permit" or "deny". By default, when an endpoint is created, all traffic is permitted to the endpoint. So for that reason, it's important to understand how to create permit/deny rules and place them in the proper order of precedence to gain granular control over the network traffic that you choose to allow to reach the virtual machine endpoint. Note that at the instant you add one or more "permit" ranges, you aredenying all other ranges by default.
If you need to isolate resources further by preventing unauthorized communications between the subnets, you can use network security groups. (NSG)
Question : You maintain a virtual network named QuickVMNet , now you want to deploy a virtual machine and make sure that it is part of QuickVMNet , how can you do that? 1. Run the New-AzureVM Power Shell cmdlet.
The New-AzureQuickVM cmdlet sets the configuration for a new virtual machine and creates the virtual machine. You can create a new Azure service for the virtual machine by specifying either the Location or AffinityGroup parameters, or deploy the new virtual machine into an existing service.
The New-AzureVM cmdlet adds a new virtual machine to an existing Azure cloud service, or creates a new virtual machine and a new cloud service in the current subscription if either the Location or AffinityGroup parameter is specified.
You can use the New-AzureQuickVM syntax, New-AzureVM or New-AzureVMConfig syntax, The New-AzureQuickVM automatically creates and provisions the VM which does not require any additional steps.
1. Back up the Site and import into a new website. 2. Use the internal Certificate Authority and ensure that clients download the certificate chain. 3. Access Mostly Uused Products by 50000+ Subscribers 4. Change the web hosting plan to Standard.