/AZ-300-Microsoft-Azure-Architect-Technologies

Study guide for Microsoft Azure Exam AZ-300

Exam AZ-300 - Microsoft Azure Architect Technologies

Overview

https://www.microsoft.com/en-us/learning/exam-az-300.aspx

This exam is for the Azure Architect role. Candidates for this exam are Azure Solution Architects who advise stakeholders and translates business requirements into secure, scalable, and reliable solutions. Candidates should have advanced experience and knowledge across various aspects of IT operations, including networking, virtualization, identity, security, business continuity, disaster recovery, data management, budgeting, and governance. This role requires managing how decisions in each area affects an overall solution. Candidates must be proficient in Azure administration, Azure development, and DevOps, and have expert-level skills in at least one of those domains.

If a candidate does not get a passing score on this exam in the first time, he/she must wait at least 24 hours to retake the exam. If this happens for the second time, the candidate must wait for at least 14 days to retake the exam. By this way, there is a maximum of 5 appearances allowed for an exam in a year.

  • Number of questions: 40 - 60

  • Exam time: 150 minutes

  • Passing score: 700

  • Do time management (after hands on labs some additional questions still might come), better to skip hands on labs if you are blocked by some hard question and answer rest of questions.

Practice tests will be available in February or March 2019. https://www.measureup.com/microsoft-azure-architect-technologies.html

