What are the limitations of just-in-time provisioning?

Four, and I raise them before anyone commits to a design.

1. It only runs at login. A user who does not sign in never gets updated, so entitlements drift silently.
2. It cannot deactivate. There is no “this user has left” event, because a leaver by definition stops logging in. De-provisioning needs a push mechanism or a reconciliation job.
3. It is only as good as the attributes sent. A missing required attribute fails the whole assertion rather than partially provisioning, and the error surfaces to the user as a login failure.
4. Community provisioning is harder than internal. An external user needs a contact and an account, so the assertion has to carry enough to establish that chain, not just the user attributes that suffice internally.

None of that makes it a bad tool — it is excellent at keeping a user's attributes and permission sets current at the moment they arrive. It is just not a lifecycle solution, and the interview question is usually testing whether I know the difference.