Azure Cloud Fundamentals

01Purpose and scope

• This manual supports the course Azure Cloud Fundamentals. It is written as a working reference for people who need to read, request, deploy, or review resources in Microsoft Azure, whether they come from an infrastructure, development, support, finance, or project background.
• The scope covers the basic model of how Azure is organized, the services most teams touch first, how access and cost are controlled, and how a small environment is planned and documented. It does not teach deep architecture for specific workloads, advanced networking design, or certification exam content. Those topics build on the foundation here.
• Practice changes with the size of the organization and the sensitivity of the data. A single developer with a personal subscription makes different decisions than a regulated business running production systems across several regions. This manual points out where those differences matter.

02Core principles

• Azure is a shared platform, so responsibility is divided. Microsoft operates the physical datacenters, the hypervisor layer, and the managed platform services. The customer remains responsible for identities, data classification, access decisions, configuration of virtual machines and network rules, and the application code. The exact split depends on the service model: infrastructure as a service leaves more to the customer than platform or software as a service. Read the shared responsibility documentation for the specific service before assuming a control is handled for you.
• Azure resources sit inside a hierarchy. Management groups contain subscriptions, subscriptions contain resource groups, and resource groups contain individual resources such as storage accounts, virtual machines, and databases. Policies, role assignments, and cost reporting can be applied at each level, and settings flow downward. Placing a resource in the wrong subscription is hard to undo cleanly, so the hierarchy should be decided before the first deployment.
• Location matters. Each resource is created in a region, and some regions offer availability zones, which are physically separate datacenters within the same region. Data residency and sovereignty rules depend on jurisdiction and on the contracts an organization has signed. Where those rules apply, confirm the permitted regions with legal or compliance staff and the current Microsoft documentation rather than relying on habit.
• Identity comes before infrastructure. Microsoft Entra ID provides the directory that authenticates people and workloads. Access should follow least privilege, meaning each person or service receives only the roles needed for the task. Shared administrator accounts and long-lived secrets written into scripts are the usual sources of trouble.
• Pay for what runs. Most Azure services bill by consumption, reserved capacity, or a combination. Resources that are stopped, unused, or oversized still cost money in many cases. Cost is a design input, not a report produced after the fact.

03Planning and preparation

• Start by naming the people who will own the work. A typical small setup needs a billing owner who can manage the account and payment method, a platform or cloud administrator who creates the subscription and hierarchy, a security contact who approves identity and access rules, and one or more workload owners who request resources. In a larger organization, the security and finance functions usually have formal sign-off on subscription creation and budget limits.
• Decide the subscription structure before creating resources. Common patterns separate production from nonproduction work, and separate workloads with different owners or cost centers. A simple plan might use one management group for the organization, one group for production, and one for development and testing, with a subscription under each for each major workload. Write the plan down with names, purposes, and owners.
• Set a naming convention and a tagging standard early. Names should identify the environment, the workload, the region, and the resource type, so that a person can read a resource name and understand its purpose. Tags such as owner, cost center, environment, and data classification allow cost and compliance reports to be filtered. Tags do not apply automatically to every resource, so enforcement through Azure Policy is worth the effort.
• Set budgets and alerts before deploying anything substantial. Cost Management in the Azure portal allows budgets with threshold notifications to named recipients. A budget alert does not stop spending by itself, so the response procedure should name who acts when an alert fires.
• Gather the deliverables you will need: a one page architecture summary, a resource inventory, an access matrix listing roles and who holds them, a cost estimate using the Azure pricing calculator, and a list of regions with the reason each was chosen. These documents are short but they prevent the most common disputes later.

04Recommended workflow

1. 1
   : Confirm the account, billing arrangement, and tenant. Verify which Microsoft Entra tenant the organization uses, who holds global administrator rights in it, and whether the billing account is an enterprise agreement, a pay-as-you-go subscription, or another arrangement. Record the answer, because billing and administration rules differ between them.
2. 2
   : Build the management group and subscription structure. Create the top level management group, the child groups for production and nonproduction, and the initial subscriptions. Move subscriptions into the correct group so that inherited policies apply from the start.
3. 3
   : Assign identities and roles. Add users to groups in Microsoft Entra ID rather than assigning roles to individuals one at a time. Assign built-in roles such as Reader, Contributor, or Owner at the narrowest scope that still allows the work. Use privileged identity management or a similar approval process for elevated roles where the tenant license supports it.
4. 4
   : Apply governance controls. Assign Azure Policy definitions that require tags, restrict deployments to approved regions, and block resource types the organization does not use. Start policies in audit mode for a short period if existing resources might fail the new rules, then switch to enforcement once owners have had time to fix them.
5. 5
   : Create resource groups and deploy resources. Group resources that share a lifecycle, such as an application's web app, database, and storage account. Prefer deployment through templates written in Bicep or Azure Resource Manager templates, or through Terraform where the team already uses it, so that the environment can be recreated and reviewed. Deploy from a pipeline when possible, using a service identity rather than a personal account.
6. 6
   : Configure monitoring, backup, and cost alerts. Enable Azure Monitor diagnostic settings for resources that matter, create alert rules for failures and resource health, configure backups for data stores according to the recovery requirements the owner has stated in writing, and confirm that budget alerts reach people who can act on them.
7. 7
   : Review and hand off. Walk through the deployed environment against the architecture summary and the access matrix. Record any deviations, confirm that owners can sign in and perform their tasks, and schedule the first cost review. Store the documents where the owners can find them and update them when the environment changes.