Skills measured and links

  • Deploy and Configure Infrastructure (25-30%)
    • Analyze resource utilization and consumption
      • Configure diagnostic settings on resources
        • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-logs-overview#diagnostic-settings
        • Resource logs - these logs come from Azure services that deploy resources within an Azure subscription, such as Network Security Groups or Storage Accounts.
        • Resource diagnostic logs are configured using resource diagnostic settings. Tenant diagnostic logs are configured using a tenant diagnostic setting.
        • Where diagnostic logs and metrics are sent (Storage Account, Event Hubs, and/or Log Analytics).
        • Which log categories are sent and whether metric data is also sent.
        • How long each log category should be retained in a storage account. A retention of zero days means logs are kept forever. Otherwise, the value can be any number of days.
        • Collection of diagnostic logs can be enabled as part of creating a resource in a Resource Manager template or after a resource is created from that resource's page in the portal. You can also enable collection at any point using Azure PowerShell or CLI commands, or using the Azure Monitor REST API.
      • Create baseline for resources
        • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/alerts-dynamic-thresholds
        • Azure portal -> Monitor -> Alerts -> New alert rule
        • Metric Alert with Dynamic Thresholds detection uses ML to learn metrics' historical behavior, identify patterns and anomalies.
        • Threshold setting - sensitivity controls the amount of deviation from metric behavior for alert. Sensitivity (High/Medium/Low)
        • Operator setting - trigger when Lower than lower threshold; Greater than upper threshold; Greater than the upper threshold or lower than the lower threshold (default)
      • Create and raise alerts
        • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/alerts-metric
        • Azure portal -> Monitor -> Alerts -> New alert rule
        • Metric alerts in Azure Monitor provide a way to get notified when one of your metrics cross a threshold. Metric alerts work on a range of multi-dimensional platform metrics, custom metrics, Application Insights standard and custom metrics.
        • az monitor metrics alert create -n {nameofthealert} -g {ResourceGroup} --scopes {VirtualMachineResourceID} --condition "avg Percentage CPU > 90" --description {descriptionofthealert}
        • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/alerts-classic-portal
        • Classic metric alerts in Azure Monitor provide a way to get notified when one of your metrics cross a threshold. Classic metric alerts is an older functionality that allows for alerting only on non-dimensional metrics. There is an existing newer functionality called Metric alerts which has improved functionality over classic metric alerts.
        • In the portal, locate the resource that you want to monitor, and then select it. In the MONITORING section, select Alerts (Classic).
        • az monitor alert create --name <alert name> --resource-group <group name> --action email <email1 email2 ...> --action webhook <URI> --target <target object ID> --condition "<METRIC> {>,>=,<,<=} <THRESHOLD> {avg,min,max,total,last} ##h##m##s"
        • After you create an alert, you can select it and do one of the following tasks:
          • View a graph that shows the metric threshold and the actual values from the previous day.
          • Edit or delete it.
          • Disable or Enable it if you want to temporarily stop or resume receiving notifications for that alert.
      • Analyze alerts across subscription
      • Analyze metrics across subscription
      • Create action groups
        • https://docs.microsoft.com/en-us/azure/azure-monitor/platform/action-groups
        • An action group is a collection of notification preferences defined by the owner of an Azure subscription. Azure Monitor and Service Health alerts use action groups to notify users that an alert has been triggered. Various alerts may use the same action group or different action groups depending on the user's requirements.
        • Email / SMS / Push / Voice / Function / LogicApp / Webhook / ITSM / Runbook
      • Monitor for unused resources
        • https://docs.microsoft.com/en-us/azure/advisor/advisor-overview
        • Azure Advisor is a service that, among other things, identifies virtual machines with low utilization from a CPU or network usage standpoint. From there, you can decide to either shut down or resize the machine based on the estimated cost to continue running the machines. Advisor also provides recommendations for reserved instance purchases. The recommendations are based on your last 30 days of virtual machine usage. When acted on, the recommendations can help you reduce your spending.
      • Monitor spend
      • Report on spend
      • Utilize Log Search query functions
      • View alerts in Log Analytics
    • Create and configure storage accounts
      • Configure network access to the storage account
        • https://docs.microsoft.com/en-us/azure/storage/common/storage-network-security
        • Configure storage accounts to deny access to traffic from all networks (including internet traffic) by default. Then grant access to traffic from specific VNets. This configuration enables you to build a secure network boundary for your applications. You can also grant access to public internet IP address ranges, enabling connections from specific internet or on-premises clients.
        • When network rules are configured, only applications requesting data from over the specified set of networks can access a storage account.
        • Network rules are enforced on all network protocols to Azure storage, including REST and SMB. To access the data with tools like Azure portal, Storage Explorer, and AZCopy, explicit network rules are required.
        • Virtual machine disk traffic (including mount and unmount operations, and disk IO) is not affected by network rules.
        • There are some cases where exceptions must be granted to enable full functionality. You can configure storage accounts with exceptions for trusted Microsoft services, and for access to storage analytics data.
        • az storage account update --resource-group "myresourcegroup" --name "mystorageaccount" --bypass Logging Metrics AzureServices
        • https://azure.microsoft.com/en-us/blog/virtual-network-service-endpoints-and-firewalls-for-azure-storage-now-generally-available/
        • To enable VNet protection, first enable service endpoints for storage in the VNet. Virtual Network Service Endpoints allow you to secure your critical Azure service resource to only your virtual network. Service endpoints also provide optimal routing for Azure traffic over the Azure backbone in scenarios where Internet traffic is routed through virtual appliances or on-premises.
        • On the storage account you can select to allow access to one or more VNets. You may also configure to allow access to one or more public IP ranges.
      • Create and configure storage account
      • Generate shared access signature
      • Install and use Azure Storage Explorer
      • Manage access keys
        • https://docs.microsoft.com/en-us/azure/storage/common/storage-dotnet-shared-access-signature-part-1
        • Account key and Shared access signatures (SAS). Your storage account includes both a primary and secondary access key, both of which grant administrative access to your account, and all resources within it. Exposing either of these keys opens your account to the possibility of malicious or negligent use. Shared access signatures provide a safe alternative that allows clients to read, write, and delete data in your storage account according to the permissions you've explicitly granted, and without need for an account key.
        • A shared access signature provides delegated access to resources in your storage account. With a SAS, you can grant clients access to resources in your storage account, without sharing your account keys. This is the key point of using shared access signatures in your applications--a SAS is a secure way to share your storage resources without compromising your account keys.
        • Your storage account key is similar to the root password for your storage account. Always be careful to protect your account key. Avoid distributing it to other users, hard-coding it, or saving it anywhere in plaintext that is accessible to others. Regenerate your account key using the Azure portal if you believe it may have been compromised.
        • A SAS gives you granular control over the type of access you grant to clients who have the SAS, including:
          • The interval over which the SAS is valid, including the start time and the expiry time.
          • The permissions granted by the SAS. For example, a SAS for a blob might grant read and write permissions to that blob, but not delete permissions.
          • An optional IP address or range of IP addresses from which Azure Storage will accept the SAS. For example, you might specify a range of IP addresses belonging to your organization.
          • The protocol over which Azure Storage will accept the SAS. You can use this optional parameter to restrict access to clients using HTTPS.
        • You can create two types of shared access signatures:
          • Service SAS. The service SAS delegates access to a resource in just one of the storage services: the Blob, Queue, Table, or File service.
          • Account SAS. The account SAS delegates access to resources in one or more of the storage services. All of the operations available via a service SAS are also available via an account SAS. Additionally, with the account SAS, you can delegate access to operations that apply to a given service, such as Get/Set Service Properties and Get Service Stats. You can also delegate access to read, write, and delete operations on blob containers, tables, queues, and file shares that are not permitted with a service SAS.
      • Monitor activity log by using Log Analytics
      • Implement Azure storage replication
    • Create and configure a Virtual Machine (VM) for Windows and Linux
      • Configure high availability
        • https://docs.microsoft.com/en-us/azure/virtual-machines/linux/manage-availability
        • Protects against: Unplanned Hardware Maintenance Event (Live Migration pauses for short time), An Unexpected Downtime (reboot, loss of the temporary drive), Planned Maintenance events (performed without any impact - sometimes updates require a planned reboot of VM in the suitable time window)
        • Recommended high availability best practices
          • Configure multiple virtual machines in an availability set for redundancy Group two or more virtual machines in an availability set. -> ensures that at least one virtual machine is available and meets the 99.95% SLA. Avoid leaving a single instance virtual machine in an availability set by itself. Each VM in availability set is assigned an update domain (five by default) and a fault domain (2-3). The order of update domains being rebooted may not proceed sequentially during planned maintenance, but only one update domain is rebooted at a time. Fault domains define the group of virtual machines that share a common power source and network switch. Default, the virtual machines from availability set are separated across up to 2-3 fault domains.
          • Use managed disks for VMs in an availability set Managed disks better reliability for Availability Sets. Ensuring that the disks of VMs in an Availability Set are isolated from each other. Automatically placing the disks in different storage fault domains (storage clusters) and aligning them with the VM fault domain.
          • For unmanaged disks
            • Keep all disks (OS and data) associated with a VM in the same storage account.
            • Review the limits on the number of unmanaged disks in a Storage account (performance reasons).
            • Use separate storage account for each VM in an Availability Set
          • Use scheduled events to proactively respond to VM impacting events VM is notified about upcoming maintenance events that can impact VM (requires subscription of events from inside of VM). Customers can use the event to perform tasks prior to the maintenance, such as saving state, failing over to the secondary, and so on. After you complete your logic for gracefully handling the maintenance event, you can approve the outstanding scheduled event to allow the platform to proceed with maintenance.
          • Configure each application tier into separate availability sets If you place two different tiers in the same availability set, all virtual machines in the same application tier can be rebooted at once. By configuring at least two virtual machines in an availability set for each tier, you guarantee that at least one virtual machine in each tier is available.
          • Combine a load balancer with availability sets Placing multiple virtual machines of the same tier under the same load balancer and availability set enables traffic to be continuously served by at least one instance.
          • Use availability zones to protect from datacenter level failures Availability zones, are alternative to availability sets. An Availability Zone is a physically separate zone within an Azure region. Three Availability Zones per supported region. Each Availability Zone has a distinct power source, network, and cooling. By architecting your solutions to use replicated VMs in zones, you can protect your apps and data from the loss of a datacenter. If one zone is compromised, then replicated apps and data are instantly available in another zone. There is no additional cost for virtual machines deployed in an Availability Zone. 99.99% VM uptime SLA is offered when two or more VMs are deployed across two or more Availability Zones within an Azure region. for i in `seq 1 3`; do az vm create --resource-group myResourceGroupSLB --name myVM$i --nics myNic$i --image UbuntuLTS --generate-ssh-keys --zone $i --custom-data cloud-init.txt az storage account create -n <accountname> -g <resourcegroup> -l <region> –sku Standard_ZRS –kind StorageV2
      • Configure monitoring, networking, storage, and virtual machine size
        • https://docs.microsoft.com/en-us/azure/virtual-machines/linux/tutorial-monitoring
        • You can enable boot diagnostics, performance metrics and manage package updates
        • Boot diagnostic captures boot output and stores it in Azure storage - troubleshoot VM boot issues
        • View boot diagnostic az vm boot-diagnostics get-boot-log --resource-group myResourceGroupMonitor --name myVM
        • VM Metrics are automatically collected for the host and can be viewed in the Azure portal.
        • To see more granular and VM-specific metrics, you need to install the Azure diagnostics extension on the VM. Enable guest-level monitoring in Azure portal. You can view these performance metrics and create alerts based on how the VM performs.
        • Update management allows you to manage updates and patches for your Azure VMs. Directly from your VM, you can quickly assess the status of available updates, schedule installation of required updates, and review deployment results to verify updates were applied successfully to the VM.
        • You can collect and view inventory for software, files, Linux daemons, Windows Services, and Windows registry keys on your computers. Tracking the configurations of your machines can help you pinpoint operational issues across your environment and better understand the state of your machines.
        • You can do more advanced monitoring of your VM by using a solution like Azure Monitor for VMs.
        • https://docs.microsoft.com/en-us/azure/virtual-machines/linux/network-overview
        • VM can have multiple NICs, and can be added or removed through the lifecycle of a VM.
        • Public / Private IP Address / Static / Dynamic
        • VNET / Subnet / NSG / LB
        • https://docs.microsoft.com/en-us/azure/virtual-machines/linux/tutorial-manage-disks
        • Operating system disk - Disk caching configuration optimized for OS performance. Because of this the OS disk should not be used for applications or data.
        • Temporary disk - SSD of the VM host. Highly performant may be used for temporary data processing. Data can be lost.
        • Datadisk can be added
        • Standard disk and Premium disk
        • az vm create --resource-group myResourceGroupDisk --name myVM --image UbuntuLTS --size Standard_DS2_v2 --generate-ssh-keys --data-disk-sizes-gb 128 128
        • The operating system needs to be configured to use additional disks
        • You can take a disk snapshot. Read only, point-in-time copy of the disk to quickly save the state of a VM before configuration changes. VM can be restored using a snapshot. Snapshot is taken of each disk independently.
        • az snapshot create --resource-group myResourceGroupDisk --source "$osdiskid" --name osDisk-backup
        • https://docs.microsoft.com/en-us/azure/virtual-machines/linux/tutorial-manage-vm#understand-vm-sizes
        • az vm list-sizes --location eastus
        • az vm create --resource-group myResourceGroupVM --name myVM3 --image UbuntuLTS --size Standard_F4s --generate-ssh-keys
      • Deploy and configure scale sets
        • https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/
        • Let you create and manage a group of identical, load balanced, and autoscaling VMs.
        • Can scale VMs in the scale set manually, or rules to autoscale on resource usage like CPU, memory or network traffic.
        • https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/quick-create-portal
        • Azure portal -> Create Virtual machine scale set -> Name; OS Type; Resource Group; User Name and Credentials or SSH Keys; Location; Instances count and VM size
        • Load balancer is created. NAT rules are used for remote connectivity such as RDP or SSH. E.g. VM1 104.42.1.19:50001, VM2 104.42.1.19:50002
        • az vmss create --resource-group myResourceGroup --name myScaleSol tcp
        • az monitor autoscale create --resource-group myResourceGroup --resource myScaleSet --resource-type Microsoft.Compute/virtualMachineScaleSets --name autoscale --min-count 2 --max-count 10 --count 2
        • az monitor autoscale rule create --resource-group myResourceGroup --autoscale-name autoscale --condition "Percentage CPU > 70 avg 5m" --scale out 3
        • az monitor autoscale rule create --resource-group myResourceGroup --autoscale-name autoscale --condition "Percentage CPU < 30 avg 5m" --scale in 1
        • Zone-redundant scale set az vmss create --resource-group myResourceGroup --name myScaleSet --image UbuntuLTS --upgrade-policy-mode automatic --admin-username azureuser --generate-ssh-keys --zones 1 2 3
        • For PowerShell use cmdlets New-AzVmss, Add-AzVmssExtension
    • Automate deployment of Virtual Machines (VMs)
    • Create connectivity between virtual networks
      • Create and configure VNET peering
        • TODO
      • Create and configure VNET to VNET
        • TODO
      • Verify virtual network connectivity
        • TODO
      • Create virtual network gateway
        • TODO
    • Implement and manage virtual networking
      • Configure private and public IP addresses, network routes, network interface, subnets, and virtual network
        • TODO
    • Manage Azure Active Directory (AD)
    • Implement and manage hybrid identities