Portrait of Ram KakaniRam Kakani
Principal PM Manager – Azure

Overview

Oracle AI Database@Azure helps organizations bring Oracle-dependent workloads to Azure while choosing the database architecture, licensing model, connectivity, and operational controls that fit their business. As adoption grows, enterprise readiness depends on turning those choices into consistent, repeatable standards—regardless of whether a deployment is created in the Azure portal, through automation, or by an API.

Azure Policy turns the organization’s approved operating model into an automated guardrail. It can enforce deployment requirements for the Oracle.Database resource type, such as:

  • License governance: deployments must use the organization’s approved license model.
  • Network access: deployments can be required to use an approved private-network model.
  • Control management: critical resources can be protected from unintended deletion.

The policy evaluates requests before a resource is created or updated. Start with the default Audit effect to understand impact; when the effect is changed to Deny, non-compliant deployments are stopped at the point of deployment. This helps teams shift governance left and reduce manual review.

The platform team defines the approved baseline once and assigns it at the appropriate management-group, subscription, or resource-group scope. Application and database teams can then deploy through their existing tools with confidence: compliant requests proceed without an additional approval step, while exceptions receive immediate feedback. This gives teams the agility to adopt Oracle AI Database@Azure faster, without trading away the operational control, security, and consistency that enterprises require.

This approach is intended for cloud platform, security, FinOps, and database-governance teams that need consistent deployment standards for Oracle AI Database@Azure. Application teams retain self-service deployment, while the platform establishes the approved baseline.

Practical Example: Standardize the License Model

Licensing is a useful first guardrail because it turns a commercial decision into a consistent deployment experience. This example is based on a customer requirement to standardize BYOL deployments; it is presented generically and can be adapted to a different approved model. The platform team selects the approved model once, and Azure Policy then applies it consistently across portal, CLI, Terraform, ARM, and API deployments.

  • BYOL standard: When the organization’s approved licensing strategy, such as an Oracle ULA, requires BYOL, require BringYourOwnLicense and prevent License Included deployments.
  • License Included standard: Require LicenseIncluded and prevent deployments configured for BYOL.

The policy definition in this article implements the first scenario: BYOL. For an organization that has approved License Included instead, use the same policy pattern with LicenseIncluded as the required value. Confirm the appropriate model with your licensing and procurement teams before enforcing it.

Start in Audit mode, review the impact with the teams that deploy Oracle AI Database@Azure, and move to Deny once the approved configuration is clear. This gives application and database teams fast, self-service deployment while the platform team maintains a clear, auditable licensing baseline.

Policy Behavior

The policy targets Oracle.Database/autonomousDatabases and denies a matching deployment when either condition is true:

  • licenseModel is missing.
  • licenseModel is not BringYourOwnLicense.

The Azure Oracle Database REST API documents LicenseIncluded as the default if licenseModel is omitted. This policy deliberately requires an explicit BYOL selection, so that an omitted value cannot silently use the default. Confirm this behavior against the API version and deployment paths used in your environment before enforcing the policy.

The policy uses these Oracle Database@Azure provider aliases:

Oracle.Database/autonomousDatabases/licenseModel

Discover the aliases with:

az provider show \
  --namespace Oracle.Database \
  --expand "resourceTypes/aliases" \
  --query "resourceTypes[?resourceType=='autonomousDatabases'].aliases[].name" \
  --output tsv

For general guidance on alias discovery and use, see Azure Policy definition structure aliases.

Example Policy Definition

Create a custom policy definition that targets only Autonomous Database resources.

{
  "properties": {
    "displayName": "Require BYOL for Oracle Autonomous Database deployments",
    "description": "Audits or denies Oracle AI Database@Azure Autonomous Database create or update requests when licenseModel is missing or is not BringYourOwnLicense.",
    "policyType": "Custom",
    "mode": "Indexed",
    "metadata": {
      "category": "Oracle.Database",
      "version": "1.3.0"
    },
    "parameters": {
      "effect": {
        "type": "String",
        "allowedValues": [
          "Deny",
          "Audit",
          "Disabled"
        ],
        "defaultValue": "Audit"
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Oracle.Database/autonomousDatabases"
          },
          {
            "anyOf": [
              {
                "field": "Oracle.Database/autonomousDatabases/licenseModel",
                "exists": "false"
              },
              {
                "field": "Oracle.Database/autonomousDatabases/licenseModel",
                "notEquals": "BringYourOwnLicense"
              }
            ]
          }
        ]
      },
      "then": {
        "effect": "[parameters('effect')]"
      }
    }
  }
}

Create and Assign the Policy

Set the subscription context.

az account set --subscription "<subscription-id-or-name>"

Create or update the custom policy definition.

SUB_ID="<subscription-id>"

