Exam AI-102 topic 5 question 10 discussion

YYN is the answer. https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-concept-state?view=azure-bot-service-4.0#state-property-accessors State property accessors are used to actually read or write one of your state properties, and provide get, set, and delete methods for accessing your state properties from within a turn. To create an accessor, you must provide the property name, which usually takes place when you're initializing your bot. Then, you can use that accessor to get and manipulate that property of your bot's state. The accessors allow the SDK to get state from the underlying storage, and update the bot's state cache for you. The state cache is a local cache maintained by your bot that stores the state object for you, allowing read and write operations without accessing the underlying storage. If it isn't already in the cache, calling the accessor's get method retrieves state and also places it in the cache. Once retrieved, the state property can be manipulated just like a local variable.

Looks correct

In order from top to bottom Yes is CORRECT. First, we need to know that the bot is stateless by nature. Once launched, our bot might not execute on the same machine or in the same process for different users. To control its behavior and retain responses to earlier queries, your bot might need to save the context of a conversation. We can add a state to our bot using the Bot Framework SDK's state and storage features. Bots preserve and manage their state through the usage of storage objects and state management. Yes is CORRECT because the Bot Framework SDK allows the bot to create and maintain objects like ConversationData in the underlying in-memory storage during the bot's runtime. In-memory storage is used to store and access state properties such as ConversationData and UserProfile through state accessors. While this storage is volatile and cleared when the bot restarts, it functions as the underlying storage layer during the active session. No is CORRECT. When the Bot Framework we defined is terminated it will lose all access to previous conversational data as the data stored in memory is temporary and disappears when the Bot Framework runtime terminates.

Save some time and ignore Bot Framework. It's no longer on the AI-102 exam.

My answer is that Yes Yes No

This is the same question as topic 5 No.52.

Final Answer YYN

The first two are YES, the last is NO. "Memory storage The Bot Framework SDK allows you to store user inputs using in-memory storage. Since in-memory storage is cleared each time the bot is restarted, it's best suited for testing purposes and isn't intended for production use. Persistent storage types, such as database storage, are best for production bots." https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-howto-v4-storage?view=azure-bot-service-4.0&tabs=csharp

Ok seems everyone get this wrong. The answer are N, N, N. CreateProperty method provides a handle to the BotState object. BotState is part of the cache. Nothing will save to the storage layer unless you explicitly do so in the code. The storage layer is in memory in this case as a result nothing will be persisted once the bot is destroyed.

Yes, No, No

First one is Yes. The code provided creates state accessors for both UserProfile and ConversationData objects. These state accessors are used to store and retrieve the respective objects in the underlying state storage mechanism, which in this case is Memory Storage. When you use the state accessors to set or get the UserProfile object, the Microsoft Bot Framework SDK will create and maintain the UserProfile object in the Memory Storage, allowing you to persist user profile information across multiple turns in the conversation.

Answer is : No No No If the user profile and conversation states are committed to memory, then they are in fact stored in cache memory and not on the underlying storage layer (disk). Hence, the user profile and conversation data will get deleted once the session runtime is over.