[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-11。"],[],[],null,["# Policy Simulator for deny policies\n\n| **Preview**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\n\u003cbr /\u003e\n\nPolicy Simulator for deny policies lets you see how a change to an\nIAM [deny policy](/iam/docs/deny-overview) might affect a principal's\naccess before you commit to making the change. You can use\nPolicy Simulator to ensure that the changes you're making won't cause a\nprincipal to lose access that they need.\n\nThis feature only evaluates deny policies. To learn how to simulate other policy\ntypes, see the following:\n\n- [Policy Simulator for organization policies](/policy-intelligence/docs/test-organization-policies)\n- [Policy Simulator for allow policies](/policy-intelligence/docs/iam-simulator-overview)\n- [Policy Simulator for principal access boundary policies](/policy-intelligence/docs/pab-simulator-overview)\n\nHow Policy Simulator for deny policies works\n--------------------------------------------\n\nPolicy Simulator for deny policies helps you determine whether a change\nto a deny policy will block access that your principals are using.\n\nWhen you run a simulation for a deny policy, Policy Simulator does the\nfollowing:\n\n1. Retrieves access logs for the organization that were generated during the\n [replay period](#replay-period). The replay period is 90 days.\n\n If the organization has not existed for more than\n 90 days, then Policy Simulator retrieves all\n access logs since the organization was created.\n2. Determines which access logs are relevant to the simulation. Relevant access\n logs are all access logs that represent a principal's most recent attempt to\n use a permission to access a resource.\n\n3. For each relevant access log, determines whether the current\n deny policies, along with the proposed changes,\n would permit the attempted access. This process is called *replaying* the\n access attempts.\n\n4. For each access log, compares the access state from the replay with the\n access state in the access logs. Then, Policy Simulator reports any\n historical access attempts that weren't blocked in the access log, but were\n blocked in the replay. These differences, which are called\n *access changes*, show which access attempts would have been blocked if the\n simulated deny policy had been in place at the time of the attempt.\n\n | **Note:** The access state in an access log might not reflect the current access state. In these cases, Policy Simulator always compares the results of the replay to the result from the access log, *not* to the current access state.\n\n### Replay period\n\nThe replay period is the time period that Policy Simulator gets access\nlogs for when running a simulation. Access logs that occur before the first day\nof the replay period or after the last day of the replay period aren't included\nin the simulation.\n\nTypically, the last day of the replay period is\n1 day prior to the simulation. However, in\nsome cases, the last day of the replay period can be up to\nup to 10 days prior to the simulation. Access logs\nthat occur after the last day of the replay period aren't included in the\nsimulation.\n\nThe replay period is 90 days. If the organization has not existed\nfor more than 90 days, then Policy Simulator retrieves all\naccess attempts since the organization was created.\n\nThe replay window is also [eventually consistent](https://en.wikipedia.org/wiki/Eventual_consistency). This\nmeans that, when you run a simulation, some data might be fresher than other\ndata. However, eventually, all the data will have the same freshness.\n\nPolicy Simulator results\n------------------------\n\nPolicy Simulator reports the impact of a proposed change to a\ndeny policy as a list of *access changes* . For deny policies, the only type of\naccess change that Policy Simulator reports is the **Access revoked**\naccess change.\n\nPolicy Simulator reports that access is revoked if the following are\ntrue:\n\n- The principal's most recent attempt to access the resource was successful\n- The proposed changes or another deny policy block the principal's access to the resource\n\nFor each access change, Policy Simulator also reports the following\ninformation:\n\n- The principal, resource, and permission involved in the access attempt.\n- The number of days during the replay period that the principal tried to use the permission to access the resource. This total includes only the access attempts that have the same result as the most recent access attempt.\n- The date of the most recent access attempt.\n\nErrors\n------\n\nThe following errors can cause a simulation to fail:\n\n- **Maximum concurrent simulations exceeded**: The user already has 10 in-progress simulations, which is the maximum number of in-progress simulations that a user can have. To resolve, wait for one of the in-progress simulations to complete, then try running the simulation again.\n- **Timeout**: The simulation took too long to run and timed out. To resolve, try running the simulation again.\n- **Invalid simulation construction**: The proposed deny policy is invalid. For example, the proposed policy has an invalid condition expression. To resolve, correct the policy and try again.\n- **Permission denied** : You don't have permission to run a simulation. To resolve, ensure that you're granted the [required roles](/policy-intelligence/docs/simulate-deny-policies#required-roles) and try again.\n\nSupported principal types\n-------------------------\n\nPolicy Simulator for deny policies only reviews access\nlogs for the following types of principals:\n\n- Google Workspace Accounts\n- Service accounts\n- Service agents\n\nWhen simulating deny policies, Policy Simulator doesn't review access\nlogs for any other principal types, including those based on federated\nidentities in a workload identity pool. As a result, Policy Simulator\ndoesn't report whether the proposed changes to your policies or bindings affect\nthose principals' access.\n\nWhat's next\n-----------\n\n- Learn how to [simulate a change to a deny policy](/policy-intelligence/docs/simulate-deny-policies).\n- Explore other [Policy Intelligence tools](/policy-intelligence/docs/overview)."]]