Might or Might Not
An application whitelisting technology might be considered unsuitable if, for instance, it had to be disabled in order to install security updates for the operating system or particular applications.
If set up properly, it should in fact block whatever does not fit a predefined pattern of behavior (including information about the installing user ID, source of install files, target of the install, temp directory used, et cetera). Unfortunately, the people who put together patches have a habit of changing many things a signature may be based upon from version to version which cause the white listed app's update to fail. This can be avoided by implementation of proper dev and test environments and verifying each new application and patch in them. Unfortunately, the need for setting up said environments in shops that do not have them prior to implementing white listing typically will lead to less than desirable outcomes.
Also, there will always be one-off applications in any organization. Rather than set up rules for all aspects of these, it is typically acceptable to turn off blocking, run the installation, turn logging on to make sure the app can run and then go back to blocking as normal*. This is in contrast to enterprise standard applications that should have rules created for both installation and patching.
* Based experience with McAfee's HIPS.