A migration team has assumed that every transformed application can be deployed as stateless. What finding would show this assumption is wrong for a given application?
Select an answer to reveal the explanation.
Short Explanation
If the application has to remember something between requests, calling it stateless doesn't make that need go away. You need to spot retained session or transactional context before assuming a stateless deployment will work.
Full Explanation
The correct finding is that the application depends on session or transactional context that must persist across requests, because a purely stateless deployment has nowhere to keep that state, so it either breaks or silently reconstructs it in a fragile way. Some mainframe applications carry session or transactional state that later steps depend on. The finding that the application has more than one functional requirement documented is wrong because having multiple functional requirements is unrelated to statefulness. The finding that the application was originally written in COBOL rather than a newer language is wrong because the original language does not determine whether the application's behaviour depends on retained state. The finding that the application exposes more than one integration point is wrong because integration point count is a separate architectural concern. For the exam, check for retained state explicitly rather than defaulting to stateless.