Oracle Cloud Infrastructure Documentation

Managing Tag Defaults

This topic describes how to you can specify tags to be automatically applied to resources at creation time.

Required IAM Policy

If you're in the Administrators group, then you have the required access for managing tag defaults and tag namespaces. For specific policy information for this feature, see Required Permissions for Working with Tag Defaults.

If you're new to policies, see Getting Started with Policies and Common Policies. If you want to dig deeper into writing policies for tagging or other IAM components, see Details for IAM.

Overview of Tag Defaults

Tag defaults let you specify tags to be applied automatically to all resources, at the time of creation, in a specific compartment. This feature allows you to ensure that appropriate tags are applied at resource creation without requiring the user who is creating the resource to have access to the tag namespaces. Consider the following example:

Alice is a finance administrator and has access to the restricted tag namespace Finance. Alice can set up a tag default to apply the Finance.CostCenter tag to all resources with a value of W1234. Eli can create resources but does not have access to the Finance tag namespace. When Eli creates a resource, the Finance.CostCenter tag is automatically applied with a value of W1234. Eli cannot change this tag, and Alice is confident that it will always be applied correctly and not changed by the users who create or edit resources.

Tag defaults allow tenancy administrators to create secure permissions boundaries between users concerned with governance and users who need to create and administer resources.

Where to Manage Tag Defaults

Tag defaults are defined for a specific compartment, and in the Console you manage them on the Compartment Details page.

This screenshot shows the Compartment Details page in the Console

Required Permissions for Working with Tag Defaults

To create or edit a tag default for a compartment, you must be granted, at a minimum, the following combination of permissions:

  • manage tag-defaults access on the compartment where you are adding the tag default
  • use tag-namespaces access on the compartment where the tag namespace resides
  • inspect tag-namespaces access on the tenancy

For the full mapping of permissions to API operations, see Details for IAM.

For example, assume you have created a set of tag namespaces in CompartmentA. To give a group named TagAdmins access to add tag defaults to CompartmentA, write a policy with the following statements:

Allow group TagAdmins to manage tag-defaults in compartment CompartmentA

Allow group TagAdmins to use tag-namespaces in compartment CompartmentA

Allow group TagAdmins to inspect tag-namespaces in tenancy

Now assume you want to allow TagAdmins to also create tag defaults in CompartmentA using tag namespaces that reside in CompartmentZ. Add a statement to allow TagAdmins to use tag namespaces in CompartmentZ:

Allow group TagAdmins to use tag-namespaces in compartment CompartmentZ

Now when TagAdmins create tag defaults in CompartmentC, they can use tag namespaces that reside in either CompartmentA or CompartmentZ.


See this known issue for information about the policy statements that are required to use tag defaults with Compute instance pools and cluster networks.

Working with Tag Defaults

Tag defaults can only be set up for defined tags. Free-form tags are not supported for tag defaults.

You can define up to 5 tag defaults per compartment.

After a tag default is created, the default tag is applied to any new resources created in the compartment. Previously existing resources in the compartment are not tagged retro-actively. Similarly, if you change the default value of the tag default, existing occurrences are not updated. And, if you delete the tag default from the compartment, existing occurrences of the tag are not removed from resources.

Required Tag Values

For tag defaults, you must include a tag value, but you have a choice about how the value is applied.

  • Default value
  • User-applied value

If you use a default value, then you must create it. This value is applied to all resources.

If you specify that a user-applied value is required, then the user creating the resource must enter the value for the tag at resource creation time. Users cannot create resources without entering a value for the tag.


You can use predefined values and user-applied values to ensure that users only apply a value that you trust. See Using Predefined Values.

Tag Inheritance

The default tag is applied to all resources that get created in the compartment, including child compartments and the resources created in the child compartments.


  • In CompartmentA, you create a tag default, TagA.

    Resources (and compartments) created in CompartmentA are automatically tagged with TagA.

    • In the subcompartment, CompartmentB, you create tag default, TagB.

      Resources and compartments created in CompartmentB are automatically tagged with TagA and TagB.

      • In the sub-subcompartment, CompartmentC, you create tag default TagC.

        Resources created in CompartmentC are automatically tagged with TagA, TagB, and TagC.

This example is illustrated in the following graphic:

This image shows an example of nested compartments and how default tags are inherited

Overriding Tag Defaults

Tag defaults can be overridden at the time of resource creation by users who have the appropriate permissions to both create the resource and use the tag namespace.

Example: CompartmentA has a tag default defined to apply CostCenter.Operations="42". Pradeep belongs to a group that grants him permissions to create instances in CompartmentA and also to use tag namespaces in CompartmentA. He creates an instance in CompartmentA, and in the Create Instance dialog, he applies the tag CostCenter.Operations="50". Because he has the appropriate permissions, when the instance is created, the tag default is overridden, and the instance is tagged with CostCenter.Operations="50".

After a resource is created and tagged, users with the appropriate permissions to both update the resource and use the tag namespace can modify the default tags that were applied at resource creation.

Tag Defaults and Retired Tags

Retired tags can't be applied to new resources. Therefore, if the tag namespace or tag key specified in a tag default is retired, resources can no longer be created in the compartment, because the retired tag cannot be applied. You must delete the tag default that specifies the retired tag to continue to create resources in the compartment.

Tag Defaults and Tag Variables

You can use tag variables in tag defaults. Tag variables dynamically resolve at resource creation time. For example, you enter a tag variable for principal name as the tag default in a particular compartment.


Davis and Garcia each create buckets in that compartment. The buckets that Davis creates include default tags that contain his name as the value, while the buckets that Garcia creates have his name.



Meanwhile, the tag default still contains the original variables. See Using Tag Variables.

Limits on Tag Defaults

There is a limit of 5 tag defaults that can be defined per compartment.

See Limits on Tags for more limits on tags.

Using the Console


Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

To create a tag default
To update the default value of a tag default
To delete a tag default

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use these API operations to manage tag defaults: