Azure DevOps service connection: lifetime of service principal I have a hard time understanding the lifetime of the service principal created in Azure AD when creating the service connection between Azure DevOps and Azure. I do it like this:

I pick the Azure Resource Manager


And then i choose the recommended


Hereafter I fill in the blanks


I now have a valid service connection and I can deploy from DevOps to Azure. The only thing i need is a user with enough rights to do this. I can even see the service principal in Azure where it tells me that the client secret will expire in two years:


What i dont understand:


does the service connection then stop working when the secret expires? Or will DevOps somehow extend the expire date?
i cant read this anywhere, so it is up for my own interpretation on how i understand the "service principal" concept, but if the user used to create the principal gets disabled or deleted, then the service principal will persist, correct?
if 2) is correct, then when will the principal get deleted? When the scope of the principal gets deleted? Or when the service principal itself gets deleted?
I will try to elaborate a lite about those topics.


When secret expires and you got error, you have to refresh connection. Go to Edit dialog for connection and save without any changes. Described here: Azure devops service connection expired and cannot edit/renew

But I have already tested scenario when I delete all secrets assigned to service principal used for the Azure DevOps connection. And it is still working. So I can assume, that it depends on how you create connection (automatic or manual service principal). When created with automatic path, it doesn't depend on secrets.

On the other hand, when I add connection with manually providing service principal, then delete all secrets, the connection stops working. 
Yes, the service principal will exist. But best practice is to set up more then one Owner of the service principal. If the only one service principal owner is deleted, you need to have higher permission to manage all service principals.
Service principal will not expire itself, only secrets generated for it. To delete service principal object, you have to do it manually.