Microsoft Azure Fundamentals

❌ Incorrect. Review the explanation below.

Why 99.95% is right:
For Virtual Machines deployed across two or more instances in an Availability Set, Microsoft guarantees 99.95% uptime. Availability Sets protect against hardware failures and planned maintenance within a single datacenter by using Fault Domains and Update Domains.

→ Why the other options are wrong:

Option A: 99.99% = This is the SLA for VMs deployed across two or more Availability Zones in the same region — a higher SLA due to greater physical separation.

Option C: 99.90% = This is the SLA for a single VM using Premium SSD or Ultra Disk — lower than Availability Set.

Option D: 99.94% = This is an example of a Composite SLA result (Availability Set + SQL Database) — not a standalone VM SLA tier.

Azure VM SLA Cheat Sheet:

Quick Memory Tip 🧠
→ Availability Set = 99.95% | Availability Zones = 99.99%
→ "More separation = higher SLA!" 📶

Why the correct answer is right:
Azure Data Lake Analytics is an on-demand analytics job service that simplifies big data processing. It allows you to write queries to transform, process, and extract insights from massive datasets without managing any infrastructure. You only pay when your analytics jobs are running — making it cost-effective and scalable for data transformation workloads.

→ Why the other options are wrong:

Option B – Azure Virtual Machine Scale Sets: Scale Sets manage groups of load-balanced VMs for compute scaling. They are infrastructure tools — not data analytics or transformation services.

Option C – Azure Virtual Network: A VNet provides private networking within Azure. It has no data processing or analytics capabilities.

Option D – Azure App Service: App Service is a web application hosting platform. It is used to deploy and run web apps, not to transform data or generate analytics insights.

Quick Memory Tip 🧠
→ "Transform data + Insights = Azure Data Lake Analytics. Pay per job. No infrastructure to manage!"

Why the correct answer is right:
The Azure Basic support plan includes only billing and subscription management support, access to documentation, and community forums. It does NOT include any technical support from engineers via phone or email. To get phone or email access to technical support engineers, you need at minimum the Developer plan (email only) or Standard plan (email + phone).

→ Why the other options are wrong:

Option A – Yes: This is incorrect. Basic plan has zero technical engineer support. The company's requirement for phone or email support cannot be met with a Basic plan.

Quick Memory Tip 🧠
→ "Basic = No tech support. Need engineer help? Minimum = Developer (email) or Standard (phone + email)!"

You can easily search for custom solutions in the Azure Marketplace and even deploy these solutions onto Azure.
You can visit the Azure Marketplace via the following URL
https://azuremarketplace.microsoft.com/en-us/marketplace/
Option A is incorrect since there is no mention of the need of a scalable solution.
Option B is incorrect since this used to categorize resources.
Option D is incorrect since this used as a Platform as a service solution for web applications.

Why the correct answer is right:
Azure Files provides fully managed cloud file shares accessible via the SMB (Server Message Block) protocol — the same protocol used by Windows for network drives. Multiple Windows 10 computers can map the Azure file share as a network drive simultaneously, with both read and write access, just like a traditional on-premises file server.

→ Why the other options are wrong:

Option A – Blobs service: Azure Blob storage is for unstructured data (images, videos, backups) accessed via REST API or HTTP/HTTPS. It cannot be mapped as a network drive.

Option B – Azure SQL database: SQL Database is a relational database for structured data. It cannot function as a file share or network drive.

Option C – Virtual Machine Data disk: A VM data disk is a managed disk that can only be attached to one VM at a time. It cannot be shared across multiple Windows 10 computers as a network drive.

Quick Memory Tip 🧠
→ "Map a network drive = Azure Files (SMB). Multiple computers, shared access. Blob = API access only!"

❌ Incorrect. Review the explanation below.

❌ Incorrect. Review the explanation below.

