Refresh links in "Benefits of Policy as Code" blog post

[alexleventer]

Link maintenance on a 2020 post (content/blog/benefits-of-policy-as-code/index.md) that predates both the CrossGuard docs reorg and the policy-as-code explainer.

Changes

Repoint stale docs links — the /docs/using-pulumi/crossguard/ tree moved to /docs/insights/policy/. The old paths still alias-redirect, but the core-concepts anchor now lands on the Policy Groups page, so the "Policy Packs" link was sending readers to the wrong doc:

• "Policy Packs" → /docs/insights/policy/policy-packs/
• "Policy Group" → /docs/insights/policy/policy-groups/
• Conclusion CTA → /docs/insights/policy/

Connect to the explainer — links the intro's "policies as code" to What is policy as code?. That explainer already links to this post; this completes the pair so readers can reach the definitional overview.

Fix a rendering bug — a stray double paren (...on-aws))) was rendering a literal ) after the link.

Notes

• Stamps lastmod per the blog link-maintenance convention in AGENTS.md.
• All five sibling blog-post links were verified as still live and left as-is.
• Left the post's prose and title-case "Policy as Code" styling untouched — this is scoped to link health, not a content rewrite of a historical post.
• Passes make lint.

🤖 Generated with Claude Code

[github-actions]

Social Media Review

No social copy to review for this PR — the only blog file it touches (content/blog/previous-cli-and-sdk-version-docs/index.md) was deleted, and deleted/filtered posts are skipped by the check.

Updated for commit aae6aafcef3da2413a44829f1c9c97fc60db564b (short: aae6aaf) at $(date -u '+%Y-%m-%d %H:%M UTC').

[pulumi-bot]

Your site preview for commit aae6aaf is ready! 🎉

http://www-testing-pulumi-docs-origin-pr-20212-aae6aafc.s3-website.us-west-2.amazonaws.com

[github-actions]

Pre-merge Review — Last updated 2026-07-13T15:06:43Z

Tip

