Cloud Service Types for MS-900

Cloud service types define the level of abstraction and control a customer has over cloud resources. They exist because different workloads require different trade-offs between control, flexibility, and management overhead. The cloud provider offers varying degrees of responsibility: in some models you manage everything above the hypervisor; in others you only manage application data. The three fundamental models are IaaS, PaaS, and SaaS, standardized by NIST SP 800-145. Microsoft 365 is primarily SaaS, but Azure services span IaaS and PaaS. The MS-900 exam expects you to classify services correctly and map them to business needs.

The shared responsibility model is the core framework for understanding cloud service types. It defines which security and management tasks are handled by the provider versus the customer. The model varies by service type:

Key exam point: The customer is ALWAYS responsible for their own data and identities, regardless of service type. This is a common trick — questions may imply the provider secures your data in SaaS, but responsibility is shared.

IaaS provides virtualized computing resources over the internet. You get virtual machines (VMs), virtual networks, and storage, but you must install and configure the OS, middleware, and applications. Azure Virtual Machines is the primary IaaS offering. Key characteristics: - Full control over the OS and applications. - Pay-as-you-go for compute hours, storage, and networking. - Scalability via manual scaling or VM scale sets. - Responsibility: Customer handles OS patches, application updates, security software, and network configuration.

Common exam scenarios: lift-and-shift migration of legacy apps, running custom software with specific OS requirements, or needing full administrative access.

PaaS delivers a managed platform for developing, running, and managing applications without the complexity of building and maintaining the underlying infrastructure. Azure App Service is a prime example. Key characteristics: - Managed runtime: The provider handles OS updates, patching, and scaling. - Built-in services: Load balancing, auto-scaling, monitoring, and CI/CD integration. - Developer focus: You only deploy code; no server management. - Responsibility: Provider manages OS, runtime, middleware; customer manages application code and data.

Common exam scenarios: web applications, APIs, mobile backends, and containerized apps (Azure Kubernetes Service is a PaaS for containers).

SaaS delivers fully functional software applications over the internet. Microsoft 365 is the flagship SaaS suite. Key characteristics: - Zero infrastructure management: Everything from servers to application code is managed by the provider. - Subscription-based: Monthly or annual per-user licensing. - Multi-tenant architecture: One application instance serves many customers, with data isolation. - Responsibility: Customer manages data, user accounts, and compliance; provider manages availability, security, and updates.

Common exam scenarios: Email (Exchange Online), collaboration (Teams, SharePoint), productivity (Office apps).

Microsoft 365 is predominantly SaaS, but it integrates with Azure services that are IaaS or PaaS: - Azure AD (now Microsoft Entra ID): A PaaS identity service that underpins M365 authentication. - Exchange Online Protection: SaaS email filtering, but advanced threat protection may use Azure functions. - SharePoint Online: SaaS document management, but you can extend it with Azure Logic Apps (PaaS).

Exam questions often present a scenario where you must choose between IaaS, PaaS, or SaaS for a workload. Key decision factors: - Control vs. convenience: More control = more management overhead. - Existing skills: If your team knows OS administration, IaaS may be easier; if they are developers, PaaS suits better. - Compliance: Some regulations require you to control the OS; IaaS is necessary.

While service types themselves don't have timers, specific implementations do: - Azure VM default OS disk: 127 GB (managed disk) - Azure App Service auto-scale: Default cool-down period of 5 minutes between scale operations. - Azure Functions timeout: Default 5 minutes for consumption plan; configurable up to 10 minutes (or unlimited on Premium plan). - Microsoft 365 user license assignment: Typically takes 1-30 minutes to propagate across all services.

For Azure IaaS/PaaS, you can use Azure CLI or PowerShell to verify service type and configuration:

# List all VMs (IaaS)
az vm list --output table

# List App Service plans (PaaS)
az appservice plan list --output table

# Check if a VM is running (IaaS)
az vm show --name MyVM --resource-group MyRG --query "powerState"

# Get Azure Functions (FaaS)
az functionapp list --output table

For Microsoft 365 SaaS, you can use the Microsoft 365 admin center or PowerShell:

# Get licensed users (SaaS)
Get-MsolUser -All | Where-Object {$_.isLicensed -eq $true}

# Check service health
Get-MsolCompanyInformation

Service types are not isolated; they often combine in a single solution: - Hybrid deployment: A company might use Office 365 (SaaS) for email, Azure VMs (IaaS) for legacy apps, and Azure SQL Database (PaaS) for new apps. - Serverless architectures: Use Azure Functions (FaaS) to process events from Office 365 (SaaS) via webhooks. - Virtual desktop: Azure Virtual Desktop (DaaS) runs on Azure VMs (IaaS) but is managed as a service.

Exam trap: A question may describe a scenario where you need to migrate an on-premises app that requires full OS control. The correct answer is IaaS (Azure VM). Candidates often choose PaaS because it's "managed," but PaaS does not give OS access.

A large insurance company has a custom claims processing application built on Windows Server 2012 with a SQL Server 2014 backend. The app requires full OS access for security scanning agents and a specific .NET Framework version not supported in Azure App Service. The company decides to migrate using IaaS: they create Azure VMs running Windows Server 2012 R2 and SQL Server 2014. They use Azure Migrate to assess compatibility and Azure Site Recovery for replication. In production, they deploy two VMs in an availability set for high availability. The OS and SQL Server are managed by their server team, who apply monthly patches via Azure Update Management. Performance considerations: they choose D-series VMs (general purpose) with premium SSDs for SQL data files. Common misconfiguration: forgetting to configure network security groups (NSGs) to restrict RDP access, leaving the VMs exposed. They also learned to set up alerts for CPU > 80% to trigger scale-out of additional VMs.

A retail company builds a new e-commerce platform using Node.js and MongoDB. The development team wants to focus on code, not servers. They choose PaaS: Azure App Service for the web frontend and Azure Cosmos DB (MongoDB API) for the database. They use Azure DevOps for CI/CD, deploying directly to App Service slots for staging and production. Auto-scaling is configured to increase instances from 2 to 10 based on CPU usage. The provider handles OS patching and runtime updates. In production, they monitor performance using Application Insights. A common pitfall: the app fails to handle connection pooling properly when scaling out, causing database connection exhaustion. They fixed it by using Cosmos DB's built-in connection pooling and setting App Service's connection limit appropriately. Cost is controlled by using reserved instances for App Service Premium plans.

A global consulting firm with 10,000 employees needs email, collaboration, and document management. They choose Microsoft 365 (SaaS) to eliminate on-premises Exchange and SharePoint servers. The IT team focuses on identity management (Azure AD Connect for hybrid identity), data governance (retention policies, DLP), and user training. They deploy Microsoft Teams for communication and OneDrive for personal file storage. Key challenges: ensuring network bandwidth for Teams video calls (they use QoS policies) and managing compliance with GDPR (they use Microsoft Purview). Misconfiguration example: an admin accidentally set a retention policy to delete all emails older than 30 days, causing data loss. They recovered from backups and implemented role-based access control to limit retention policy changes. The SaaS model allows them to scale globally without managing any servers.