High Availability is NOT a key characteristic of SLAs for Azure products and services.
Here’s a breakdown of the key characteristics:
o
Performance targets: SLAs often include guarantees about the performance of Azure services, such as response times or throughput.
o
Uptime: SLAs typically include commitments to the availability of Azure services, expressed as a percentage of annual uptime.
o
Service credits: If an Azure service fails to meet its SLA, Microsoft may provide service credits as compensation.
High Availability is a general term that can refer to various aspects of a service’s reliability. While it’s important for Azure services, it’s not specifically listed as a key characteristic of SLAs.
Reference:
(1) AZ-900 Guide: Core Cloud Services – Azure architecture and service …. https://www.azureguru.org/az-900-guide-core-cloud-services-azure-architecture-and-service-guarantees/. (2) Recommendations for defining reliability targets – Microsoft Azure Well …. https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics.

What is the Azure Hybrid Benefit?
The Azure Hybrid Benefit is a pricing offer that helps you maximise the value of your existing on-premises Windows Server and/or SQL Server licence investment while you are migrating to Azure. With it, eligible customers pay a reduced rate on Azure Virtual Machines (infrastructure as a service or IaaS) and a reduced rate on Azure SQL Database (platform as a service or PaaS) and SQL Server on Azure Virtual Machines (IaaS).
*Actual savings may vary based on region, instance type or usage.
Which products are eligible for the Azure Hybrid Benefit?
Windows Server Standard Edition with Software Assurance
Windows Server Datacenter edition with Software Assurance
SQL Server Enterprise Core with Software Assurance
SQL Server Enterprise Core with Software Assurance
Azure SQL Database
Note: Customers eligible for Azure Hybrid Benefit can use this benefit in Azure Dedicated Host (more details in Windows Server and SQL Server sections)
Who is eligible for this offer?
Azure Hybrid Benefit is available to customers who own eligible SQL Server and/or Windows Server licenses with active Software Assurance or the equivalent qualifying subscription licenses.
The offer is available in all Azure cloud regions.
For more info : https://azure.microsoft.com/en-in/pricing/hybrid-benefit/faq/

→ Why Azure Pipelines is right:
Azure Pipelines is a CI/CD (Continuous Integration / Continuous Deployment) automation service. It builds, tests, and deploys code automatically. It has no feature for assigning work items or tasks to individual developers — that's not its purpose.

→ Why the other options are wrong:

Option A: GitHub has lightweight project management features — including Issues and Projects — that allow task assignment to users.

Option B: Azure Boards is a full project management tool with Kanban boards, sprints, backlogs, and work items — specifically designed to assign tasks to individual developers.

Quick Memory Tip 🧠
→ Azure Pipelines = "Build and deploy — NOT a task manager!"
→ Task assignment = Azure Boards ✅ | GitHub ✅ | Azure Pipelines ❌

Why the correct answer is right:
Azure Firewall is a fully managed, stateful network security service that can be deployed centrally in a hub VNet and filter traffic across multiple spoke VNets and subscriptions via hub-spoke topology. You can create, enforce, and log application and network connectivity policies centrally — making it the ideal solution for enterprise-wide traffic filtering across multiple subscriptions.

→ Why the other options are wrong:

Option B – Application Security Group (ASG): ASGs allow you to group VMs logically and define NSG rules based on those groups. They operate within a single VNet and cannot span multiple subscriptions.

Option C – Azure DDoS Protection: DDoS Protection defends against large-scale volumetric attacks. It does not filter or control regular application or network traffic flows.

Option D – Network Security Group (NSG): NSGs apply allow/deny rules at the subnet or NIC level within a single VNet. They cannot centrally manage traffic filtering across multiple subscriptions and VNets.

Quick Memory Tip 🧠
→ "Azure Firewall = Central filtering across multiple VNets + subscriptions. NSG = Single VNet only. DDoS = Attack protection only."

→ Why Option C is right:
Each service serves a specific connectivity scenario. Service Endpoints extend VNet identity to Azure services. P2S is for individual remote users. S2S connects an entire on-premises network to Azure. ExpressRoute is the premium private, high-speed link that bypasses the public internet entirely.

→ Why the other options are wrong:

Options A, C, D: All incorrectly swap definitions — most commonly mixing up ExpressRoute with S2S VPN, and P2S with Service Endpoints.

Quick Memory Tip 🧠
→ P2S = One person, one computer | S2S = Office to Azure | ExpressRoute = Private highway, no internet | Service Endpoints = Azure-to-Azure secure access