Summary: This PR refreshes links in the 2020 blog post "Benefits of Policy as Code" — it repoints the old /docs/using-pulumi/crossguard/… doc links to their current /docs/insights/policy/… homes, adds a link to the /what-is/what-is-policy-as-code/ explainer, removes a stray closing parenthesis inside one link, and stamps lastmod. For a link-refresh the failure mode that would hurt a reader is a changed link pointing at a dead target or a stale anchor; every changed link target was checked against the repo and confirmed to resolve (Policy Packs, Policy Groups, the Insights/Policy landing page, the What-is explainer, and the manage-infrastructure-with-pac#controlling-cost-on-aws anchor). lastmod: 2026-07-12 is yesterday's date and is fine. Passes run: full claim verification against the repo and live sources, frontmatter sweep, readthrough coherence, and an editorial-balance check (single-subject, N/A). No PR-introduced blockers; the one contradicted figure and the unverifiable claims all sit on lines this PR does not touch.

Review confidence:

Dimension	Level	Notes
mechanics	HIGH
facts	MEDIUM	1 contradicted + 3 unverifiable, all on pre-existing lines this PR doesn't change
coherence	HIGH

Investigation log

• Cross-sibling reads: not run (not in a templated section)
• External claim verification: 31 of 52 claims verified (3 unverifiable, 1 contradicted) · 4 specialists (numerical, cross-reference, capability, framing); 0 cross-specialist corroborations · routed: 0 inline, 33 Pass 1, 0 Pass 2, 19 Pass 3 (verified 11, contradicted 1, unverifiable 7).
• Cited-claim spot-checks: not run (no cited claims)
• Frontmatter sweep: ran on body + meta_desc (frontmatter parsed OK; no alias/URL collisions)
• Temporal-trigger sweep: not run (no trigger words)
• Code execution: not run (no static/programs/ change)
• Code-examples checks: not run (no fenced code blocks in content files)
• Editorial-balance pass: ran (single-subject, N/A)

🚨 Outstanding	⚠️ Low-confidence	💡 Pre-existing	✅ Resolved
0	3	1	0

🔍 Verification trail

52 claims extracted · 31 verified · 3 unverifiable · 1 contradicted

• L4 in content/blog/benefits-of-policy-as-code/index.md "lastmod: 2026-07-12" → ➖ not-a-claim (evidence: This is a frontmatter lastmod metadata field indicating when the blog post content was last modified, not a falsifiable factual assertion.; source: content/blog/benefits-of-policy-as-code/index.md)
• L4 in content/blog/benefits-of-policy-as-code/index.md "This blog post's content was last modified on 2026-07-12." → ✅ verified (evidence: The file's frontmatter explicitly sets lastmod: 2026-07-12, which matches the claim exactly. Note: 2026-07-12 is yesterday relative to the review date (2026-07-13), so it is a valid lastmod, not a future date.; source: repo:content/blog/benefits-of-policy-as-code/index.md)
• L5 in content/blog/benefits-of-policy-as-code/index.md "An organization can benefit from Policy as Code through cost control, compliance, and best practices." → ✅ verified (evidence: The Pulumi blog post "Benefits of Policy as Code" itself states: "Organizations can realize cost savings, improved compliance, efficient deployments, fine-grained control over infrastructure, and better use of cloud provider native resources," and details cost control, compliance/security, and best-practices sections throughout.; source: https://www.pulumi.com/blog/benefits-of-policy-as-code/)
• L13 in content/blog/benefits-of-policy-as-code/index.md "Policies must be tested against a live system, meaning either using an existing system or configuring and deploying an ephemeral version." → ➖ not-a-claim (evidence: Direct paraphrase of the blog's own text; the author's own contextual framing, not a third-party-attributed falsifiable claim.; source: repo:content/blog/benefits-of-policy-as-code/index.md)
• L13 in content/blog/benefits-of-policy-as-code/index.md "When policies are written with code, you can apply software development practices such as testing, automated deployment, and version control." → ➖ not-a-claim (evidence: General conceptual statement authored by the blog post itself, not a falsifiable third-party assertion.; source: repo:content/blog/benefits-of-policy-as-code/index.md)
• L13 in content/blog/benefits-of-policy-as-code/index.md "Cloud providers typically offer a GUI to create policies." → ➖ not-a-claim (evidence: General background statement about cloud provider tooling used as context, not a specific verifiable product claim.; source: content/blog/benefits-of-policy-as-code/index.md)
• L13 in content/blog/benefits-of-policy-as-code/index.md "Creating policies via a cloud provider GUI is not easily repeatable." → ➖ not-a-claim (evidence: Subjective/rhetorical assertion supporting the blog's thesis, not a falsifiable technical claim about a specific product.; source: content/blog/benefits-of-policy-as-code/index.md)
• L13 in content/blog/benefits-of-policy-as-code/index.md "Writing infrastructure policy in a high-level programming language helps automate and enforce best practices." → ➖ not-a-claim (evidence: General positioning statement expressing the author's opinion, not a falsifiable factual assertion.; source: content/blog/benefits-of-policy-as-code/index.md)
• L15 in content/blog/benefits-of-policy-as-code/index.md "There is a linked page at /what-is/what-is-policy-as-code/ describing what policy as code is." → ✅ verified (evidence: content/what-is/what-is-policy-as-code.md exists at that path and describes what policy as code is ("Policy as code is the practice of defining and enforcing security, compliance, cost, and operational governance rules as version-controlled, testable code..."), matching the linked page's purpose.; source: repo:content/what-is/what-is-policy-as-code.md)
• L15 in content/blog/benefits-of-policy-as-code/index.md "The organizational benefits of policies as code include cost savings, improved compliance, efficient deployments, fine-grained control over infrastructure, and better use of cloud provider native resources." → 🤷 unverifiable (evidence: The claim is the blog post's own summary sentence (not an attributed quote from the linked page). The verifier reported it could not confirm the linked target existed; however a separate check in this same run confirmed content/what-is/what-is-policy-as-code.md does exist — see the 📋 Triaged note.; source: gh api repos/pulumi/docs/contents/content/what-is)
• L21 in content/blog/benefits-of-policy-as-code/index.md "A previous Pulumi article at /blog/manage-infrastructure-with-pac#controlling-cost-on-aws provides an example policy that finds all resources in a deployment and calculates the total monthly cost." → ✅ verified (evidence: content/blog/manage-infrastructure-with-pac/index.md contains a "## Controlling cost on AWS" section (anchor matches) with example policy code that "finds all the instances and validates the aggregate cost against the maximum monthly amount allowed."; source: repo:content/blog/manage-infrastructure-with-pac/index.md)
• L21 in content/blog/benefits-of-policy-as-code/index.md "With pricing data available online, you can calculate the cost of a resource ahead of time and create a policy that limits the amount spent to deploy it." → ✅ verified (framing: exact-match — claim closely paraphrases source's stated cost-control policy concept; evidence: A sibling policy-as-code post states nearly verbatim: "You can calculate the cost of a resource ahead of time and create a policy limiting the amount you spend to deploy it."; source: https://www.pulumi.com/blog/manage-infrastructure-with-pac/ and https://www.pulumi.com/blog/take-control-with-pac/)
• L23 in content/blog/benefits-of-policy-as-code/index.md "Pulumi implemented this serverless-function-based unused-resource cleanup system internally." → ✅ verified (evidence: The published blog post states: "In this article, we show how to use a serverless function to find unused resources daily and shut them down. We implemented this system at Pulumi and reduced our operating costs by 64%."; source: https://www.pulumi.com/blog/benefits-of-policy-as-code/)
• L23 in content/blog/benefits-of-policy-as-code/index.md "An article at /blog/controlling-aws-costs-with-lambda-and-pulumi/ shows how to use a serverless function to find unused resources daily and shut them down." → ✅ verified (evidence: content/blog/controlling-aws-costs-with-lambda-and-pulumi/index.md describes "an AWS Lambda Go application that removes wasteful resources from our AWS accounts daily" and walks through cleaning up unattached EBS volumes, matching the claim.; source: repo:content/blog/controlling-aws-costs-with-lambda-and-pulumi/index.md)
• L23 in content/blog/benefits-of-policy-as-code/index.md "A cloud provider's resources can be used to implement a watchdog function with a policy that cleans up unused resources." → ❌ contradicted (evidence: General illustrative statement about cloud automation concepts, not a specific falsifiable product/third-party claim.; source: repo:content/blog/benefits-of-policy-as-code/index.md)
• L23 in content/blog/benefits-of-policy-as-code/index.md "Pulumi reduced its operating costs by 64% using this system, as described at /blog/controlling-aws-costs-with-lambda-and-pulumi#in-conclusion." → ❌ contradicted (evidence: The cited source, "Controlling AWS Costs with Pulumi and AWS Lambda," describes an AWS Lambda cleanup application and tagging policy but contains no "64%" operating-cost-reduction figure anywhere in its content, including its conclusion. The retrieved text only states things like "To keep our cloud costs down, Pulumi uses an AWS Lambda Go application that removes wasteful resources from our AWS accounts daily" with no quantified savings percentage.; source: https://www.pulumi.com/blog/controlling-aws-costs-with-lambda-and-pulumi/; intuition: A suspiciously specific "64%" figure with no corroborating text in the cited source is a red flag.)
• L25 in content/blog/benefits-of-policy-as-code/index.md "Joe Duffy wrote an article on using tags for cost tracking, automation, and organization in AWS." → ✅ verified (evidence: The Pulumi blog post "Automatically Enforcing AWS Resource Tagging Policies" is credited "Joe Duffy · Posted on Apr 6th, 2020" and states: "AWS publishes best practices for how to tag your resources for cost tracking, automation, and organization."; source: https://www.pulumi.com/blog/automatically-enforcing-aws-resource-tagging-policies/)
• L25 in content/blog/benefits-of-policy-as-code/index.md "Tags are a simple key/value pair applied to a cloud resource." → ✅ verified (evidence: AWS documentation states: "A tag is a key-value pair applied to a resource to hold metadata about that resource," matching the claim.; source: https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html)
• L25 in content/blog/benefits-of-policy-as-code/index.md "Tags let you manage, search, and filter resources." → ➖ not-a-claim (evidence: General, uncontroversial statement about the well-known purpose of cloud resource tags, not a specific falsifiable product claim.; source: general knowledge of cloud resource tagging conventions)
• L27 in content/blog/benefits-of-policy-as-code/index.md "The article at /blog/automatically-enforcing-aws-resource-tagging-policies/ showed how to use a programming language to tag a resource to enable cost tracking by project, stack, and cost center." → ✅ verified (evidence: The linked article exists and demonstrates tagging an S3 bucket with "user:Project", "user:Stack", and "user:Cost Center" tags "that enable cost allocation reporting."; source: repo:content/blog/automatically-enforcing-aws-resource-tagging-policies/index.md)
• L27 in content/blog/benefits-of-policy-as-code/index.md "Joe Duffy demonstrated how to use policy as code to enforce tagging of resources when they are created, at /blog/automatically-enforcing-aws-resource-tagging-policies#defining-our-tags-enforcer-policy." → ✅ verified (evidence: The target post is authored by joe-duffy and contains the exact heading "### Defining our Tags Enforcer Policy" demonstrating policy as code enforcing resource tagging; anchor matches.; source: repo:content/blog/automatically-enforcing-aws-resource-tagging-policies/index.md)
• L27 in content/blog/benefits-of-policy-as-code/index.md "The article enables resources to pass the tagging policy." → ➖ not-a-claim (evidence: Vague paraphrase of the blog's own example content, describing the author's own illustrative example rather than a checkable fact.; source: repo:content/blog/benefits-of-policy-as-code/index.md)
• L31 in content/blog/benefits-of-policy-as-code/index.md "Policy as Code is a way to enforce infrastructure policies that prevent inadvertent access to resources such as databases and storage or to enforce cost policies." → ✅ verified (evidence: The live Pulumi blog post contains this exact sentence verbatim.; source: https://www.pulumi.com/blog/benefits-of-policy-as-code/)
• L33 in content/blog/benefits-of-policy-as-code/index.md "Leaving services open to the internet is less of a problem in production than in other environments." → ✅ verified (evidence: The published blog post states verbatim: "Leaving services open to the internet is less of a problem in production, but what about development environments?" The claim matches this original published sentence; it is the author's own existing framing, not a new PR assertion.; source: https://www.pulumi.com/blog/benefits-of-policy-as-code/)
• L33 in content/blog/benefits-of-policy-as-code/index.md "Developers often have much leeway to deploy resources when building a new application." → ➖ not-a-claim (evidence: General, subjective positioning statement about developer workflows, not a falsifiable assertion.; source: content/blog/benefits-of-policy-as-code/index.md)
• L33 in content/blog/benefits-of-policy-as-code/index.md "Testing environments may be less secure than production." → ➖ not-a-claim (evidence: General opinion/positioning statement common in security literature, not a falsifiable factual claim.; source: N/A - not-a-claim)
• L33 in content/blog/benefits-of-policy-as-code/index.md "Development instances may remain inadvertently available long after they have been used for development." → ➖ not-a-claim (evidence: General illustrative statement/opinion used to motivate the value of policy as code, not a falsifiable factual assertion.; source: content/blog/benefits-of-policy-as-code/index.md)
• L35 in content/blog/benefits-of-policy-as-code/index.md "Policies that run at the organization level can mitigate the likelihood of unauthorized access to resources or data breaches." → ➖ not-a-claim (evidence: Direct paraphrase of the author's own blog content ("Policies that run at the level of the organization can mitigate the likelihood of unauthorized access to resources or even data breaches"), not a third-party assertion.; source: repo:content/blog/benefits-of-policy-as-code/index.md)
• L35 in content/blog/benefits-of-policy-as-code/index.md "Policy as Code can enforce best practice across the organization regardless of the type of environment (dev, test, or production)." → ✅ verified (evidence: Line 35 states: "Regardless of the type of environment, whether its dev, test, production, Policy as Code can enforce best practice across the organization." Faithful paraphrase.; source: repo:content/blog/benefits-of-policy-as-code/index.md)
• L35 in content/blog/benefits-of-policy-as-code/index.md "Controlling ingress and egress to and from resources and not exposing them on the internet is a best practice." → ➖ not-a-claim (evidence: General, well-established cloud security best-practice statement, not a specific falsifiable assertion.; source: General security best-practice knowledge (e.g., CIS Benchmarks, AWS/Azure Well-Architected guidance))
• L37 in content/blog/benefits-of-policy-as-code/index.md "CVE-2020-8835 allows container escape to get root privileges on the host node." → ✅ verified (evidence: CVE record confirms: "This flaw allows an unprivileged user or process to execute eBPF programs to crash the kernel, resulting in a denial of service or potentially gaining root privileges on the system." Other sources cite CVE-2020-8835 among eBPF verifier bugs enabling container escape to host.; source: https://notcve.org/cve/CVE-2020-8835)
• L37 in content/blog/benefits-of-policy-as-code/index.md "On Google Cloud, nodes running Ubuntu with Kubernetes 1.16 and 1.17 were affected by CVE-2020-8835." → 🤷 unverifiable (evidence: CVE-2020-8835 is documented as a general Linux-kernel eBPF verifier privilege-escalation flaw affecting Ubuntu 18.04 LTS and 19.10 (per Ubuntu's advisory and SentinelOne), not as a Kubernetes-version-specific or GKE-specific issue tied to "Kubernetes 1.16 and 1.17." Ubuntu's advisory mentions no GKE or specific Kubernetes minor versions.; source: https://ubuntu.com/security/CVE-2020-8835; intuition: Claim ties a generic Linux-kernel CVE to specific Kubernetes minor versions and a specific cloud provider — reads like invented specificity. WebSearch dispatched but verification did not converge within the turn budget.)
• L37 in content/blog/benefits-of-policy-as-code/index.md "You can write a policy that checks the GKE version and prevents vulnerable versions from being deployed." → ➖ not-a-claim (evidence: The author's own illustrative example of Policy as Code capability, describing a generic use case rather than a falsifiable third-party assertion.; source: repo:content/blog/benefits-of-policy-as-code/index.md)
• L41 in content/blog/benefits-of-policy-as-code/index.md "When Pulumi's deployment engine creates the preview, it also tests whether resources are compliant with the included policies." → ✅ verified (evidence: Paraphrases the blog's own text: "A feature of Pulumi's deployment engine is that it constructs a preview of the resource graph. When it creates the preview, it also tests if resources are compliant with the included policies." Matches Pulumi CrossGuard's documented preview-enforcement behavior.; source: repo:content/blog/benefits-of-policy-as-code/index.md (L41))
• L41 in content/blog/benefits-of-policy-as-code/index.md "Pulumi policies are run before a resource is registered, and resource inputs (configuration parameters) are validated at that time." → ✅ verified (evidence: The blog states: "The policies are run before a resource is registered, and inputs (configuration parameters) are validated. Out-of-compliance resources are blocked from being created or modified by the policy." Matches CrossGuard's documented architecture.; source: repo:content/blog/benefits-of-policy-as-code/index.md (L41))
• L41 in content/blog/benefits-of-policy-as-code/index.md "Pulumi validates inputs (configuration parameters) as part of policy checks." → ✅ verified (evidence: The blog states inputs (configuration parameters) are validated as part of policy checks; reflects CrossGuard's known behavior.; source: repo:content/blog/benefits-of-policy-as-code/index.md L41)
• L41 in content/blog/benefits-of-policy-as-code/index.md "Out-of-compliance resources are blocked from being created or modified by Pulumi's policy engine." → ✅ verified (evidence: Pulumi's policy-packs docs confirm "Configurable enforcement levels (advisory, mandatory, disabled)" — with mandatory enforcement, CrossGuard blocks resource creation/modification on a failed policy check, consistent with the blog.; source: repo:content/docs/insights/policy/policy-packs/_index.md)
• L41 in content/blog/benefits-of-policy-as-code/index.md "A shortcoming of using a cloud provider GUI to create policies is that they can only be tested on deployed resources." → 🤷 unverifiable (evidence: The blog author's own argument/framing (not attributed to an external source) contrasting cloud GUI policy tools with Pulumi's preview-based validation. No single authoritative third-party source confirms or denies this broad generalization about GUI-based cloud policy tools.; source: repo:content/blog/benefits-of-policy-as-code/index.md; intuition: Broad generalization about "cloud provider GUI" policy tools across all providers — plausible but not confirmable from a single authoritative source.)
• L43 in content/blog/benefits-of-policy-as-code/index.md "The Pulumi engine supports testing either the entire stack or selected resources for policy compliance." → ✅ verified (evidence: The linked sibling article confirms Pulumi CrossGuard has two policy types — "ResourceValidationPolicy - Validates a particular resource in a stack" and "StackValidationPolicy - Validates the stack as a whole."; source: repo:content/blog/enforcing-different-kinds-of-policies-for-cloud-resources/index.md)
• L43 in content/blog/benefits-of-policy-as-code/index.md "You can run policies against a stack as a whole, and stack-level validation will not prevent resources that are out of compliance from being created." → ✅ verified (evidence: The cited source states: "Policies of StackValidationPolicy are run against the stack as a whole. These policies are run after all stack resources are registered and thus do not block an out-of-compliance resource from being created or modified, but do fail the preview or update."; source: repo:content/blog/enforcing-different-kinds-of-policies-for-cloud-resources/index.md)
• L49 in content/blog/benefits-of-policy-as-code/index.md "Policy Packs are described at /docs/insights/policy/policy-packs/ and provide a way to group similar policies based on how you manage your infrastructure." → ✅ verified (evidence: content/docs/insights/policy/policy-packs/_index.md exists at /docs/insights/policy/policy-packs/ and states policy packs are "collections of rules that enforce compliance and best practices across your infrastructure," confirming the grouping described in the blog.; source: repo:content/docs/insights/policy/policy-packs/_index.md)
• L49 in content/blog/benefits-of-policy-as-code/index.md "Policy Packs do not restrict which policies you can combine; for example, Kubernetes policies can be bundled with container registry policies." → ✅ verified (evidence: The blog states: "Policy packs don't restrict which policies you combine; you can have Kubernetes policies bundled with container registry policies." Matches Pulumi's Policy Pack design (a PolicyPack is a collection of Policy objects with no resource-type restriction).; source: content/blog/benefits-of-policy-as-code/index.md:49)
• L49 in content/blog/benefits-of-policy-as-code/index.md "All cloud providers offer a set of best practices for deploying resources." → ➖ not-a-claim (evidence: General, well-known industry scene-setting statement (AWS Well-Architected, Azure CAF, GCP best practices) used before introducing Policy Packs, not a falsifiable claim about the cited page.; source: content/blog/benefits-of-policy-as-code/index.md)
• L51 in content/blog/benefits-of-policy-as-code/index.md "A group of stacks that use the same Policy Pack is called a Policy Group, as described at /docs/insights/policy/policy-groups/." → ✅ verified (evidence: content/docs/insights/policy/policy-groups.md (resolves to /docs/insights/policy/policy-groups/) exists and states: "Policy groups organize one or more policy packs and apply them to specific stacks or cloud accounts," confirming the concept.; source: gh api repos/pulumi/docs/contents/content/docs/insights/policy/policy-groups.md)
• L53 in content/blog/benefits-of-policy-as-code/index.md "You can apply Policy Packs on individual resource stacks or across multiple stacks as Policy Groups." → ✅ verified (evidence: Docs state: "Policy groups apply policy packs to specific stacks or cloud accounts," confirming Policy Packs can be applied to individual stacks or across multiple stacks via Policy Groups.; source: repo:content/docs/insights/policy/_index.md and repo:content/docs/insights/policy/get-started.md)
• L57 in content/blog/benefits-of-policy-as-code/index.md "Cloud providers have methods for managing access to resources such as IAM (Identity Access and Management) policies and ACL (Access Control Lists)." → ➖ not-a-claim (evidence: General, well-established industry knowledge about cloud access-control mechanisms, not a specific falsifiable product claim.; source: general knowledge)
• L57 in content/blog/benefits-of-policy-as-code/index.md "The Pulumi engine works with cloud provider resources in conjunction with Policy as Code." → ✅ verified (evidence: The article states the deployment engine builds a preview and "tests if resources are compliant with the included policies... Out-of-compliance resources are blocked from being created or modified," corroborating that the engine works in conjunction with Policy as Code.; source: repo:content/blog/benefits-of-policy-as-code/index.md (lines 41, 57))
• L59 in content/blog/benefits-of-policy-as-code/index.md "IAM Access Analyzer creates a record for each problem identified and shows which policy is responsible for granting wider access to resources than would be best practice." → 🤝 matches (evidence: The cited previous Pulumi blog (aws-iam-access-analyzer-and-crossguard) states: 'For each problem it identifies, it creates a so-called "finding" which records what policy is responsible for granting wider access to specific resources than you might want' — faithful paraphrase (record ≈ finding).; source: repo:content/blog/aws-iam-access-analyzer-and-crossguard/index.md)
• L59 in content/blog/benefits-of-policy-as-code/index.md "AWS IAM Access Analyzer creates a record for each problem identified and shows which policy is responsible for granting wider access to resources than would be best practice." → ✅ verified (framing: strengthened — the claim frames findings as flagging access "wider than best practice," while AWS docs describe findings as flagging any access granted outside the defined "zone of trust"; the source's broader framing still supports the claim's gist; evidence: AWS docs confirm: "For each instance of a resource shared outside of your account, IAM Access Analyzer generates a finding" with details on the resource, external entity, and permissions granted.; source: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
• L61 in content/blog/benefits-of-policy-as-code/index.md "The IAM Access Analyzer works on deployed resources, requiring infrastructure to be deployed first before running the analyzer using a Pulumi program." → ✅ verified (framing: strengthened — AWS also offers a "preview access" API for not-yet-deployed resources, but the standard workflow (deploy first, then analyze) matches AWS's core documented behavior; evidence: AWS docs: "Once enabled, IAM Access Analyzer analyzes the policies applied to all of the supported resources in your zone of trust," generating findings for resources already sharing access externally.; source: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
• L61 in content/blog/benefits-of-policy-as-code/index.md "When the scan of a resource is complete, the IAM Access Analyzer returns detailed results that can be passed to the policy for validation." → ✅ verified (evidence: AWS docs confirm IAM Access Analyzer generates detailed findings after scanning, which can be reviewed/used for validation (including custom policy checks in CI/CD).; source: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
• L73 in content/blog/benefits-of-policy-as-code/index.md "There is a docs page at /docs/insights/policy/ for learning more about using programming languages for Policy as Code." → ✅ verified (evidence: content/docs/insights/policy/_index.md exists at /docs/insights/policy/ and includes a "Languages" section: "Policies can be written in TypeScript/JavaScript (Node.js), Python, or OPA (Rego)," matching the claim.; source: repo:content/docs/insights/policy/_index.md)

📊 Editorial balance

Single-subject post; balance check N/A.

🚨 Outstanding in this PR

No outstanding issues in this PR.

⚠️ Low-confidence

Review each and resolve as appropriate — these don't block the PR.

• [L37] content/blog/benefits-of-policy-as-code/index.md — "On Google Cloud, nodes running Ubuntu with Kubernetes 1.16 and 1.17 were affected by CVE-2020-8835." — The verification step couldn't confirm this version/provider specificity: CVE-2020-8835 is documented as a general Linux-kernel eBPF privilege-escalation flaw (Ubuntu 18.04 LTS / 19.10 per Ubuntu's advisory), not something primary sources tie to GKE or Kubernetes 1.16/1.17 specifically. This is pre-existing prose on a line this PR doesn't touch, so it doesn't gate the link refresh — but if you have a source that ties the CVE to those GKE/Kubernetes versions, worth citing it; otherwise consider loosening the specificity.

• [L41] content/blog/benefits-of-policy-as-code/index.md — "A shortcoming of using a cloud provider GUI to create policies is that they can only be tested on deployed resources." — This reads as the post's own argument rather than a sourced fact, so it can't be confirmed against an authoritative source. It's a broad generalization across all cloud-provider GUI policy tools; pre-existing on a line this PR doesn't touch. If you want it to hold up as a general claim, consider attributing or narrowing it.

Style findings

Found by pattern-based linting; Findings may be false positives.

• line 49: [style] weasel word — 'several' is a weasel word!

📋 Triaged verifier findings

I double-checked these and realized they weren't real findings — click to expand

• [L15] content/blog/benefits-of-policy-as-code/index.md — "The organizational benefits of policies as code include cost savings, improved compliance, efficient deployments, fine-grained control over infrastructure, and better use of cloud provider native resources." — Mis-sourced: The verification step marked this unverifiable partly because it reported the newly-added link target /what-is/what-is-policy-as-code/ didn't exist. It does — content/what-is/what-is-policy-as-code.md resolves at that path and describes policy as code (confirmed separately in this same run and via the repo). The sentence itself is the post's own summary of the benefits it then details, so there's nothing broken: the added link resolves and the summary is the author's own framing.

💡 Pre-existing issues in touched files (optional)

• [L23] content/blog/benefits-of-policy-as-code/index.md — "...We implemented this system at Pulumi and reduced our operating costs by 64%." — Pre-existing: This 64% figure and its link sit on a context line this PR doesn't modify (the PR refreshes other links in the post). The figure does appear in the published post itself, but the linked article, "Controlling AWS Costs with Pulumi and AWS Lambda," contains no "64%" figure anywhere — including its conclusion — so the number is attributed to a source that doesn't state it. Worth reconciling in a follow-up: either cite where the 64% comes from or soften the attribution.

✅ Resolved since last review

No items resolved since the last review.

📜 Review history

• 2026-07-13T15:06:43Z — Link-refresh PR: all updated CrossGuard→/docs/insights/policy/ links, the new /what-is/what-is-policy-as-code/ link, and the stray-paren fix resolve; flagged a pre-existing unsourced "64%" figure and two pre-existing unverifiable claims. (aae6aaf)

---

Need a re-review? Want to dispute a finding? Mention @claude and include #update-review.
(For ad-hoc questions or fixes, just @claude — no hashtag.)

[CamSoper]

Automated rubber stamp approval applied

---

Generated by Claude Code