B is correct. Once lock from local PA, new policy cant be push from Pano

Panorama Administrator's Guide Manage Locks for Restricting Configuration Changes Locking the candidate or running configuration prevents other administrators from changing the configuration until you manually remove the lock or Panorama removes it automatically (after a commit). Locks ensure that administrators don’t make conflicting changes to the same settings or interdependent settings during concurrent login sessions.

In the context of "panorama managed devices" i think a local configuration lock is a lock placed on a firewall config locally, by logging on to it, rather than logging on to panorama. If any lock placed by another administrator, in panorama or locally on a firewall. Would simply be unlocked by a commit done in panorama by any administrator, it's purpose would be defeated.

B is correct: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CltACAS "When a user has a configuration lock, it is not possible to perform a commit or push a policy from Panorama. If the administrator is not available to remove the lock, a device WebGUI or CLI command can be used by a superuser to force the removal of the configuration lock." A is not correct. You can't perform a commit while a lock is in place, therefore, the lock can't be automatically removed after a commit that you cannot execute.

local locks prevent panorama pushes. they have to be removed by the admin who locked it

B is correct. Once lock from local PA, new policy cant be push from Pano

B is correct. If you trey to push a config to a device with a local local you get the following message: Details: . Other administrators are holding device wide config locks.