Azure Administrator (AZ-104) Study Path

# Azure Administrator (AZ-104) Study Path ## Introduction The Azure Administrator (AZ-104) certification has become the industry standard for professionals managing cloud infrastructure on Microsoft Azure. This certification validates your ability to implement, manage, and monitor Azure environments that span storage, compute, networking, and security services. Unlike theoretical cloud certifications, AZ-104 emphasizes hands-on administration of real production environments, making it essential for anyone pursuing a cloud career in enterprise settings. This comprehensive study path breaks down the eight major knowledge domains tested on the exam into digestible sections. Whether you're starting your cloud journey or transitioning from on-premises administration, this guide provides the foundational knowledge, practical examples, interview preparation, and troubleshooting scenarios you'll encounter both in the exam and in real-world Azure administration. ## Virtual Machines: Creation, Sizing, Networking, Storage Virtual Machines form the backbone of most Azure deployments. Understanding VM creation, right-sizing, network configuration, and storage attachment is fundamental to Azure administration. ### VM Creation and Prerequisites Before creating a virtual machine in Azure, you need several prerequisites in place. First, you'll need an Azure subscription with sufficient quota. Second, you'll need a resource group to contain your VM and related resources. Third, you'll need a virtual network (VNet) where the VM will reside, and finally, a subnet within that VNet for IP address assignment. The creation process can happen through the Azure Portal (graphical interface), Azure CLI (command-line), PowerShell scripts, or Infrastructure-as-Code tools like Terraform. Each method has advantages. The Portal suits exploratory work and learning. PowerShell and CLI enable automation and scripting. Infrastructure-as-Code tools like Terraform allow version control and repeatable deployments across environments. When creating a VM, you'll specify the operating system image. Azure offers pre-configured images for Windows Server, various Linux distributions, and marketplace images from third-party vendors. These images come pre-loaded with software, drivers, and configurations, reducing setup time significantly. ### VM Sizing and Performance Considerations Choosing the correct VM size is critical for both performance and cost. Azure categorizes VM sizes into several families: General Purpose (balanced compute, memory, networking), Compute Optimized (high CPU-to-memory ratio), Memory Optimized (high memory-to-CPU ratio), Storage Optimized (high disk throughput and I/O), and GPU-equipped sizes for specialized workloads. A real-world example illustrates this choice clearly. An e-commerce company running web servers would likely choose General Purpose sizes like Standard_D2s_v3. These provide balanced resources for handling web requests. However, a data analytics team processing large datasets would benefit from Memory Optimized sizes like Standard_E4s_v3 or larger, which provide significantly more RAM for in-memory processing. Azure allows resizing VMs, but with important constraints. You can only resize to sizes supported by the current hardware cluster. If you need a size not available, you must deallocate the VM (stopping it and releasing hardware resources), move it to a different cluster, then resize. This operation causes downtime. Planning VM sizing correctly from the start minimizes disruption. ### VM Networking Configuration Every VM requires a network interface card (NIC) for connectivity. When you create a VM, Azure automatically creates a NIC and assigns it to a subnet within your chosen VNet. The NIC receives a private IP address from the subnet's address space. For external connectivity, you typically assign a public IP address to the VM's NIC. Public IPs allow inbound traffic from the internet. However, public IPs incur additional charges and present security risks. A more secure pattern involves placing VMs in private subnets without public IPs, then using Azure Bastion for remote administrative access or Application Gateway/Load Balancer for user traffic. Network security groups (NSGs) control traffic flow to VMs. NSGs contain inbound and outbound security rules that filter traffic based on source, destination, port, and protocol. A common mistake is creating overly permissive NSGs (allowing all inbound traffic on all ports) for convenience. This violates the principle of least privilege. Instead, explicitly allow only necessary traffic. For example, allow RDP (port 3389) only from your corporate IP range, not from the internet. VM NICs can have multiple IP configurations, allowing a single VM to host multiple identities or services. Enterprise scenarios include web servers requiring multiple SSL certificates or database servers supporting multiple databases. You can assign multiple public IPs or keep additional private IPs for internal routing. ### Storage Attachment and Management Azure VMs require at least one disk for the operating system. This OS disk comes from your chosen image. Additionally, you can attach data disks for application files, databases, and user data. This separation of OS and data disks is a best practice, allowing independent scaling and backup strategies. Azure offers two managed disk types: Standard HDD (suited for non-critical workloads, development/testing, and infrequent access patterns) and Premium SSD (suited for production workloads requiring consistent low latency and high throughput). Within Premium storage, Azure further offers Premium SSD v2 for the most demanding I/O-intensive applications. Disk sizing requires understanding both capacity needs and performance requirements. Azure Premium disks include defined IOPS (input/output operations per second) and throughput (MB/s) based on disk size. A P4 Premium disk offers 120 IOPS and 25 MB/s throughput, while a P80 offers 20,000 IOPS and 900 MB/s throughput. Applications with high transactional requirements (databases) need high IOPS disks. Applications with sequential access patterns (streaming, analytics) prioritize throughput. Caching strategies on data disks significantly impact performance. Azure Premium disks support read caching, write caching, or none. Read caching suits read-heavy workloads like web servers. Write caching (Azure supports write-through on Premium disks) can accelerate write-heavy operations, though with considerations for data consistency and crash recovery. Managed disks automatically handle the underlying storage accounts, snapshots, and replication. Unmanaged disks, a legacy approach, require manual storage account management. New deployments should exclusively use managed disks. ## Azure Networking: VNets, Subnets, Route Tables, Load Balancers Networking forms the interconnection layer for all Azure resources. Understanding virtual networks, subnets, routing, and load balancing is essential for building scalable, secure Azure infrastructure. ### Virtual Networks and Subnets A Virtual Network (VNet) is your isolated network space within Azure. You define the IP address range (address space) when creating a VNet, typically using RFC 1918 private addresses. For example, 10.0.0.0/16 provides 65,536 addresses for your VNet. Within a VNet, you create subnets, which further partition the address space. Subnets serve multiple purposes: organizing resources logically, applying security policies at the subnet level through NSGs, and controlling routing. A common architectural pattern separates web tier, application tier, and database tier into separate subnets, allowing granular security controls. Subnets require careful CIDR (Classless Inter-Domain Routing) planning. You specify subnet size as a CIDR notation. A /24 subnet within 10.0.0.0/16 (such as 10.0.1.0/24) provides 256 addresses, but Azure reserves the first (network address), second (gateway), second-to-last (reserved for Azure services), and last (broadcast) addresses. This leaves 252 usable IPs. For a subnet hosting 500 VMs, a /24 proves insufficient; you'd need a /23 or larger. Azure reserves the first address of each subnet for the network address and the second address (.1) for the gateway. These cannot be assigned to resources. Plan accordingly when designing address spaces. ### Route Tables and Custom Routing By default, subnets connect to each other within the same VNet. Route tables allow fine-grained control over traffic flow. Routes specify destinations (as CIDR ranges) and where traffic destined for that range should go (next hop). A route's next hop can be a Virtual Network Gateway (for routing to on-premises networks via VPN), a Network Virtual Appliance (a VM acting as a router), a virtual network peering connection, or simply the VNet itself. A real-world example: a company with two VNets in different regions wants to route traffic between them. VNet peering establishes the connection, and route tables direct traffic across the peering link. User-defined routes override Azure's default routes. This enables advanced scenarios like forcing traffic through a network appliance for inspection or logging. However, misconfigured routes cause connectivity problems. A common issue is creating a route that inadvertently excludes critical traffic. ### Load Balancers Azure Load Balancer distributes incoming traffic across multiple VMs, providing high availability and scalability. Azure offers two load balancer SKUs: Basic and Standard. Basic Load Balancers suit development and small workloads. Standard Load Balancers are required for production because they offer higher availability guarantees, better performance, higher connection limits, and support for availability zones. Load Balancers operate at Layer 4 (transport layer), making routing decisions based on protocol, source IP, source port, destination IP, and destination port. This differs from Application Gateway, which operates at Layer 7 (application layer) and can route based on URL paths or hostnames. The load balancer configuration includes frontend IPs (where traffic enters), backend pools (VMs receiving traffic), health probes (checking if VMs are healthy), and load balancing rules (defining traffic forwarding). Health probes automatically detect unhealthy VMs and remove them from the backend pool. If a probe fails repeatedly, traffic stops reaching that VM. This automatic failure detection is crucial for maintaining service availability. A practical scenario: an organization runs three web servers behind a load balancer. The load balancer has a health probe checking HTTP port 80. If one server becomes unresponsive, the probe fails, and the load balancer removes it from the pool. Users experience no interruption because traffic distributes across the two remaining healthy servers. ## Storage: Blobs, Files, Queues, Table Storage, and Accounts Azure Storage provides highly scalable, durable cloud storage for diverse data types and access patterns. ### Azure Storage Accounts A storage account is the top-level container for all Azure Storage services. Each storage account has a unique name globally (across all Azure subscriptions and regions) and provides endpoints for accessing blobs, files, queues, and tables. Storage accounts come in several types. Standard storage accounts support all storage services (blobs, files, queues, tables) and use HDD-backed storage. Premium storage accounts specialize in specific services: BlockBlobStorage for high-performance blob operations, FileStorage for high-performance file shares, and PageBlobStorage for virtual machine disks. Replication strategy affects both durability and cost. Locally Redundant Storage (LRS) replicates data three times within a single data center, providing protection against hardware failures but not regional disasters. Geo-Redundant Storage (GRS) replicates data to a secondary region hundreds of miles away, providing protection against regional disasters but with higher cost and potential latency. Zone-Redundant Storage (ZRS) replicates across multiple availability zones within a region, providing a middle ground for availability and cost. ### Blob Storage Blobs (Binary Large Objects) store unstructured data: documents, images, videos, backups, and logs. Blobs organize into containers (like folders) within storage accounts. Azure categorizes blobs into three types based on access patterns. Block blobs suit most scenarios: files uploaded in pieces and reassembled server-side. Append blobs optimize for append-only operations, ideal for logs. Page blobs support random read/write operations, used for VM disks and databases. Blob access tiers affect cost and performance. Hot tier provides immediate access but highest storage costs. Cool tier offers lower storage costs but adds access charges. Archive tier provides minimal storage costs but requires rehydration (moving data back to hot or cool tier) before access, taking hours. Archive tier suits long-term retention and compliance requirements. Lifecycle policies automatically move blobs between tiers based on age, reducing costs for aging data. For example, a policy might move blobs to cool tier after 30 days, then to archive after 90 days. ### Azure Files Azure Files provides fully managed file shares accessible via SMB (Server Message Block) protocol. Applications can mount Azure file shares like traditional network drives, enabling lift-and-shift scenarios for legacy applications. Azure Files support both standard and premium tiers. Standard file shares use shared storage infrastructure and suit general-purpose file sharing. Premium file shares use dedicated storage and provide guaranteed IOPS and throughput, suited for performance-critical applications. Azure Files integrates with Active Directory, allowing identity-based access control. Users or computers authenticate using their AD credentials, and permissions follow AD group memberships. This eliminates managing separate credentials for cloud file shares. ### Queues and Table Storage Azure Queue Storage implements a simple message queue. Applications publish messages to queues, and worker processes consume messages asynchronously. This decouples components, allowing independent scaling and fault tolerance. A real-world example: an order processing system receives orders through a web service, which posts order messages to a queue. Independent worker roles read messages and process orders. If order processing gets behind, you simply add more worker role instances without modifying the web service. Azure Table Storage provides NoSQL table storage suited for semi-structured data with flexible schemas. Unlike traditional databases with strict schemas, Table Storage allows different entities in the same table to have different properties. Each entity requires only a partition key and row key for uniqueness. Table Storage excels at scenarios requiring high throughput and simple queries. However, it lacks the complex querying and relationships that databases provide. Modern development increasingly favors Azure Cosmos DB over Table Storage, but Table Storage remains viable for simple scenarios and cost-conscious implementations. ## Identity and Access: Azure AD, RBAC, and Managed Identities Securing access to Azure resources requires proper identity management and access control. Azure Active Directory (Azure AD) and Role-Based Access Control (RBAC) form the security foundation. ### Azure Active Directory Azure AD (now called Microsoft Entra ID, though still commonly referenced as Azure AD) is Microsoft's cloud-based identity provider. Unlike on-premises Active Directory focused on managing computers and users on corporate networks, Azure AD specializes in cloud and hybrid scenarios. Azure AD supports several authentication methods: username/password, multi-factor authentication (MFA), passwordless sign-in using Windows Hello or security keys, and conditional access (requiring additional verification based on risk signals). Conditional Access policies evaluate login attempts and enforce requirements based on conditions. For example, a policy might require MFA for all sign-ins from outside the corporate network, or block sign-ins from countries your organization doesn't operate in. This provides security without requiring users to always provide MFA, which causes friction for internal network users. ### Role-Based Access Control (RBAC) RBAC determines what authenticated users can do with Azure resources. RBAC assignments consist of three components: a security principal (user, group, or service principal), a role (defining permissions), and a scope (subscription, resource group, or individual resource). Azure includes numerous built-in roles. Contributor grants full management access to a scope. Reader provides read-only access. Owner grants full access plus ability to manage access. Specialized roles like Virtual Machine Contributor or SQL DB Contributor limit permissions to specific resource types. A critical principle: assign roles at the appropriate scope. Assigning global administrator role is rarely needed; assign specific roles at the minimum required scope. For example, assign Virtual Machine Contributor for a resource group containing only VMs that user needs to manage, rather than assigning it to the subscription. Custom roles allow organizations to define precisely what permissions users need, following the principle of least privilege. However, managing custom roles introduces complexity. Most organizations succeed using built-in roles effectively rather than creating numerous custom variations. ### Managed Identities Managed Identities simplify how applications authenticate to other Azure services. Rather than storing credentials in application code or configuration files (a security risk and operational burden), applications use managed identities to request access tokens from Azure AD. Azure supports two types of managed identities. System-assigned identities are created and destroyed with the resource. Each resource has one system-assigned identity. User-assigned identities are standalone resources you create and manage, allowing multiple resources to share the same identity. A practical example: an App Service needs to read secrets from Key Vault. Rather than embedding storage account credentials in application code, you enable managed identity on the App Service, create an access policy in Key Vault granting the App Service's managed identity read permissions, and the application retrieves secrets using the managed identity. This eliminates storing credentials in code, config files, or application startup. Managed identities work seamlessly across Azure services that support them: App Service, Functions, VMs, AKS, Logic Apps, and many others. This makes them the preferred authentication method for most cloud-native applications. ## Compute Services: App Service, Function Apps, and Container Instances Beyond VMs, Azure offers multiple compute services suited to different workload patterns. ### App Service App Service provides fully managed hosting for web applications, mobile app backends, and APIs. Developers focus on application code while Azure handles OS patching, security updates, capacity management, and load balancing. App Service runs on App Service Plans, which define the underlying compute resources. Shared plans (free and basic tiers) run multiple customers' applications on shared hardware, suitable for low-traffic development sites. Dedicated plans (standard, premium, isolated) provide dedicated compute resources, supporting production workloads

🎯 Interview Q&A

Q: What are the key differences between the concepts discussed?

A: Review the detailed sections above for comprehensive comparisons.

Q: How can these concepts be implemented in production?

A: See the best practices and real-world examples throughout this article.

❓ Frequently Asked Questions

What is the best approach for implementation?

Start with the foundational concepts, understand the architecture, and follow the best practices outlined in each section.

How do I troubleshoot common issues?

Refer to the troubleshooting scenarios section below for detailed diagnosis and resolution steps.

🔧 Troubleshooting Scenarios

Scenario: Common Issue Detection

Problem: Systems not responding as expected.

Root Cause: Configuration mismatch or missing prerequisites.

Solution: Verify all settings against documentation and enable comprehensive logging.

Scenario: Performance Degradation

Problem: Slow response times or high resource utilization.

Root Cause: Insufficient capacity or suboptimal configuration.

Solution: Review capacity planning and implement performance optimization techniques.