AZ-104 — Example Quiz

Virtual Machine Contributor scoped to the resource group gives exactly the permissions needed — manage VMs in that group only. Subscription-level Contributor is too broad. Owner is too permissive (includes role assignment). Global Administrator is an Azure AD role, not an Azure RBAC role.

Every virtual network requires an address space (e.g. 10.0.0.0/16) and at least one subnet. NSGs, VPN gateways, and public IPs are optional and can be added later as needed.

Azure Storage Service Encryption (SSE) encrypts all data at rest by default using Microsoft-managed keys. No action is required to enable it. You can optionally switch to customer-managed keys via Key Vault for greater control, but the default already meets the requirement. HTTPS-only protects data in transit, not at rest.

NSGs filter traffic using security rules. An inbound rule allowing TCP 443 from the internet (source: Internet or Any) permits HTTPS traffic to reach the VM. A user-defined route changes routing behaviour. A service endpoint secures access to PaaS services. Application security groups help group VMs logically within NSG rules but don't create the allow rule themselves.

RBAC uses scope inheritance. A role assigned at a management group flows down to subscriptions, then to resource groups, then to individual resources. This is why you should assign roles at the narrowest scope necessary — assigning Contributor at the subscription level gives access to every resource group and resource in it.

To resize an OS disk, you must first stop (deallocate) the VM. Then you can increase the disk size through the portal, CLI, or PowerShell. After restarting, you may need to expand the partition within the OS. You cannot shrink a disk — only increase it. The temporary disk is ephemeral and not suitable for persistent data.

NSG rules support IP addresses/CIDR ranges, application security groups (logical groupings of VMs), and service tags (predefined labels like Internet, AzureLoadBalancer, VirtualNetwork). Azure AD groups and subscription IDs cannot be used in NSG rules — RBAC and NSGs are separate systems.

ARM templates and Bicep are declarative and idempotent by design — you define the desired state and Azure ensures it matches, whether you run the deployment once or ten times. Imperative CLI or PowerShell scripts would need custom logic to check for existing resources before creating them. The portal is manual and not repeatable.

AzCopy is a command-line tool optimised for high-performance bulk transfers to and from Azure Storage. It supports parallel transfers, resumable copies, and can saturate your network bandwidth. Storage Explorer uses AzCopy under the hood but adds GUI overhead. Portal upload is impractical for 2 TB. File Sync is designed for ongoing synchronisation, not one-time bulk migration.

The storage account firewall lets you restrict access to specific virtual networks via service endpoints or private endpoints, and set the default action to Deny. This blocks all access except from the allowed networks. SAS tokens can restrict by IP but don't block the public endpoint entirely. HTTPS-only and Azure AD authentication don't control network access.

First ensure users have registered MFA methods (otherwise they'll be locked out). Then create the Conditional Access policy, configure it to require MFA as a grant control, and finally test with a member of the targeted group.

Azure Monitor alert rules let you set metric-based conditions (e.g. CPU > 90% for 5 minutes) scoped to a resource group, and trigger actions like sending email via an action group. Advisor gives recommendations, not real-time alerts. Service Health tracks Azure platform issues. Activity log alerts trigger on management operations (create, delete), not performance metrics.

Azure Blob Storage has three access tiers: Hot (frequent access, higher storage cost, lower access cost), Cool (infrequent access, lower storage cost, higher access cost), and Archive (rare access, lowest storage cost, highest retrieval cost and latency). "Standard" and "Premium" describe performance tiers of the storage account, not blob access tiers. "Warm" is not an Azure tier.

NSGs can be associated with subnets or individual network interfaces — not with the virtual network itself. To apply an NSG to all traffic in a VNet, you must associate it with each subnet within that VNet.

Scale out (horizontal scaling) adds more instances of your app. An autoscale rule on the App Service plan triggers this based on metrics like CPU usage. Scale up (vertical scaling) increases the size of each instance but doesn't add more. Load Balancer and Traffic Manager distribute traffic but don't control instance count.

A SAS token provides time-limited, scoped access to specific resources without exposing the account keys. You can restrict it to a single container, set it to read-only, and set a 24-hour expiry. Sharing account keys gives full access. Azure AD roles and managed identities are better for long-term access from trusted applications, not temporary third-party access.

By default, Azure virtual networks are isolated — VMs in different VNets cannot communicate. Virtual network peering connects two VNets and allows traffic to flow between them. Public IPs would allow internet communication but not private VNet-to-VNet traffic. NSG rules could block traffic, but without peering there is no path for traffic at all. Different Azure AD tenants don't prevent network connectivity.

The key difference between Owner and Contributor is that Owner can manage access (assign RBAC roles) and manage policy, while Contributor cannot. Both roles can create, modify, and delete resources like VMs, resource groups, and ARM deployments.

Azure Policy enforces rules across resources — you can create a policy that restricts allowed VM sizes to specific SKUs. This prevents anyone from deploying non-compliant VMs, regardless of their RBAC role. RBAC controls who can do what, but cannot restrict which SKU sizes are used. Advisor makes recommendations but doesn't enforce them.

First create a dedicated gateway subnet (must be named GatewaySubnet) in the VNet. Then create the virtual network gateway, which deploys into that subnet (this takes 20-45 minutes). Then create the connection resource linking the Azure gateway to the on-premises local network gateway using a shared key. Finally verify the connection status.