Azure Bicep - Deploy Child Resources
Azure Bicep - Deploy Child Resources

Azure Bicep – Deploying child resources

Sometimes, a resource may have one or more than one child resources. For example, when a storage account is created, the storage account may contain blobs, file storage, and queue storage. Sometimes, it has only one nesting level, some other times, there may be more nesting levels, it completely depends on the resources being created.

In this article, we are going to have a look at how to deploy child resources.

Name of the child resource

In bicep file, we can specify child resources either within the nested scope of parent resource or outside of the parent resource. Where we declare the child resource decides which pattern should we use for passing the values of child resource name and resource type. The full name and type always resolve to the same pattern.

{parent-resource-name}/{child-level1-resource-name}/{child-level2-resource-name}

{resource-provider-namespace}/{parent-resource-type}/{child-resource-type}

Let’s now have a look at two different ways for specifying child resources.

Within Parent Resource

As shown in the code snippet given below, the nested resource declaration must appear at the top level of syntax of parent resource. It can not be nested further inside any other object or properties.

Another thing to note is – the name and type of the nested resource are single segment values, there are no slashes in between.

An example of this kind of syntax is shown below. The top level resource – storage account – has a child resource, file storage. Then the file storage has another child – share.

A nested resource can access the properties of its parent resource. The resources defined within same parent can reference one another by using their symbolic names. However, a parent resource cannot access properties of its children. It would result in an error.

Outside Parent Resource

In this case, the syntax for declaring a child resource is same as that of any parent level resource. The only difference is – while declaring a child resource, the resource should have a property value specified for the property parent – as shown in the code snippet given below.

Another difference is – here the resource type contains slashes as we need to specify the full type. The name property however, is not fully qualified. It just specifies a single token without slashes, which specifies the name of the resource itself.

One example is given below. We have used the same code that we used in previous example code snippet for declaring child resources from within the parent resource.

Full Name Outside the Parent

This is one more approach specified in the documentation. We can specify full type and full name of the child resources. In that case, instead of parent attribute, we need to use dependsOn property, which takes collection of symbolic names of the parent resources.

However this approach is not the recommended approach as per documentation as it not as much type safe as other two approaches.

I hope you find this information helpful. Let me know your thoughts.

Leave a ReplyCancel reply