This problem confused me when I started working with animations!
The issue is the difference between animations and frames... Animations always run to the last frame, or they loop if looping is specified.
What you need is 6 animations for your die, and to switch to the required animation when you know the result of the random number. So, you need one animation that has six frames representing the six sides of the die (the 'rolling' animation), and you need six more animations, each having one frame; a different side of the die.
Display the rolling die animation first, then switch to the appropriate animation when you know which number you need to display.
Or... An alternative solution, is to just have six animations for the die, each having one frame. You then repeatedly switch between the 6 animations and just stop switching between them when the random number is chosen. You the display the correct animation for the number.
I think the first solution is more efficient in terms of processor usage, but requires duplicate images, and the second animation is less efficient when it comes to processing, but uses fewer images. For a small game, the second solution won't cause any problems, and is probably the easier to implement.
I think your confusion has (understandably) arisen because we assume that an 'animation' has several frames; it can, but it doesn't have to! Also, with problems such as this, it is not immediately apparent that animations always run through to the last frame, even if we [switch to frame...]. This instruction block is only temporal; it doesn't 'lock' the animation on that frame. I would prefer a simple toggle along the lines of [stop/start animation on {frame}] but that doesn't exist (as far as I know, anyway), so we have to work with what we have!