Managing environment configurations and resource governance. If you are studying for the DP-300 exam, this is the topic that keeps your databases running smoothly without overspending or breaking security rules. It matters because without it, you could accidentally give a test database the same access as your live customer database, or run up a massive bill because you forgot to turn off a development server over the weekend.
Jump to a section
A simple way to picture Managing Environment Configurations and Resource Governance
Have you ever tried to renovate your kitchen while still trying to cook dinner for your family?
Imagine you are the head chef at a busy restaurant. You have a kitchen with different sections: the grill, the prep station, the walk-in fridge, and the dishwasher area. Each section has its own resources — gas for the grill, water for the dishwasher, cold air for the fridge. As head chef, you need to make sure the grill has enough gas to sear steaks, but you also need to make sure the dishwasher has enough hot water to clean plates during the dinner rush. If you let the grill use all the available gas, then the oven can't bake bread. If the dishwasher uses too much cold water, the fridge compressor struggles.
Now, your restaurant is about to open a second location. You have to decide: should you physically build a completely new kitchen from scratch, paying for all new equipment and plumbing? Or should you use a standardised kitchen design that can be replicated quickly? This is exactly like managing environment configurations in Azure. You have databases running in different environments — development, testing, and production. Each needs certain resources (compute power, memory, storage) and certain settings (firewall rules, backup policies). Resource governance is the system of rules you put in place to prevent any one database from hogging all the server power or accidentally exposing customer data. Just like you set limits on how much gas the grill can use, you set limits on how much CPU a development database can consume. And just like you create a standardised kitchen plan for your new restaurant, you use Azure Resource Manager templates to create standardised, repeatable database environments.
The trick is that, unlike a physical kitchen, these environments can run in the same cloud kitchen (Azure) side by side, as long as you keep them logically separated with the right configurations and governance.
Let's start with the core idea. In IT, an 'environment' is a complete set of resources where your database lives. You usually have at least three: development (where you write and test code), staging (where you test changes in an environment that mimics the real thing), and production (the live system your customers use). Each environment needs its own configuration — that is, its own settings for things like who can access it, how much power it has, and how often it gets backed up.
Resource governance is the set of rules and limits you put on these resources. Think of it as the speed limits and traffic lights for your databases. Without it, one runaway query could slow down every other application in the company.
The main tool for this in Azure is Azure Resource Manager (ARM). ARM is the management layer that lets you create, update, and delete resources like databases, servers, and networks. Every request to create a database goes through ARM. It checks if you have permission (using Microsoft Entra ID), if the configuration is valid, and if you have enough quota to create that resource.
Now, let's define the key terms you need to know for DP-300:
A subscription is like a billing account. You get one or more subscriptions from your organisation. Each subscription has its own limits on how many resources you can create. For example, you might be limited to 100 SQL databases per subscription.
A resource group is a container that holds related resources for a solution. You might put all the resources for your development environment in one resource group: the database, the server, the storage account for backups, and the network rules. Resource groups let you manage, monitor, and delete everything together. If you delete the resource group, you delete all the resources inside it — very useful for cleaning up a test environment.
Azure Policy is a service that enforces rules on your resources. For example, you can create a policy that says 'All databases must have encryption turned on.' When an administrator tries to create a new database without encryption, Azure Policy blocks the creation or applies the encryption automatically.
Resource locks are like a safety lock on a door. You can apply a 'CanNotDelete' lock on a production database so that nobody — even an administrator — can accidentally delete it. You have to remove the lock first, then delete the resource.
Tags are simple labels you attach to resources. For example, you can tag every database with 'Environment: Production' and 'CostCentre: Marketing'. Tags help you organise resources and understand your costs.
Cost management tools let you set budgets and alerts. You can say 'If this database is going to cost more than 500 dollars this month, send me an email.'
Microsoft Entra ID (formerly Azure Active Directory) is the identity service that controls who can do what. You assign roles to users — for example, the 'SQL DB Contributor' role lets someone manage databases but not change the server firewall rules. This is called Role-Based Access Control (RBAC).
Azure Blueprints let you package together a standard set of Azure resources, policies, and role assignments. If your company needs to create a new development environment that always follows the same security rules, you can use a blueprint to deploy it consistently.
How does this all fit together for a database administrator? When you create a new Azure SQL Database, you must choose or create a server, a resource group, and a subscription. You set its compute size (how much CPU and memory), its storage size, and its backup retention period (how long you keep backups). You also configure the firewall rules (which IP addresses can connect), the authentication method (Microsoft Entra ID or SQL login), and the data encryption settings.
Resource governance comes into play when you need to ensure this database doesn't interfere with others. You might use Azure SQL Database's built-in resource governance features like resource limits per database. You can set a maximum DTU (Database Transaction Unit) or vCore limit for a database, ensuring it can't use more than its fair share of the server's resources.
For managed instances (a more advanced database service), you can configure instance-level resource governance to guarantee performance for critical databases.
Finally, you must consider the lifecycle of your environments. Development databases should be auto-paused when not in use, to save money. They should be restored from production backups occasionally to test with real data, and they should be deleted after a project finishes. Policies and locks help enforce this lifecycle automatically.
In summary, managing environment configurations and resource governance is about setting up your database environments consistently, securely, and cost-effectively, and then enforcing those settings through Azure's built-in tools so that you don't have to rely on people remembering the rules.
Plan your resource hierarchy
Decide how many subscriptions you need and how to organise them into management groups. For example, one subscription for production, one for development. This is the foundation for applying governance at the right level.
Define and apply Azure Policies
Create policies that enforce your company's rules: require encryption, restrict database tiers, mandate tags. Assign these policies at the management group or subscription level so they apply automatically to new resources.
Implement resource locks on critical resources
Apply 'CanNotDelete' locks to production databases and staging databases. This prevents accidental deletion even by users with high-level permissions. Remember to remove the lock before any planned maintenance.
Tag all resources consistently
Use Azure Policy to require tags like 'Environment', 'CostCentre', and 'Owner'. This enables cost tracking, automation, and easier resource management. Audit existing resources to add missing tags.
Set up cost management and budgets
Create budgets for each environment with email alerts when spending approaches limits. Use auto-pause for serverless databases in non-production environments to save money when they are idle.
Create Azure Blueprints for repeatable deployments
Package your standard environment setup (resource group, policies, locks, tags, and roles) into a blueprint. When a new project starts, deploy the blueprint to ensure consistency and compliance from day one.
Meet Priya, a database administrator at a mid-sized retail company. The company runs an e-commerce website with a production database that processes customer orders. They also have a development database where engineers build new features, and a staging database where they test those features before release.
One Monday morning, Priya gets a call from the finance team: the company's Azure bill for last month is 40% higher than expected. Priya logs into the Azure portal and opens the Cost Management tool. She looks at the cost by tag and sees that the development environment, which should be tagged 'Environment: Dev', is actually showing a large chunk of the bill. She drills down and discovers that a developer created a new test database last Friday — a very expensive one with high performance settings — and forgot to tag it. Because it had no tag, it wasn't included in the cost reports the team usually monitors.
Priya's first step is to implement an Azure Policy that requires all databases to have a 'CostCentre' and 'Environment' tag. Any new database created without these tags will be automatically denied. She also creates a policy that restricts which virtual machine sizes and database tiers can be used in the development subscription — preventing expensive 'business critical' tier databases from being spun up for simple tests.
Next, Priya receives a request from the security team. They want to ensure that every database — whether in development or production — has Transparent Data Encryption (TDE) enabled. TDE encrypts the data when it is written to disk. Priya creates another Azure Policy that audits all databases for TDE status and auto-remediates any that are missing it.
Later in the week, a junior developer accidentally deletes the staging database while trying to clean up old resources. This is a major setback because the team loses a week of testing data. Priya decides to apply a 'CanNotDelete' resource lock to the resource group containing the staging database. Now, even if someone tries to delete it, Azure blocks the action.
Priya also uses Azure Blueprints to standardise new environment creation. When the company decides to create a new 'sandbox' environment for experimenting with new database features, she defines a blueprint that includes:
A resource group with the correct naming convention
A policy that forces all databases to use the 'General Purpose' service tier (not the more expensive 'Business Critical' tier unless approved)
A resource lock to prevent accidental deletion
A cost budget that alerts if the environment exceeds 200 dollars per month
A tag for 'Environment: Sandbox'
Each time a new sandbox is needed, the team simply deploys the blueprint. It creates everything consistently, with the right governance already in place.
Finally, Priya sets up auto-pause for the development and sandbox databases after one hour of inactivity. This saves significant money, because developers only use these databases during working hours.
Through these steps, Priya has transformed the company's database management from chaotic and expensive to consistent, secure, and cost-controlled — all using the resource governance tools in Azure.
The DP-300 exam tests your understanding of managing environment configurations and resource governance in several specific ways. You will see multiple-choice questions, case studies, and 'choose the best option' scenarios. Here is exactly what they want you to know:
They love to test Azure Policy versus RBAC versus resource locks. A common question: 'A junior admin accidentally deletes a production database. What should you implement to prevent this?' The answer is a resource lock (specifically CanNotDelete), not RBAC and not Azure Policy. RBAC controls who can do what; a resource lock prevents anyone from doing it.
They will ask about inheriting policies. If you apply a policy at the subscription level, it applies to all resource groups and resources inside that subscription. They will test whether you understand that a policy can be applied at management group, subscription, resource group, or individual resource level. The broader the scope, the more it covers.
They will ask about the difference between 'audit' and 'deny' effects in Azure Policy. 'Audit' just logs a warning if a resource doesn't comply; 'Deny' blocks the creation of non-compliant resources. For example, a policy that 'deny' creating databases without encryption will stop the creation. A policy that 'audit' will let it be created but flag it.
Resource tags appear frequently. Know that you can use tags to organise billing, enforce policies, and automate actions. A typical question: 'You need to ensure all databases have a cost centre tag. What should you use?' Answer: Azure Policy with a 'deny' or 'audit' effect.
They will test Microsoft Entra ID integration. Know that you can use Microsoft Entra ID authentication for SQL databases and that this is more secure than using SQL Server logins. You need to assign a Microsoft Entra ID user as the 'Active Directory admin' for the SQL server first.
They will test the difference between 'General Purpose', 'Business Critical', and 'Hyperscale' service tiers, especially in the context of cost governance. They might ask: 'You need to ensure developers only use the cheapest tier. What do you use?' Answer: A policy that restricts the allowed SKU.
The exam loves scenarios where you need to manage costs. They will ask about setting budgets, using cost alerts, and the 'auto-pause' feature for serverless databases.
Traps to watch for:
Confusing 'RBAC roles' with 'Azure Policy'. Remember: RBAC is about who can do what. Policy is about what is allowed to exist.
Thinking that deleting a resource group automatically deletes a resource lock on that resource group — it doesn't. You need to remove the lock first.
Assuming that all policies are applied at creation time only. Some policies can audit ongoing compliance.
Forgetting that Azure Blueprints include not just resources but also policies, roles, and locks.
Key definitions to memorise:
Resource lock: Prevents deletion or modification of a resource.
Azure Policy: Enforces rules on resource properties.
RBAC: Controls which users can perform actions.
Tag: A metadata label for organising resources.
Blueprint: A package of resources, policies, and roles for standardised deployments.
Management group: A container for managing multiple subscriptions.
The exam expects you to know the tools in the Azure portal: Cost Management, Policy, Locks, Tags, and Blueprints. They will give you a scenario and ask which tool to use.
Finally, they test your understanding of 'initiatives' in Azure Policy. An initiative is a group of policies. For example, 'ISO 27001' is an initiative with many policies. They might ask which initiative to use for a compliance requirement.
Resource locks are your safety net to prevent accidental deletion of production databases — never rely on RBAC alone for that.\n
Azure Policy enforces configurations, like requiring encryption or specific tags, at resource creation and continuously.\n
Tag every database with environment, cost centre, and owner to make cost tracking and automation possible.\n
Use Azure Blueprints to deploy consistent, compliant environments with policies, roles, and resources bundled together.\n
The 'deny' effect in Azure Policy blocks non-compliant resource creation straight away, while 'audit' only logs the violation.\n
Microsoft Entra ID authentication is more secure and easier to manage than SQL Server logins for Azure SQL databases.\n
Cost management alerts and budgets help you avoid surprise bills from runaway development or test databases.\n
Management groups let you apply policies and RBAC across multiple subscriptions in a single hierarchy.
These come up on the exam all the time. Here's how to tell them apart.
RBAC (Role-Based Access Control)
Controls who can perform actions (e.g., create databases).
Uses role assignments like 'SQL DB Contributor'.
Works at scope: management group, subscription, resource group, resource.
Azure Policy
Controls what resource configurations are allowed (e.g., encryption must be on).
Uses policy definitions with effects like 'Deny' or 'Audit'.
Also works at the same scopes, but enforces rules, not permissions.
Resource Lock
Prevents deletion or modification of a resource entirely.
Simple to apply — just a lock type (CanNotDelete, ReadOnly).
Cannot be overridden even by the resource owner; must be removed first.
Azure Policy with 'Deny' Effect
Blocks creation of resources that don't meet specific conditions.
Can enforce complex rules, like 'only allow specific database tiers'.
Can be set to 'Audit' instead of 'Deny' for non-blocking compliance checks.
Tag
A metadata label (key-value pair) attached to a resource.
Used for organisation, cost tracking, and automation.
Does not enforce any behaviour by itself.
Azure Policy
A rule that enforces or audits resource configurations.
Used to enforce compliance, security, and naming conventions.
Can require tags to exist, but is a separate service from tags themselves.
Mistake
Azure Policy and RBAC are the same thing — both control who can do what.
Correct
Azure Policy controls what resources can be created or how they must be configured. RBAC controls who can perform actions (like creating or deleting) on resources.
Both involve 'rules', so beginners lump them together. In reality, they serve completely different purposes and are used together.
Mistake
If I delete a resource group that has a resource lock, the lock is removed automatically and the deletion succeeds.
Correct
A resource lock on a resource group prevents the deletion of that resource group itself. You must remove the lock before you can delete the group.
People think locks only protect individual resources inside the group, but locks can also be applied to the resource group container itself.
Mistake
Tags are only useful for cosmetic organisation and don't affect functionality.
Correct
Tags can be used to enforce policies (e.g., require a specific tag), automate actions (like shutting down resources based on a 'shutdown' tag), and allocate costs in billing reports.
Tags seem like simple labels, so beginners undervalue them. Azure treats them as integral to governance and automation.
Mistake
Once you apply an Azure Policy, it only checks new resources, not existing ones.
Correct
Azure Policy can be configured to audit or remediate existing non-compliant resources. The 'audit' effect flags them, and 'deployIfNotExists' can automatically fix them.
People think policies only apply at creation time because that is when they are most visible. Azure Policy can also continuously monitor compliance.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A resource lock prevents deletion or modification of a resource. Azure Policy enforces rules on resource properties (like 'must have encryption'). They work together but solve different problems.
Yes. Applying a 'CanNotDelete' lock to a resource group prevents anyone from deleting the resource group itself, which protects all resources inside it.
In Azure Cost Management, you can filter and group costs by tags. For example, if you tag all development databases with 'Environment: Dev', you can see exactly how much money is spent on development.
If the policy effect is 'Deny', the creation fails and you get an error message explaining which policy was violated. If the effect is 'Audit', the database is created but flagged as non-compliant in the compliance dashboard.
Yes. You can use the 'audit' effect to check existing databases for compliance, and the 'deployIfNotExists' effect to automatically apply required configurations to existing ones.
A management group is a container that lets you manage access, policies, and compliance across multiple subscriptions. For example, you can apply a policy to a management group that covers all subscriptions inside it.
You've finished Managing Environment Configurations and Resource Governance. Continue through the DP-300 study guide to build a complete picture of the exam.
Done with this chapter?