Parameterising Logic App (Standard) connections.json with bicep - Part 3

In my previous 2 posts here and here, I briefly showed how we can create the bicep snippet to create API connection resources and subsequently use that to parameterise our Logic App's connections.json. However, I've come to realise that I've missed out one configuration: API access policy. 😨

The API access policy dictates the object (in my case it's the Logic App) that can access the API connection. In this post, I'm covering this additional configuration as well as an observation on the behaviour of bicep.

Creating the API access policy is simple. We've to create Microsoft.Web/connections/accessPolicies, and add the bind our Logic App to this new access policy.

The snippet below creates the API access policy resource given that we've retrieved the particular Logic App resource that we want to allow access to.

resource apiAccessPolicy 'Microsoft.Web/connections/accessPolicies@2016-06-01' = {
  name: '${logicApp.name}-${guid(resourceGroup().name)}'
  location: location
  parent: serviceBusConnApiConnection
  properties: {
    principal: {
      type: 'ActiveDirectory'
      identity: {
        tenantId: subscription().tenantId
        objectId: reference(logicApp.id, logicApp.apiVersion, 'Full').identity.principalId
      }
    }
  }
}

And that's it. The only peculiar behaviour that I've seen is the naming of this resource. For a service bus API access policy, we need to name it with the prefix of the service bus connection name as in the above snippet. However, that is not the case for azure blob.

For azure blob, using the naming structure above will give us an error ~~Expected resource name to not contain any "/" characters. Child resources with a parent resource reference (via the parent property or via nesting) must not contain a fully-qualified name.bicep(BCP170). ~~Turns out we can just name it without the prefix of the API connection's name 🙄, i.e. it's simply

name: '${logicApp.name}-${guid(resourceGroup().name)}'

I'm still trying to understand the reason for this, but well, it is what it is 😄

UPDATE: Turns out I missed out the parent keyword which indicates what's the connection resource for the access policy 😄. Once the parent is specified, we can name the access policy without the prefix.