05Quality checks, risk controls and compliance

• Azure Advisor produces recommendations for reliability, security, performance, operational excellence, and cost. Treat its output as a prompt for review rather than as instructions. Some recommendations conflict with the workload's requirements, and a recommendation to resize a database may be wrong for a system that spikes at month end. Record the decision either way.
• Microsoft Defender for Cloud provides a security posture view and recommendations across subscriptions. Enabling enhanced protection plans carries an additional cost, so the decision should be made with the security owner and documented. Review open high severity findings on a fixed schedule rather than only when someone remembers.
• Check public exposure at deployment and after changes. Storage accounts, databases, and virtual machines should not be reachable from the public internet unless the design requires it. Network security groups, private endpoints, and firewall rules should be reviewed against the architecture summary. Azure Policy can block some public access settings outright, which is a stronger control than a checklist.
• Control secrets with Azure Key Vault rather than storing them in configuration files, source repositories, or scripts. Restrict who can read secrets, enable logging on the vault, and rotate credentials on a schedule set by the owner.
• Compliance depends on the regulations that apply to the data and the industry. Frameworks such as those published by standards bodies or government agencies each have their own requirements, and Microsoft publishes compliance documentation for its services. This manual does not establish what any specific regulation requires. For regulated or high-risk data, including health, financial, legal, or tax records, the guidance here does not replace qualified professional judgment, approved internal procedures, or required authorization. Confirm requirements with the responsible compliance or legal staff and the current official sources.

06Collaboration and documentation

• Each resource group and subscription should have a named owner and a named technical contact recorded in tags and in the inventory. When an owner changes roles, the handover should be recorded in the same place. Ownerless resources are the usual source of unexplained cost and unclear security responsibility.
• Keep an architecture summary for each workload. It should show the main components, the region and zone choices, the network boundaries, the identity model, and the data stores with their classification. A diagram helps, but the written reasons for each choice are more useful later, because they explain why a decision was made.
• Change requests should identify the resource, the change, the reason, the rollback approach, and the approver. For infrastructure changes made through templates, the template and its pull request serve as much of the record. Manual portal changes should be avoided in production where possible, and when they happen, they should be written back into the template so that the next deployment does not undo them.
• Share cost reports with workload owners monthly, using tag based filtering. Finance staff need a consistent view of spending by cost center, and engineers need enough detail to act. A short written note explaining significant changes in spending is usually more valuable than the raw chart.

07Measures and continuous improvement

• Useful indicators include the percentage of resources with complete required tags, the number of role assignments granted at subscription or management group scope, the count of open high severity security recommendations and how long they stay open, the share of spending that falls under a budget owner, and the number of deployments that fail or require manual correction. Each indicator should have a named owner and a review frequency. Targets should come from the workload owner and the business, not from a generic benchmark.
• Availability and recovery figures should match the service level agreements the organization has committed to, and the service level terms for each Azure service are published by Microsoft. Test recovery procedures on a schedule. A backup that has never been restored is an assumption, not a control.
• Review unused and idle resources each quarter. Stopped virtual machines that still have disks attached, unattached public IP addresses, and old snapshots are common sources of spend. Removing them requires confirmation from the owner, so the review should produce a list and a deadline rather than immediate deletion.
• Revisit the subscription and governance design once a year or when the organization changes significantly. Acquisitions, new regulatory obligations, and new workloads often expose gaps in the original hierarchy.

08Common mistakes and how to prevent them

• A frequent mistake is treating the first subscription as a permanent sandbox. Production workloads end up sharing a subscription with experiments, which complicates access control, cost reporting, and policy scope. Prevent this by creating separate subscriptions for production and nonproduction work at the start, even when the first workload is small.
• Another mistake is assigning the Owner role broadly to make work easier. This gives users the ability to change permissions as well as resources. Prevent it by granting Contributor or a narrower custom role for deployment work, and reserving Owner for a small named group.
• Teams often create budgets and never look at them, or set alert thresholds that fire only after the money is spent. Prevent this by setting thresholds below the actual ceiling, naming the recipient, and writing the response expectation in the runbook.
• Resources are frequently created by hand in the portal and then forgotten. Prevent this by requiring templates for production deployments and by using policy to require tags on every resource at creation time.
• Assuming the platform handles backup, retention, or patching is a serious error. Managed services differ, and the owner must confirm what is included, what is configurable, and what is their responsibility.

09Practical checklist

• Confirm the tenant, billing arrangement, and the named administrators before creating any resources.
• Record the management group and subscription structure with owners and purposes.
• Define the naming convention and the required tags, and enforce them with Azure Policy.
• Limit deployment regions to those approved for the data involved, and document the reason for each.
• Assign roles through groups at the narrowest practical scope, and avoid broad Owner assignments.
• Store secrets in Azure Key Vault and confirm who can read them.
• Deploy production resources from templates or a pipeline using a service identity.
• Configure budgets with alerts to named recipients and write the response procedure.
• Enable monitoring, diagnostic settings, and backups matched to stated recovery requirements.
• Review Azure Advisor and Defender for Cloud findings on a fixed schedule and record decisions.
• Check public network exposure after every change to networking or storage settings.
• Update the architecture summary, access matrix, and inventory after each significant change.
• Review idle resources and cost trends with owners each quarter.

★Learning sources

• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Data Analytics Applications
• Micro Degree: Google Cloud Platform Basics
• Micro Degree: Generative AI Applications