Azure Synapse is a limitless analytics service that brings together enterprise data warehousing and Big Data analytics. It gives you the freedom to query data on your terms, using either serverless on-demand or provisioned resources—at scale. Azure Synapse brings these two worlds together with a unified experience to ingest, prepare, manage, and serve data for immediate BI and machine learning needs
Azure Synapse has four components:
Synapse SQL: Complete T-SQL based analytics – Generally AvailableSQL pool (pay per DWU provisioned)SQL on-demand (pay per TB processed) – (Preview)
Spark: Deeply integrated Apache Spark (Preview)
Data Integration: Hybrid data integration (Preview)
Studio: Unified user experience. (Preview)
For more info : https://docs.microsoft.com/en-us/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-overview-what-is

Why Azure Policy is right:
Azure Policy allows you to define rules that automatically enforce compliance across your environment. By creating a policy that specifies allowed VM SKU sizes, Azure will block non-compliant VMs from being deployed at creation time AND evaluate existing VMs. This ensures governance without manual oversight.

→ Why the other options are wrong:

Option A: Manual inspection is reactive, not preventative. It won't stop non-compliant VMs from being deployed — it only catches them after the fact.

Option B: Azure RBAC controls who can perform actions — not what resources they can create. RBAC cannot restrict VM SKU sizes; only Azure Policy can enforce that.

Quick Memory Tip 🧠
→ Enforce resource rules automatically = Azure Policy = "Set the rules, Azure does the enforcement!" 📏

Azure monitor is not a global service. Please check below URL for more details-
https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/configure-azure-monitor

Why 2 is right:
Microsoft Azure Germany consists of two physically isolated regions — Germany Central (Frankfurt) and Germany Northeast (Magdeburg). These regions are specifically designed to comply with German data privacy regulations (GDPR and German-specific laws), ensuring all customer data stays within Germany under German law governance.

→ Why the other options are wrong:

Options A, B, C: None of these are correct. Azure Germany has exactly 2 dedicated sovereign regions — not 1, 3, or 4.

Quick Memory Tip 🧠
→ Azure Germany = 2 regions = "One pair — Frankfurt + Magdeburg — for German data sovereignty!" 🇩🇪

❌ Incorrect. Review the explanation below.

Why Option D is right:
An Azure Region is a geographical area containing one or more datacenters that are in close proximity and networked together with a low-latency network. This ensures fast communication between datacenters within the same region. Azure currently has 60+ regions worldwide — not limited to countries with Microsoft offices.

→ Why the other options are wrong:

Option A: Azure regions exist on every continent and in many countries — not limited to Europe and the Americas only.

Option B: "No change needed" is wrong because the bracketed statement about subsidiary offices is factually incorrect.

Option C: "High-latency network" is completely wrong — Azure regions use low-latency connections between datacenters. High latency would defeat the purpose of having a regional cluster.

Quick Memory Tip 🧠
→ Azure Region = "One or more datacenters + low-latency network = fast, close, connected!" ⚡

❌ Incorrect. Review the explanation below.

References: https://azure.microsoft.com/en-us/blog/regulatory-compliance-dashboard-in-azure-security-center-now-available/

Why the correct answer is right:
Azure Repos is a set of version control tools within Azure DevOps that supports both Git (distributed version control) and TFVC (Team Foundation Version Control). Developers use it to store, share, and collaborate on code with features like pull requests, branch policies, and code review workflows — similar to GitHub.

→ Why the other options are wrong:

Option B – Azure DevTest Labs: DevTest Labs creates and manages VM environments for development and testing. It is not a version control or source code management tool.

Option C – Azure Storage: Azure Storage is a data storage service for files, blobs, queues, and tables. It has no version control or code management capabilities.

Option D – Azure Cosmos DB: Cosmos DB is a globally distributed NoSQL database. It stores application data — not source code or version history.

Quick Memory Tip 🧠
→ "Azure Repos = Version control for code (Git or TFVC). Think: Repos = Repository = Code storage with history!"