az rest \
  --method PUT \
  --url "https://management.azure.com/subscriptions/${SUB_ID}/providers/Microsoft.Authorization/policyDefinitions/require-oracle-autonomous-database-byol?api-version=2023-04-01" \
  --body @policies/require-autonomous-database-byol.json

Assign the policy at subscription scope.

az rest \
  --method PUT \
  --url "https://management.azure.com/subscriptions/${SUB_ID}/providers/Microsoft.Authorization/policyAssignments/require-adb-byol?api-version=2022-06-01" \
  --body @policies/assign-require-autonomous-database-byol.json

Scope and Access Impact

Azure Policy is assigned to an Azure resource scope, not to a group of users. The assignment applies to the resources at that scope and all child resources:

  • Management group: use when the same baseline must apply across multiple subscriptions.
  • Subscription: use when all Oracle Database@Azure deployments in one subscription must follow the baseline. This article uses this scope.
  • Resource group: use when a workload or environment needs a more targeted rollout.
  • Individual resource: use only for an exceptional, narrowly scoped control.

The policy affects every user, service principal, and managed identity that submits a matching request within the assigned scope, provided that identity otherwise has Azure RBAC permission to perform the action. Azure Policy does not grant or remove access; it adds a compliance check to authorized requests. Use Azure RBAC and Microsoft Entra ID groups to decide who can deploy or manage resources, and use Azure Policy to decide which configurations and actions are allowed.

Requesting a policy exemption

When a workload has a documented business or technical reason not to use BYOL, its owner can request a policy exemption from the platform or governance team. An exemption can be scoped to the individual resource or resource hierarchy, remains visible as Exempted in Azure Policy compliance reporting, and can have an expiration date. Use exemptions for specific, time-bound exceptions; do not weaken the baseline policy or create broad exclusions for a single workload.

The platform or governance team should review and create the exemption because Azure requires explicit exemption permissions. See Azure Policy exemption structure for the exemption model, categories, expiration, and required permissions.

Protecting against accidental deletion

The BYOL policy in this article uses the Deny effect to stop non-compliant create and update requests. To protect a critical resource from accidental deletion, create a separate policy that uses Azure Policy’s denyAction effect with the delete action. This complementary control returns 403 Forbidden for a matching delete request. Keep deletion protection as a separate, independently versioned policy, and validate resource-group, parent/child, and cascade-deletion behavior in a non-production subscription before enforcement.

Validate Enforcement

After testing in Audit mode, attempt to create an Autonomous Database with either of these settings:

  • License type: License included

Azure blocks the deployment with:

Resource '<database-name>' was disallowed by policy.
Code: RequestDisallowedByPolicy
Policy: Require BYOL for Oracle Autonomous Database deployments

Create a compliant deployment with:

licenseModel = BringYourOwnLicense

Before production rollout, also test portal, CLI, automation, and supported Terraform or ARM/Bicep workflows; updates to existing resources; a request where licenseModel is omitted; and approved policy-exemption behavior.

Check Compliance

Trigger a policy scan.

az policy state trigger-scan --subscription "${SUB_ID}"

List policy states for the assignment.

az policy state list \
  --subscription "${SUB_ID}" \
  --policy-assignment require-adb-byol \
  --query "[].{resource:resourceId, compliance:complianceState, action:policyDefinitionAction}" \
  --output table

Existing matching resources are evaluated for compliance. The policy does not delete an existing non-compliant resource; it prevents matching create and update requests that do not meet the BYOL requirement. During an Audit rollout, compliance reporting helps teams understand the impact before enforcement is enabled.

Rollback

Disable enforcement without deleting the assignment by changing the assignment parameter to Disabled.

{
  "parameters": {
    "effect": {
      "value": "Disabled"
    }
  }
}

Remove the assignment when the control is no longer required.

az policy assignment delete \
  --name require-adb-byol \
  --scope "/subscriptions/${SUB_ID}"

Keep the definition if other subscriptions will reuse it. Delete the definition only after all assignments are removed.

Conclusion

Governance should make the approved path the easiest path. By expressing validated licensing requirements in Azure Policy, platform teams give application and database teams the freedom to deploy while ensuring every deployment meets the organization’s guardrails from the start.

Begin with a pilot assignment in Audit mode, review the results with the teams that deploy Oracle AI Database@Azure, validate each supported deployment path, and then move to Deny when the expected behavior is confirmed. Reuse the same policy pattern for other Oracle AI Database@Azure resource types by selecting the applicable resource type and provider aliases. As the Network Anchor model evolves, add its validated requirements through a separate, versioned policy rather than coupling them to this licensing baseline.

This approach replaces one-off reviews with a scalable, consistent control: teams get fast feedback during deployment, licensing standards are applied uniformly, and compliance is visible in the Azure Policy experience. The result is an enterprise-ready service model that lets platform teams govern at scale while application and database teams stay productive—accelerating migration and innovation on Oracle AI Database@Azure.