Hi @MohanaBasak , thank you for the blog post, that's very useful. We're using Databricks autoloader (with notification mode without using UC) to load files across aws accounts. The databricks job is in account B and the s3 bucket / sqs-to-be-created-by-autoloader / sns-to-be-created-by-autoloader are in account A. The only difference is that our databricks job in account B needs to write to account B's S3 and Glue (not writting to account A's S3 as you described in the blog post). I believe that it's a common use case. Do you think after the account B role `arn:aws:iam::<account_b_id>:role/acc_b_instance_profile` has assumed the the account A role `arn:aws:iam::<account_a_id>:role/acc_a_autol_auto_create_role`, the databricks job would lose its original permissions (given to `arn:aws:iam::<account_b_id>:role/acc_b_instance_profile`) to write to account B's S3 and Glue? Or the databricks job is smart enough to only assume the role when using autoloader with SQS/SNS, and skip assuming the role (so using the original `arn:aws:iam::<account_a_id>:role/acc_a_autol_auto_create_role`) when writing to account B's S3 and Glue?