Azure policies can be used to define requirements for resource properties during deployment and for already existing resources. Azure Policy controls properties such as the types or locations of resources. Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements. In this question, we would create an Azure policy assigned to the resource group that denies the creation of virtual machines in the resource group. You could place a read-only lock on the resource group. However, that would prevent the creation of any resources in the resource group, not virtual machines only. Therefore, an Azure Policy is a better solution.
References: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-lock-resources

Why Option A is right:
Each service has a distinct role. DevOps Services is the full developer collaboration suite. App Service is a PaaS hosting platform. DevTest Labs spins up sandbox environments quickly. Logic Apps automates workflows without code. All four definitions are unique and precise.

→ Why the other options are wrong:

Options B, C, D: All shuffle the definitions incorrectly — most commonly swapping DevOps Services with App Service, or mixing DevTest Labs with Logic Apps.

Quick Memory Tip 🧠
→ DevOps = Pipelines + Git + Boards | App Service = Host web apps | DevTest = Test environments | Logic Apps = Automate workflows 🔄

❌ Incorrect. Review the explanation below.

Why Azure Policy is right:
Azure Policy can be scoped to a specific resource group and configured to deny the creation of specific resource types — like Virtual Machines. You apply a "Deny" effect policy on Microsoft.Compute/virtualMachines to myRG, and any attempt to create a VM there will be automatically blocked.

→ Why the other options are wrong:

Option A: Azure Role (RBAC) controls who can do things — not what resources can be created. RBAC cannot block a specific resource type from being deployed.

Option B: Azure Lock (Read-only or Delete) prevents modification or deletion of existing resources — it cannot block the creation of new resource types.

Option C: Tags are metadata labels for organization and cost tracking — they have zero enforcement capability and cannot block resource creation.

Quick Memory Tip 🧠
→ Block a resource TYPE from being created = Azure Policy
→ "Policy = What can be built. RBAC = Who can build it. Lock = Can't delete it!" 🧱

❌ Incorrect. Review the explanation below.

❌ Incorrect. Review the explanation below.

Why Option B is right:
Consumption-based pricing means you only pay for what you actually use. If your workload is sporadic or infrequent — running only a few hours a day or week — you avoid paying for idle time. Compare this to time-based pricing, where you pay regardless of whether the resource is being used.

→ Why the other options are wrong:

• Option A: Consumption-based is NOT always cheaper. For resources running 24/7, reserved or time-based pricing can be more cost-effective. The word "always" makes this wrong.
• Option C: Consumption-based pricing is actually harder to predict and understand because costs vary with usage. Time-based pricing is simpler.
• Option D: Cost prediction is easier with time-based or reserved pricing. Consumption-based pricing makes future cost estimation harder due to variable usage.

Quick Memory Tip 🧠
→ Consumption = "Only pay when you use it — perfect for light, irregular workloads!" 💰

Why the correct answer is right:
Azure supports moving resources — including Virtual Machines — between subscriptions using the Azure portal, Azure CLI, or PowerShell via the Move-AzResource command. Both the source and destination subscriptions must be associated with the same Microsoft Entra ID (Azure AD) tenant. The VM and its dependent resources (disk, NIC, VNet) need to be moved together.

→ Why the other options are wrong:

Option B – No: This is incorrect. Azure explicitly supports cross-subscription resource moves. This is a supported and documented feature in Azure Resource Manager.

Quick Memory Tip 🧠
→ "Azure VMs CAN move between subscriptions — as long as both subscriptions are in the same Entra ID tenant!"

Why Multiplying is right:
A Composite SLA is calculated by multiplying the individual SLAs together. For example:

• App Service: 99.95%
• Azure SQL Database: 99.99%
• Composite SLA = 99.95% × 99.99% ≈ 99.94%

The result is always lower than either individual SLA because any single failure brings the whole application down.

→ Why the other options are wrong:

Option A: Taking the lowest SLA would underestimate reliability — it ignores the probability calculation.

Option B: Taking the highest SLA would overestimate reliability — it's mathematically incorrect for dependent services.

Option C: Averaging the SLAs is also incorrect and not how Microsoft calculates Composite SLA.

Composite SLA Formula:

