Closed DavidMrLane closed 1 month ago
@DavidMrLane thanks for raising this issue.
Just to make sure I understand - are you saying that this line principalId: adminServiceApp.identity.principalId
is failing to resolve to the system assigned identity?
If you add an output statement like output sysAssignedMI string = adminServiceApp.identity.principalId
does that resolve and output the SP's ID?
I'm trying to understand where the issue is.
I don't understand why, but adding the output allowed it to validate and then the template deployed successfully.
Does it fail if you remove the output statement, or continue to work? It's definitely weird behaviour. I might have said it was some replication delay issue across distributed systems, but then I wouldn't expect the failure during validation.
Does it fail if you remove the output statement, or continue to work? It's definitely weird behaviour. I might have said it was some replication delay issue across distributed systems, but then I wouldn't expect the failure during validation.
Yes after successfully applying, removing the output statement causes the template validation to fail again.
Closing this as a duplicate of #183. We'll track the investigation and fix there.
Bicep version Bicep CLI version 0.30.23
Describe the bug When validating this template I get the error below:
{"code": "InvalidTemplate", "message": "Deployment template validation failed: 'The resource 'Microsoft.App/containerApps/ca-adminsvc' is not defined in the template. Please see https://aka.ms/arm-syntax for usage details.'.", "additionalInfo": [{"type": "TemplateViolation", "info": {"lineNumber": 0, "linePosition": 0, "path": ""}}]}
Additional context Instead of adding the container app so I could I reference it's system assigned managed identity, I tried the role assignment to a
resource userManagedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' existing = {
andresource miSpn 'Microsoft.Graph/servicePrincipals@v1.0' existing = {
, and that validated fine.