SysDB is an agent, so it resides in memory. Its contents are built after every boot, which means that it does not survive a reboot... Ans - D

Arista EOS: SYSDB Separating functional control of the system into multiple processes greatly enhances resiliency and fault isolation, but requires a mechanism for coordinating actions within the system. This is the role of Sysdb. As figure 2 shows, at the core of EOS is the system database. Sysdb is an in-memory database (machine generated at run time), which runs in user space and contains the complete state of the system. Like traditional databases, Sysdb does not contain any application logic and is only responsible for keeping state. However rather than being optimized for transactions, Sysdb is designed for synchronizing state among processes, also called ‘agents’, by notifying interested processes or agents when there is a change. All agents in the system mount their configuration and status from Sysdb. This is very much like a file-system mount where read-only or read-write permissions are specified for each mount point. When an agent mounts from Sysdb, it receives its own local copy of all of the state in that mount point. As Sysdb is maintained in RAM, once the switch is turned off or restarted, information is lost.

. SysDB is the repository for state information for EOS agents, means its like RAM, when reboots nothing is saved in it

D because it resides in RAM

Do belive with D SysDB is an agent, so it resides in memory. Its contents are built after every boot, which means that it does not survive a reboot (that’s what the startup-config is for).

I believe the answer should be D, sysDB is only available in RAM