Hi,

1. Is this expected behavior when using --force-lock after a partially successful deployment? - This is expected when the state becomes disconnected from actual workspace resources. DAB uses IDs generally to correlate bundle resources with workspace instances. If the state file does not contain the IDs of partially deployed resources, DAB treats it as new.

2. Is there a recommended recovery process after a deployment fails midway? - You can use the bundle deployment bind command to manually link existing resources back to your bundle. It updates the state file to recognize the existing resource preventing duplicates in the next deployment

3. Is there a way to resume deployment without creating duplicate resources? - You can try to manually reconnect the partially deployed resources to the bundle state. Identify which jobs were created, 

   for every job that exists - bind it to your bundle & deploy normally. You can also manually delete the partially deployed resources from the UI and deploy again.

databricks jobs list --output JSON | grep "jobname"

databricks bundle deployment bind resourcekey jobid -t prod

databricks bundle deploy -t prod

4. Does this indicate that the deployment state (Terraform/DAB state) is being recreated or lost? - The state is being lost or corrupted during the failed deployment. Next deployment runs with the old state that doesn't include the partially deployed resources. DAB sees it as missing from state and creates it again

5. Is there any recommended approach for Azure DevOps pipelines to prevent this scenario? - You can follow below.

• Use explicit root_path in production
• State file backup - You can consider backing up the state file from the workspace if possible before deploying.
• You can use bundle validate before deployment to catch configuration issues
• Consider fail-on-active-runs to prevent concurrent deployment issues