Composite SLA = SLA₁ × SLA₂ × SLA₃ …
"The more services you add, the lower your composite SLA becomes!"

Quick Memory Tip 🧠
→ Composite SLA = Multiply all individual SLAs = "More services = more risk = lower combined SLA!" 📉

Yes, this would give a cost breakdown for the resources being used in Azure.
An example is given below where you go to the Cost Analysis section in Cost Management.
For more information on Azure Cost Management, please visit the below URL

https://docs.microsoft.com/en-us/azure/cost-management/overview

Since this is clearly mentioned in the documentation, all other options are incorrect.
For more information on DDoS protection, please visit the below URL
https://docs.microsoft.com/en-us/azure/virtual-network/ddos-protection-overview

Since this is clearly mentioned in the documentation, all other options are incorrect

❌ Incorrect. Review the explanation below.

Why Monthly is right:
Azure billing cycles can be annual, quarterly, or monthly — but the minimum (shortest) billing interval is monthly. Even though Azure tracks usage daily and measures some services per second/minute, invoices are issued at minimum on a monthly basis. Azure Cost Management shows you daily cost breakdowns, but the billing invoice itself is monthly at minimum.

→ Why the other options are wrong:

• Option A: Weekly billing is not a supported Azure invoice frequency.
• Option B: Daily billing is not how Azure invoices work — daily is a cost tracking view, not an invoice cycle.
• Option D: Annual is a valid billing cycle, but it is not the minimum — monthly is the shortest cycle.

Quick Memory Tip 🧠
→ Azure billing minimum = Monthly = "Usage tracked daily, invoiced monthly!" 🗓️

Why XLS is right:
The Azure Pricing Calculator allows you to download your cost estimates in Excel (.XLS) format. This makes it easy to share estimates with stakeholders, model different scenarios, and refine cost projections using spreadsheet tools.

→ Why the other options are wrong:

Option A: JSON is used for APIs and configuration files — it is not a download format for cost estimates.

Option C: XML is used for data exchange — it is not supported by the Azure Pricing Calculator as a download format.

Option D: CSV is a common data format but is not the format available for downloading Azure cost estimates. Only XLS is supported.

Quick Memory Tip 🧠
→ Azure Pricing Calculator download = XLS (Excel) = "Spreadsheet format — great for sharing with management!" 📊

Why General Availability (GA) is right:
General Availability (GA) means a feature has completed evaluation, testing, and is now officially released for all Azure customers with full Microsoft support, SLAs, and production-readiness. It's the final stage in the Azure release cycle.

→ Why the other options are wrong:

Option A: Public Preview is still in the testing/evaluation phase — available to all customers, but NOT fully supported and NOT recommended for production workloads.

Option B: Private Preview is only for a limited, selected group of customers — it's the earliest, most restricted testing phase.

Option D: "General Preview" is not a valid Azure release stage — it doesn't exist in Microsoft's official release lifecycle.

Azure Release Cycle Summary:

Private Preview → Public Preview → General Availability (GA)
Limited users → All users (evaluation) → All users (production-ready ✅)

Quick Memory Tip 🧠
→ GA = "Graduation day — fully supported, production-ready, open to everyone!" 🎓

❌ Incorrect. Review the explanation below.

Why Option D is right:
The primary benefit of the Public Cloud is its shared model — Microsoft builds and operates massive infrastructure, and multiple organizations each consume a portion of it. This allows customers to pay only for what they use (pay-as-you-go) without investing in their own physical infrastructure.

→ Why the other options are wrong:

Option A: The Public Cloud is NOT owned by the general public — it's owned by private corporations like Microsoft (Azure) and Amazon (AWS).

Option B: The Public Cloud is not a crowd-sourcing model — customers don't contribute to or enhance the cloud infrastructure; they simply consume services.

Option C: Public Cloud resources are NOT freely accessible — customers pay for what they use, and access is strictly managed and authenticated.

Quick Memory Tip 🧠
→ Public Cloud = "Microsoft owns it, many companies share it, each pays for their slice!" ☁️

Why the correct answer is right:
Each Azure DevOps tool has a distinct purpose: Repos = source code management (like GitHub). Boards = work item and sprint tracking (like Jira). Artifacts = package management for build outputs (like NuGet/npm feeds). Test Plans = manual and automated testing in CI/CD pipelines. Together they form a complete DevOps toolchain.

→ Why the other options are wrong:

Option A: Incorrectly maps Repos to "agile PM" (that's Boards) and Boards to "source code" (that's Repos) — swapped definitions.

Option C: Incorrectly assigns Artifacts to "source-code repository" — Artifacts hosts build packages, not raw source code.

Option D: Assigns Repos to "automated test tool" — that belongs to Test Plans.

Quick Memory Tip 🧠
→ "Repos = Code. Boards = Tasks. Artifacts = Packages. Test Plans = Testing. Remember: R-B-A-T!"

❌ Incorrect. Review the explanation below.

❌ Incorrect. Review the explanation below.

For products governed by the Modern Lifecycle Policy, Microsoft will provide a minimum of 12 months’ notification prior to ending support if no successor product or service is offered—excluding free services or preview releases.
For more info : https://support.microsoft.com/en-us/help/30881/modern-lifecycle-policy
Hence option B is correct and rest all options are not valid in regard to Modern Lifecycle Policy for Azure services.

❌ Incorrect. Review the explanation below.

Why Metadata is right:
Azure Tags store metadata about resources. A tag is a name-value pair — for example, Environment: Production or Department: Finance. This metadata helps with organizing, filtering, and billing analysis across your Azure resources. Tags don't enforce rules or grant permissions — they simply describe and label.

→ Why the other options are wrong:

Option B: Role defines what actions a user can perform on a resource (RBAC) — not what a tag is.

Option C: Permission is the outcome of a role assignment — it grants or denies access to resources.

Option D: Policy enforces rules and standards on resources — it's not what a tag represents.

Quick Memory Tip 🧠
→ Tags = Name + Value = Metadata = "Labels that describe your resources!" 🏷️

Why Update Domain is right:
Update Domains are part of an Availability Set configuration. They ensure that when Azure performs planned maintenance (OS patching, hardware updates), VMs are updated in sequence — not all at once. Each Update Domain is updated one at a time, preventing simultaneous downtime across your application.

→ Why the other options are wrong:

Option A: Fault Domains protect against unplanned hardware failures — like a rack power failure or a network switch going down. They separate VMs by physical rack, not by update sequence.

Option B: Availability Zones are physically separate datacenters within a region — they protect against full datacenter failures but don't manage update sequencing.

Option C: Load Balancing distributes incoming traffic across healthy instances — it doesn't control how or when Azure applies updates.

Key Distinction:

Quick Memory Tip 🧠
→ Update Domain = "Azure's update schedule — one group at a time, no full outage!" 🔄

Apache Hadoop was the original open-source framework for distributed processing and analysis of big data sets on clusters. The Hadoop ecosystem includes related software and utilities, including Apache Hive, Apache HBase, Spark, Kafka, and many others.
Azure HDInsight is a fully managed, full-spectrum, open-source analytics service in the cloud for enterprises. The Apache Hadoop cluster type in Azure HDInsight allows you to use HDFS, YARN resource management, and a simple MapReduce programming model to process and analyze batch data in parallel.
To see available Hadoop technology stack components on HDInsight, see Components and versions available with HDInsight. To read more about Hadoop in HDInsight, see the Azure features page for HDInsight.
For more info : https://docs.microsoft.com/en-us/azure/hdinsight/hadoop/apache-hadoop-introduction

→ Why Option A is right:
Private Cloud is exclusively for one organization — either on-premises or hosted, but restricted access. Public Cloud is owned by a provider like Azure and open to any paying customer. Hybrid Cloud integrates both, letting data and apps flow between private and public environments.

→ Why the other options are wrong:

Options B and C: Both swap the definitions between cloud types — a classic exam trap. Mixing Private and Hybrid definitions is the most common mistake.

Quick Memory Tip 🧠
→ Private = "Only for us!" | Public = "Open to everyone!" | Hybrid = "Best of both worlds!" 🔒🌐🔀