1. Is it mandatory to have SQL Server agent account defined in SQL
server logins to run the job?
See this and this.
The SQL Server Agent runs as a Windows service named NT SERVICE\SQLSERVERAGENT. The NT SERVICE\SQLSERVERAGENT login is how the Windows process that is SQL Server Agent connects to the Database Engine to read the msdb database to find out what it should do; and then do it. Both of these logins are members of the sysadmin fixed server role, so they can do anything in the Database Engine. And they need to stay that way.
As for the account that you used to run the services, this is complicated and has changed in each version of SQL Server.The short answer is that the account you specify will be used when a process tries to reach outside of the current Windows environment. But within the computer, there is a mix of authorization granted to the domain user, the service, and the Windows group SQLServerMSSQLUser$computername$MSSQLSERVER.
There are permission in the operating system that an agent account gets by default. Details here.
As per books online:
The account that the SQL Server Agent service runs as must be a member
of the following SQL Server roles:
The account must be a member of the
sysadmin fixed server role.
To use multiserver job processing, the
account must be a member of the msdb database role TargetServersRole
on the master server.
In all Windows versions, permission to log on as a service (SeServiceLogonRight)
But it should not be a member of local administration group.
We recommend choosing a Windows user account that is not a member of
the Windows Administrators group. However, there are limitations for
using multiserver administration when the SQL Server Agent service
account is not a member of the local Administrators group
2. What user/login my update job is using in order to update the table?
Job ownership is an important concept in SQL Server Agent. SQL Server Agent sets the security context for job execution based on the role of the user owning the job. By default, SQL Server Agent executes job steps under the SQL Server Agent service account irrespective of job ownership, or under the context of a proxy account.
The exception to this rule is T-SQL job steps, which execute under the security context of the job owner. If the job owner is a member of the sysadmin role, then the job step executes in the context of the SQL Server Agent service account.