就应用程序池的安全性而言，我们必须保证 w3wp.exe 工作进程可以读取 IIS 配置数据，因为这是 w3wp.exe 工作进程正常工作的基础。w3wp.exe 工作进程必须能够读取其所服务的网站的 IIS 设置。这意味着 w3wp.exe 工作进程必须对 applicationHost.config 文件中配置的大多数内容具有 Read 访问权限。问题是：如果每个应用程序池都可以读取整个配置文件，那么，配置文件中的所有信息就都暴露给每一个应用程序池了。因此，我们必须确保：就 applicationHost.config 文件中的整体内容而言，不允许每一个应用程序池都具有对这些整体内容的 Read 权限或 Write 权限。否则，某些用户就可以获取对敏感信息的访问权限。
为了解决这个问题，IIS 开发团队提出了一种方法，允许 w3wp.exe 工作进程读取与其有关的所有设置，但是同时又不需要访问其他应用程序的信息，也不能访问敏感的全局设置数据，这样就能够在不同的应用程序工具之间做到完全的配置隔离。
当应用程序池第一次启动时，Windows Process Activation Service（WAS）仅获得与该应用程序池有关的信息，并且在 C:\inetpub\temp\appPools\ 目录下创建了一个临时文件夹，为这个应用程序池设置 ACL，然后将信息保存在这个临时文件夹中。下图显示了这个保存了 WCF.Inventory.config 文件的文件夹。

.config 文件中的数据大多数与 applicationHost.config 文件中的数据相同，但是没有保存任何其他应用程序池中的 Web 网站信息。我们没有必要在 .config 文件中保存其他应用程序池中的 Web 网站信息，因为w3wp.exe 工作进程是由 WAS 管理的，而且 w3wp.exe 工作进程也不需要使用自身的信息。
如果与该文件有关的数据发生了变更，那么这个临时文件也会随之更新，否则，这个文件就一直保存在上述目录中，直到 IIS 停止运行。如果我们删除这个文件，那么 IIS 将无法正常执行该应用程序池的功能，所有与该应用程序池有关的操作都会发生失效，并且仅当 IIS 重启后，在重新生成这个被删除的文件之后，这个问题才能得到解决。如果我们仅仅是回收这个应用程序池，那么这个被删除的文件不会被重新生成，因此无法解决这个问题。所以，除非错误定位时必须使用这些文件，并且确实能够理解这些文件的功能和各种方式，否则最好不要对这些文件进行操作。
在 IIS 7.0 中创建临时文件的整个过程都是全新开发的，从而确保了一个应用程序池中的恶意代码无法从应用程序池中读取敏感配置数据。