How does a ViewModel survive configuration changes and what is its scope?

What's really being asked

This question probes whether you understand the boundary between framework-managed UI state and instance state in the Jetpack lifecycle architecture. Specifically, the interviewer wants to know if you can explain why a ViewModel outlives an Activity during rotation but still respects final cleanup, and whether you understand the difference between a ViewModelStore and a LifecycleOwner. They also care if you know why holding data in a ViewModel is preferable to holding it directly in an Activity, since the Activity is recreated on every configuration change while the ViewModel is not.

The full answer

First, scope definition: a ViewModel is scoped to a ViewModelStoreOwner, which is typically an Activity or a Fragment. Second, survival mechanism: when a configuration change occurs, the Activity instance is destroyed, but its associated ViewModelStore is retained by the framework and reattached to the new Activity instance. Third, lifecycle endpoint: the ViewModelStore clears all ViewModels only when the owner is finishing permanently, which happens when onDestroy is called and isChangingConfigurations returns false, or when the process is killed. Fourth, practical implication: because the ViewModel object itself is reused, you can hold UI-related data such as network results or user selections without serializing them into a Bundle. Fifth, threading awareness: since the ViewModel can survive configuration changes, long-running operations started inside it are not interrupted by rotation.

The mistakes people make

A major red flag is claiming that onSaveInstanceState preserves the ViewModel; that API only handles small, parcelable data in a Bundle, not live objects. Another mistake is saying the Activity itself survives rotation or that a static map holds the ViewModel; neither is true. Some candidates also confuse ViewModel scope with process scope, implying the data lives forever even if the app is swiped away, which is incorrect. A subtler error is forgetting that a ViewModel should never hold a direct reference to an Activity or View, since the old Activity is leaked during recreation.

What usually comes next

The interviewer may ask how ViewModel works with SavedStateHandle for process death, or why you should not pass a ViewModel between Activities. They might also ask about the difference between Activity-scoped and Fragment-scoped ViewModels, or how Hilt injects them into different owners. Another common follow-up is asking how to share a ViewModel between a parent Activity and its Fragments using the Activity as the ViewModelStoreOwner.

A concrete example

Imagine an Activity that fetches a list of photos. The user rotates the phone. The Activity is torn down and recreated, but the ViewModel containing the list and the active coroutine job remains in the ViewModelStore. The new Activity requests the same ViewModel via the ViewModelProvider, receives the existing instance, and immediately shows the cached list without refetching. When the user presses back, onDestroy signals a true finish, the ViewModelStore calls clear on the ViewModel, and the coroutine is cancelled. If the system kills the process in the background, the ViewModel is gone, which is why you might pair it with SavedStateHandle for critical parcelable state.