content(what-is): expand the GitHub Actions secret explainer by alexleventer · Pull Request #19263 · pulumi/docs

alexleventer · 2026-05-20T16:46:01Z

Summary

Rewrites content/what-is/what-is-a-github-action-secret.md for SEO and AEO. The previous page led with a generic GitHub Actions intro and a single tutorial; the new version covers the three secret scopes, libsodium encryption, OIDC as a stored-secret alternative, and the specific limits engineers ask about (64 KB, 1,000 secrets per repo, no rotation).

What changed

Opening definition — bolded one-sentence definition (encrypted variable, scoped to repo/environment/org, redacted from logs, withheld from forked PRs), followed by an explicit note on libsodium and OIDC as a modern alternative.
Use cases — concrete list (cloud credentials, registry tokens, deploy tokens, third-party APIs, signing keys, Pulumi access tokens).
Scope table — repository vs. environment vs. organization with where to define, who can read, and best-fit use cases.
Encryption table — six-stage breakdown (submission, storage, delivery, runner, logs, post-job).
Workflow access — YAML example, caveats on forked PRs, composite/reusable workflows, and GITHUB_TOKEN.
Limits — 64 KB per secret, 1,000 per repo, 100 per env, 1,000 per org, no native rotation, no fine-grained access within a repo, no versioning.
OIDC section — comparison table (stored secret vs. OIDC + cloud role) and where each fits.
Best practices — prefer OIDC, scope to environments, smallest scope possible, use GITHUB_TOKEN, don't echo secrets, block forked-PR access, rotate.
Pulumi section — YAML example using pulumi/auth-actions and pulumi/actions with OIDC and Pulumi ESC.
FAQ — ten doubt-removers (encryption, where to add, size limit, count limits, forked PRs, log redaction limits, OIDC, cross-repo sharing, GITHUB_TOKEN, rotation).
Cross-links — secrets management, CircleCI/Cloudflare secrets, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault.

Test plan

make serve; visit /what-is/what-is-a-github-action-secret/ and confirm tables and code blocks render
Spot-check cross-links (/docs/iac/packages-and-automation/continuous-delivery/github-actions/, /product/esc/)
CI lint + pinned review

🤖 Generated with Claude Code

github-actions · 2026-05-20T17:00:36Z

Pre-merge Review — Last updated 2026-05-20T16:52:02Z

Tip

Summary: Despite the title, this PR expands three what-is SEO pages — the GitHub Actions secret explainer (the headline change), plus the DynamoDB vs Bigtable comparison and the aws sts get-caller-identity dynamic-credentials walkthrough. Reader-blocking risk is concentrated in factual claims: the GitHub Actions limits (size and per-scope counts) are stated incorrectly in both the body and the FAQ; the secret-encryption description has the decrypt boundary in the wrong place; several Bigtable claims have aged out (GoogleSQL "in preview", backups exportable to Cloud Storage); and the STS MaxSessionDuration description swaps the role-chaining and OIDC caps. The verifier ran a 150-claim external sweep (with frontmatter + temporal-trigger + code-examples passes); cross-sibling reads and editorial-balance were skipped (not a templated section, not a blog).

Review confidence:

Dimension	Level	Notes
mechanics	HIGH
facts	LOW	15 contradicted claims surfaced — most are clear factual errors with authoritative-source citations; several upstream-aged claims (GoogleSQL preview, GitHub limits) need refreshing.
code correctness	HIGH	No `static/programs/` changes; in-page YAML/TS snippets are illustrative and self-consistent.

Investigation log

Cross-sibling reads: not run (not in a templated section — content/what-is/ pages are individually structured)
External claim verification: 101 of 150 claims verified (16 unverifiable, 18 contradicted) · 4 specialists (numerical, cross-reference, capability, framing); 0 cross-specialist corroborations · routed: 0 inline, 98 Pass 1, 0 Pass 2, 52 Pass 3 (verified 32, contradicted 14, unverifiable 6).
Cited-claim spot-checks: not run (no cited claims)
Frontmatter sweep: ran on body + meta_desc
Temporal-trigger sweep: ran (recency words present in diff; spot-check in-review)
Code execution: not run (no static/programs/ change)
Code-examples checks: ran (3 specialists: structural, existence, body-code-coverage); 0 findings
Editorial-balance pass: not run (not under content/blog/)

🚨 Outstanding	⚠️ Low-confidence	💡 Pre-existing	✅ Resolved
15	43	0	0

🔍 Verification trail

150 claims extracted · 101 verified · 16 unverifiable · 18 contradicted

L32 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB is built for high-throughput transactional applications with predictable low latency." → ✅ verified (evidence: The file at L32 contains the exact sentence: "DynamoDB is built for high-throughput transactional applications with predictable low latency, while Bigtable is built for very large analytical and time-series tables that need consistent, low…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L32 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable is built for very large analytical and time-series tables that need consistent, low-latency reads at petabyte scale." → ✅ verified (framing: strengthened — the file's own summary ("optimized for petabyte-scale analytical, IoT, and time-series workloads") is broader; the claim narrows it to "consiste…; evidence: The PR's own file confirms Bigtable is "optimized for petabyte-scale analytical, IoT, and time-series workloads," the scalability table shows "Petabytes per instan[ce]," and the consistency section states "Bigtable provides strong consiste…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L32 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Amazon DynamoDB is a fully-managed, serverless key-value and document database from AWS, optimized for single-digit-millisecond access at any scale." → ➖ not-a-claim (evidence: The text at L32 is the PR author's own introductory description of Amazon DynamoDB in the article they are writing. The /tutorials/glossary/nosql/ source hint is a link used in the same sentence for the word "NoSQL," not a citation for t…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L53 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable supports GoogleSQL (in preview) as a query interface." → ❌ contradicted (framing: shifted — the claim's "(in preview)" qualifier is outdated; GoogleSQL for Bigtable appears to have moved past preview status based on current official document…; evidence: (escalated from pass1) Google Cloud's official docs (last updated May 2026) confirm Bigtable supports GoogleSQL as a query interface, but no longer label it as "in preview." The August 2024 blog post noted "During this Preview phase," sugg…; source: https://docs.cloud.google.com/bigtable/docs/googlesql-overview)
L54 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB reads are eventually consistent by default, with an option to request strongly consistent reads." → ✅ verified (evidence: The file at the relevant section states: "DynamoDB reads are eventually consistent by default, with an option to request strongly consistent reads (at higher cost and slightly higher latency)." This matches the claim exactly and is con…; source: content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L54 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable provides strong consistency within a single cluster." → ✅ verified (evidence: The file itself states in the at-a-glance table "Strong within a single cluster" for Bigtable's consistency, and the detailed section reads: "Bigtable provides strong consistency for reads and writes within a single cluster. Multi-clus…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L55 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable supports single-row atomic operations only and does not support multi-item (cross-row or cross-table) transactions." (also L98, L222) → ✅ verified (evidence: The file at the referenced lines states: "Bigtable supports single-row atomic operations — including read-modify-write and check-and-mutate — but does not offer cross-row or cross-table transactions." The comparison table also confirms…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L55 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB supports ACID transactions across up to 100 items." → ✅ verified (evidence: (escalated from pass1) The official AWS DynamoDB developer docs confirm: "TransactWriteItems is a synchronous and idempotent write operation that groups up to 100 write actions in a single all-or-nothing operation." The AWS blog also notes…; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transaction-apis.html)
L55 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable supports single-row atomic operations only, not multi-row or multi-table transactions." → ✅ verified (evidence: The file at L55 (at-a-glance table) states Bigtable transactions are "Single-row atomic only," and the detailed Consistency and Transactions section confirms: "Bigtable supports single-row atomic operations — including read-modify-write an…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L56 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Both DynamoDB and Bigtable target single-digit-millisecond p99 latency for well-designed workloads." (also L103) → ✅ verified (framing: strengthened — AWS officially claims single-digit ms performance generally (not specifically p99), but real-world AWS data shows p99 ~9.5ms (within single digi…; evidence: (escalated from pass1) Bigtable: Google Cloud blog explicitly states "at the 99th percentile, you can perform single-digit millisecond queries." DynamoDB: AWS states it "delivers consistent single-digit millisecond performance at any scale…; source: https://cloud.google.com/blog/products/databases/new-features-for-cloud-bigtable-observability/ ; https://aws.amazon.com/blogs/database/how-global-payments-inc-improved-their-tail-latency-using-request-hedging-with-amazon-dynamodb/)
L57 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB pricing model is on-demand per request or provisioned RCU/WCU." → ✅ verified (evidence: The at-a-glance comparison table in the file states DynamoDB's pricing model as "On-demand per request, or provisioned RCU/WCU", which exactly matches the claim. The pricing section further elaborates: "DynamoDB charges per request and per…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L57 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable pricing model is per-node-hour plus storage." → ✅ verified (evidence: The file at L57 (at-a-glance table) states Bigtable's pricing model is "Per-node-hour plus storage," and the Pricing model section further confirms: "Bigtable charges per node-hour and per GB stored."; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L58 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable has a maximum row size of 256 MB per row, with a recommended maximum of less than 100 MB." (also L80, L134-135) → ✅ verified (evidence: Google Cloud Bigtable official docs confirm both figures: "Make sure that data in a single row doesn't exceed 256 MB" (hard limit) and "Keep the size of all values in a single row under 100 MB" (recommended maximum), per cloud.google.com/b…; source: https://cloud.google.com/bigtable/docs/schema-design)
L59 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB supports global distribution via Global Tables with multi-region active-active replication." → ✅ verified (evidence: The file's at-a-glance comparison table explicitly states DynamoDB's global distribution is "Global Tables (multi-region active-active)", and the surrounding content at L59 confirms this characterization. This matches the well-known AWS Dy…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L60 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB is serverless." → ✅ verified (evidence: The file's own at-a-glance table states "Serverless | Yes | No (node-based clusters; autoscaling available)" for DynamoDB vs Bigtable, and the opening paragraph describes DynamoDB as "a fully-managed, serverless key-value and document data…; source: content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L60 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable is not serverless — it uses node-based clusters, though autoscaling is available." → ✅ verified (evidence: The file's at-a-glance comparison table explicitly states for Bigtable under "Serverless": "No (node-based clusters; autoscaling available)", which directly matches the claim. The pricing section also confirms Bigtable charges "Per node-ho…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L60 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB is serverless (Yes)." → ✅ verified (evidence: The at-a-glance comparison table in the file explicitly lists "Serverless | Yes | No (node-based clusters; autoscaling available)" for DynamoDB vs Bigtable, confirming DynamoDB is serverless (Yes).; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L69 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB supports secondary indexes (local and global) to query on non-key attributes." → ✅ verified (evidence: The file at the relevant section states: "Secondary indexes (local and global) make it possible to query on non-key attributes." This is an exact match to the claim.; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L69 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB stores items in tables, where every item has a primary key that can be a single partition key or a partition key plus a sort key." → ✅ verified (evidence: AWS official DynamoDB docs confirm: "DynamoDB supports two different kinds of primary keys: 1- Partition key 2- Partition key and sort key." Items are stored in tables and every item has a primary key that is either a single partition key…; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html)
L69 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB supports document storage up to 400 KB per item." → ✅ verified (evidence: AWS official documentation confirms: "The maximum item size in DynamoDB is 400 KB, which includes both attribute name binary length (UTF-8 length) and attribute value lengths."; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Constraints.html)
L73 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable stores data in a single, massive sparse, sorted, distributed map where rows are keyed by a single row key (a byte string) and sorted lexicographically." → ✅ verified (evidence: The file at the Bigtable data model section reads: "Bigtable stores data in a single, massive sparse, sorted, distributed map: rows are keyed by a single row key (a byte string) and sorted lexicographically." This is an exact match to…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L73 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "In Bigtable, each row contains column families, each family contains columns, and each cell can hold multiple timestamped versions." → ✅ verified (evidence: The file at the Bigtable data model section (around L73) states verbatim: "Each row contains column families, each family contains columns, and each cell can hold multiple timestamped versions." This accurately describes Bigtable's hierarc…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L73 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable has no secondary indexes — query patterns are designed around the row-key layout." → ✅ verified (evidence: The file at the relevant section states: "There are no secondary indexes — query patterns are designed around the row-key layout." The comparison table also confirms Bigtable secondary indexes as "None — design row keys for access patterns…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L80 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "| Document support | Native (lists, maps) up to 400 KB | Not document-oriented; rows hold many columns |" → ✅ verified (evidence: AWS official documentation confirms: "The maximum item size in DynamoDB is 400 KB, which includes both attribute name binary length (UTF-8 length) and attribute value lengths." DynamoDB natively supports List and Map data types (document-s…; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Constraints.html)
L88 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB reads are eventually consistent by default, with an option to request strongly consistent reads at higher cost and slightly higher latency." → ✅ verified (evidence: AWS official docs confirm: "Eventually consistent is the default read consistent model for all read operations." Strongly consistent reads are available on-request at higher cost ("Eventually consistent reads are half the cost of strongly…; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html)
L92 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable provides strong consistency for reads and writes within a single cluster." → ✅ verified (evidence: The file at the relevant section states: "Bigtable provides strong consistency for reads and writes within a single cluster." This is also reflected in the at-a-glance table: "Strong within a single cluster." This is consistent with Go…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L92 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable supports single-row atomic operations including read-modify-write and check-and-mutate." → ✅ verified (evidence: The file at the relevant section states: "Bigtable supports single-row atomic operations — including read-modify-write and check-and-mutate — but does not offer cross-row or cross-table transactions." This matches the claim exactly. Re…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md (Bigtable consistency section))
L92 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable does not offer cross-row or cross-table transactions." → ✅ verified (evidence: The file at L92 states: "Bigtable supports single-row atomic operations — including read-modify-write and check-and-mutate — but does not offer cross-row or cross-table transactions." This is consistent with Bigtable's well-documented…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L99 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "| Conditional writes | Yes | Yes (check-and-mutate) |" → ✅ verified (evidence: Google Cloud official documentation confirms that Bigtable supports conditional writes via the CheckAndMutateRow API: "Check-and-mutate operations, also known as conditional mutations or conditional writes." The docs also state "This type…; source: https://docs.cloud.google.com/bigtable/docs/routing (index 4-1) and https://cloud.google.com/bigtable/docs/writing-data (index 5-2))
L103 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Both DynamoDB and Bigtable target single-digit-millisecond p99 latency for well-designed workloads." → ❌ contradicted (framing: shifted — the claim attributes p99 single-digit-ms to both services equally, but DynamoDB's official framing is average latency, not p99; only Bigtable explici…; evidence: Bigtable explicitly targets p99 single-digit ms ("at the 99th percentile, you can perform single-digit millisecond queries"), but DynamoDB's official docs describe single-digit ms for "Average SuccessfulRequestLatency," not p99 — and AWS r…; source: https://cloud.google.com/blog/products/databases/new-features-for-cloud-bigtable-observability/ ; https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingLatency.html)
L105 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DAX (DynamoDB Accelerator), an in-memory cache, can push DynamoDB reads into microseconds for cache-friendly workloads." → ✅ verified (framing: strengthened — claim adds "DynamoDB Accelerator" expansion and "DynamoDB reads" specificity; source's broader form proves the claim as a subset; evidence: The file at the relevant section states: "DAX, an in-memory cache, can push reads into microseconds for cache-friendly workloads." The claim correctly expands DAX as "DynamoDB Accelerator" and specifies "DynamoDB reads," which is accurate…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L106 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable delivers consistent low latency for reads and writes proportional to the number of nodes in a cluster." → ❌ contradicted (framing: shifted — source says throughput/performance capacity scales linearly with nodes; claim asserts latency is proportional to node count, which is a different (an…; evidence: Google Cloud Bigtable docs state "a cluster's performance scales linearly as you add nodes" — referring to throughput capacity, not latency. Latency is not described as proportional to node count; rather, adding nodes reduces latency under…; source: https://docs.cloud.google.com/bigtable/docs/performance)
L115 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable charges per node-hour and per GB stored." → ✅ verified (framing: strengthened — claim says "per GB stored"; source uses GiB, but the two-part node-hour + storage pricing model is confirmed exactly.; evidence: The official Google Cloud Bigtable pricing page confirms both cost dimensions: nodes are billed per node per hour (e.g., "$0.65 per node per hour in us-central1") and storage is billed per GiB (e.g., "$0.17 per GiB in us-central1"). The cl…; source: https://cloud.google.com/bigtable/pricing)
L123 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "| Backups | PITR and on-demand backups (per GB) | Backups per GB-month |" → ✅ verified (framing: strengthened — the claim abbreviates DynamoDB's pricing as "per GB" while the source specifies "per GB-month"; the source's fuller form proves the claim as a c…; evidence: AWS pricing docs confirm DynamoDB on-demand backups are charged per GB-month and PITR is "$0.20 per GB based on the size of the data and all local secondary indexes." Google Cloud Bigtable docs confirm "Backup storage is priced in GiB/mont…; source: https://aws.amazon.com/dynamodb/pricing/on-demand/ and https://cloud.google.com/blog/products/databases/how-to-save-money-when-using-cloud-databases)
L124 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable has no free tier; billing is per-hour from the moment the cluster is created." (also L226) → ✅ verified (evidence: The official Bigtable pricing page confirms per-hour billing: "You are charged each hour for the maximum number of nodes that exist during that hour" and "Charges apply even if your cluster is inactive." Bigtable does not appear on Google…; source: https://cloud.google.com/bigtable/pricing)
L134-135 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable has a maximum row size of 256 MB per row, with a recommended maximum of less than 100 MB." → ✅ verified (evidence: Google Cloud Bigtable official docs confirm both figures: "Make sure that data in a single row doesn't exceed 256 MB" (schema design page) and "Ideally, you should never let a row grow beyond 100 MB in size, and the limit is 256 MB" (garba…; source: https://cloud.google.com/bigtable/docs/schema-design and https://docs.cloud.google.com/bigtable/docs/garbage-collection)
L139 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable supports backups stored in the same instance and import/export to Cloud Storage." (also L242) → ❌ contradicted (framing: shifted — the claim conflates two distinct features: native backups (stored within the Bigtable instance/cluster, NOT exportable to Cloud Storage) and Dataflow…; evidence: Google's official Bigtable backups documentation explicitly states: "You cannot export, copy, or move a Bigtable backup to another service, such as Cloud Storage." Backups are fully integrated within the Bigtable service; import/export to…; source: https://docs.cloud.google.com/bigtable/docs/backups)
L139 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB supports point-in-time recovery (PITR) for 35 days." → ✅ verified (framing: strengthened — claim states "35 days" as a fixed figure; source clarifies it is the maximum/default of a configurable 1–35 day range. The claim is a valid subs…; evidence: AWS official docs confirm: "Point-in-time recovery (PITR) backups are fully managed by DynamoDB and provide up to 35 days of recovery points at a per second granularity." The default recovery period is 35 days, configurable between 1 and 3…; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Point-in-time-recovery.html)
L141 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB Global Tables provide active-active replication across regions with last-writer-wins conflict resolution." → ✅ verified (evidence: (escalated from pass1) AWS official docs confirm both aspects: DynamoDB Global Tables is described as "a fully managed, multi-Region, and multi-active database" and "If the same item is modified in multiple Regions simultaneously, DynamoDB…; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/V2globaltables_HowItWorks.html and https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
L147-148 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB supports exports to S3, Athena Federated Query, and Redshift via Zero-ETL for analytics." → ✅ verified (framing: strengthened — claim groups three distinct integration mechanisms together; Athena Federated Query queries DynamoDB directly rather than via export, but all th…; evidence: (escalated from pass1) AWS official docs confirm DynamoDB supports exports to S3, Athena Federated Query (querying DynamoDB directly via connectors), and Zero-ETL integration with Redshift. Per AWS docs: "Amazon DynamoDB zero-ETL integrati…; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/RedshiftforDynamoDB-zero-etl.html)
L147 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable has native integration with BigQuery, Dataflow, and Dataproc for analytics." → ✅ verified (framing: strengthened — claim narrows the source's broader list of integrations to specifically BigQuery, Dataflow, and Dataproc for analytics; source's broader form pr…; evidence: (escalated from pass1) The official Google Cloud Bigtable product page states: "Build data-driven applications faster with seamless integrations with Apache Spark, Hadoop, GKE, Dataflow, Dataproc, Vertex AI Vector Search, and BigQuery." Th…; source: https://cloud.google.com/bigtable (product page) and https://docs.cloud.google.com/bigtable/docs/integrations and https://cloud.google.com/dataproc/docs/concepts/connectors/cloud-bigtable)
L152 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB supports the AWS SDKs and PartiQL as query interfaces." → ❌ contradicted (framing: shifted — source says "DynamoDB API, PartiQL" but claim says "AWS SDKs and PartiQL"; these refer to different subjects (native service API vs. client SDK libra…; evidence: The file's own comparison table lists DynamoDB's query interface as "DynamoDB API, PartiQL" — not "AWS SDKs and PartiQL." The claim substitutes "AWS SDKs" for "DynamoDB API," which are distinct: the DynamoDB API is the native service inter…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md (at-a-glance table, Query interface row))
L154 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Dataflow is the standard way to land streaming data into Bigtable tables." → ❌ contradicted (framing: narrowed — claim broadens a common/recommended pattern to "the standard way"; Google docs present Dataflow as one of multiple options, including direct Pub/Sub…; evidence: Google's official Bigtable import/export docs explicitly note an alternative: "You can stream messages from Pub/Sub directly to a Bigtable table using Pub/Sub Bigtable subscriptions (Preview). This method lets you write streaming messages…; source: https://docs.cloud.google.com/bigtable/docs/import-export)
L178 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Both the Pulumi AWS provider and Google Cloud provider expose the full service surface for DynamoDB and Bigtable, including IAM, replication, backups, and auto…" → 🤷 unverifiable (framing: narrowed — the specific features (IAM, replication, backups, autoscaling) are verifiably present in both providers, but "full service surface" is an overclaim…; evidence: The pulumi-aws DynamoDB provider includes tableReplica.go, getBackups.go, and resourcePolicy.go; the pulumi-gcp Bigtable provider includes instanceIamPolicy/Binding/Member, tableIamPolicy/Binding/Member, AutoscalingConfig, and backup-relat…; source: gh api repos/pulumi/pulumi-aws/contents/sdk/go/aws/dynamodb; gh api repos/pulumi/pulumi-gcp/contents/sdk/go/gcp/bigtable)
L208 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "With either provider you can put encryption keys, IAM bindings, and replication into the same program — and enforce safe defaults across the org with [Pulumi P…" → ✅ verified (evidence: The path /docs/insights/policy/ resolves to a valid Pulumi documentation page titled "Policies | Insights & Governance" which describes Pulumi Policies for enforcing compliance and security across cloud infrastructure, matching the claim…; source: repo:content/docs/insights/policy/_index.md)
L214 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB wins for point-lookup-heavy OLTP traffic, especially with DAX in front." → ✅ verified (evidence: Multiple authoritative sources confirm this positioning: Pluralsight notes "GCP Bigtable explicitly advise that it is not suitable for OLTP/OLAP" while DynamoDB supports ACID transactions; AWS docs confirm DAX "reduces the response times o…; source: https://www.pluralsight.com/resources/blog/cloud/comparing-cloud-nosql-databases-dynamodb-vs-cosmos-db-vs-cloud-datastore-and-bigtable; https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.html)
L214 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable wins for large sequential scans and very high sustained write throughput." → ✅ verified (framing: strengthened — claim narrows Bigtable's general sequential/write throughput advantages to a comparative "wins" framing; sources' broader descriptions of Bigtab…; evidence: Multiple authoritative sources confirm Bigtable's advantage for sequential scans and high write throughput. Google's own docs note Bigtable "scans the table and reads the requested rows sequentially" and that "a cluster's performance scale…; source: https://docs.cloud.google.com/bigtable/docs/dynamodb-users; https://docs.cloud.google.com/bigtable/docs/performance; https://geeklogbook.com/google-bigtable-vs-amazon-dynamodb-understanding-the-differences/)
L218 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Apache Cassandra uses a similar wide-column model to Bigtable and is a self-managed alternative for portability across clouds." → ✅ verified (evidence: Multiple authoritative sources confirm both parts of the claim. The official Apache Cassandra docs state it "implements a partitioned wide-column storage model" and its design combined "Google's Bigtable data and storage engine model." Goo…; source: https://cassandra.apache.org/doc/latest/cassandra/architecture/overview.html; https://cloud.google.com/bigtable/docs/cloud-bigtable-for-cassandra-users; https://leadwebpraxis.com/bigtable-or-cassandra/)
L218 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB is exclusive to AWS and Bigtable is exclusive to Google Cloud." → ✅ verified (evidence: The file's at-a-glance comparison table explicitly lists "Cloud: AWS" for DynamoDB and "Cloud: Google Cloud" for Bigtable, and the intro describes them as "NoSQL services from major cloud providers" — confirming each is exclusive to its re…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L218 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable is exclusive to Google Cloud." → ✅ verified (evidence: The file's own at-a-glance comparison table lists Bigtable's "Cloud" as "Google Cloud" (vs. DynamoDB's "AWS"), and Google Cloud Bigtable is a proprietary managed service offered exclusively on Google Cloud with no equivalent offering on ot…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md (at-a-glance table, Cloud row))
L222 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB supports ACID transactions across up to 100 items in a single request." → ✅ verified (evidence: The file at L222 states "It supports ACID transactions across up to 100 items in one or more tables in a single request, including condition checks." AWS's official DynamoDB documentation confirms that TransactWriteItems and TransactGetIte…; source: content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L222 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable only supports single-row atomic operations — there are no multi-row or multi-table transactions." → ✅ verified (evidence: The file itself at the Bigtable consistency section states: "Bigtable supports single-row atomic operations — including read-modify-write and check-and-mutate — but does not offer cross-row or cross-table transactions." The comparison…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
L226 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable does not have a free tier — every node accrues per-hour cost from the moment the cluster is created." → ✅ verified (evidence: The official Bigtable pricing page confirms no free tier exists and that nodes accrue per-hour costs from provisioning: "You are charged each hour for the maximum number of nodes that exist during that hour... Charges apply even if your cl…; source: https://cloud.google.com/bigtable/pricing)
L238 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB supports a subset of SQL through PartiQL." → ✅ verified (evidence: The file itself lists "DynamoDB API, PartiQL" as DynamoDB's query interface in the at-a-glance table. PartiQL is AWS's SQL-compatible (subset of SQL) query language for DynamoDB, a well-established AWS feature. The claim accurately describ…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md (at-a-glance table, Query interface row))
L238 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable supports GoogleSQL (in preview) and is queryable from BigQuery via federation." → ❌ contradicted (framing: shifted — claim states GoogleSQL is "(in preview)" but it is generally available (GA); the BigQuery federation part is correct and also GA; evidence: (escalated from pass1) GoogleSQL for Bigtable is now GA, not in preview. The official blog announced it in August 2024: "we're announcing Bigtable support for GoogleSQL," and release notes confirm multiple GA milestones (geography function…; source: https://cloud.google.com/blog/products/databases/announcing-sql-support-for-bigtable; https://cloud.google.com/blog/products/data-analytics/bigtable-bigquery-federation-brings-hot--cold-data-closer; https://docs.cloud.google.com/bigtable/docs/release-notes)
L238 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable is queryable from BigQuery via federation." → ✅ verified (evidence: (escalated from pass1) Google Cloud's official blog confirms: "with the General Availability of Bigtable federated queries with BigQuery, you can query data residing in Bigtable via BigQuery faster, without moving or copying the data." Thi…; source: https://cloud.google.com/blog/products/data-analytics/bigtable-bigquery-federation-brings-hot--cold-data-closer)
L242 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable supports backups stored in the same instance and import/export to Cloud Storage." → ❌ contradicted (framing: shifted — the claim attributes "import/export to Cloud Storage" as a backup storage option, but the source explicitly prohibits exporting backups to Cloud Stor…; evidence: The official Bigtable backups docs explicitly state: "You cannot export, copy, or move a Bigtable backup to another service, such as Cloud Storage." Bigtable does support import/export of data (not backups) to Cloud Storage via a separate…; source: https://docs.cloud.google.com/bigtable/docs/backups)
L246 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Existing HBase applications can typically point at Bigtable with minor configuration changes." → ❌ contradicted (framing: narrowed — claim broadens the migration effort to "minor configuration changes," but sources describe substantial steps including API updates, schema translati…; evidence: (escalated from pass1) Google Cloud's official migration docs describe a multi-step process including schema translation, data export/import, authentication conversion to IAM, and API version updates. One doc notes: "if your application ta…; source: https://docs.cloud.google.com/bigtable/docs/hbase-api-changes)
L246 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "The HBase API is specific to Bigtable; DynamoDB uses its own API and PartiQL." → ❌ contradicted (framing: shifted — the source shows Bigtable supports the HBase API, but the claim asserts the HBase API is "specific to Bigtable," which reverses the ownership relatio…; evidence: The file's own comparison table lists Bigtable's query interface as "HBase API, Bigtable client libraries, GoogleSQL (preview)" — but HBase is an open-source Apache project whose API predates and is independent of Bigtable; Bigtable merely…; source: content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md (at-a-glance comparison table, Query interface row))
L250 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Pulumi gives teams a single way to provision DynamoDB on AWS or Bigtable on Google Cloud, using the same programming languages, the same review workflow, and t…" → ✅ verified (evidence: The file content/docs/get-started/_index.md exists and includes /docs/get-started/ as an alias, confirming the link /docs/get-started/ is a valid, live page. The claim's CTA link resolves correctly.; source: repo:content/docs/get-started/_index.md)
L254 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "* Database Comparison: Cosmos DB vs DynamoDB" → ✅ verified (evidence: The file content/what-is/database-comparison-cosmos-db-vs-dynamodb.md exists with the title "Database Comparison: Cosmos DB vs DynamoDB", matching the link text and path referenced in the claim.; source: repo:content/what-is/database-comparison-cosmos-db-vs-dynamodb.md)
L255 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "* Cosmos DB vs MongoDB: Know the differences" → ✅ verified (evidence: The file content/what-is/cosmos-db-vs-mongodb-know-the-differences.md exists in the repo with the title "Cosmos DB vs MongoDB, Know The Differences?" matching the linked text "Cosmos DB vs MongoDB: Know the differences" at the path `/wha…; source: repo:content/what-is/cosmos-db-vs-mongodb-know-the-differences.md)
L256-257 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "* Pulumi Google Cloud provider" → ✅ verified (evidence: The path /registry/packages/gcp/ exists in the Pulumi registry repository (pulumi/registry) at themes/default/content/registry/packages/gcp/_index.md, confirming the URL /registry/packages/gcp/ is a valid link to the Pulumi Google…; source: gh api repos/pulumi/registry/contents/themes/default/content/registry/packages/gcp)
L3 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "Pulumi ESC issues OIDC-issued credentials that are short-lived and auditable in CloudTrail, with no static IAM keys required." → ✅ verified (evidence: The file's meta_desc (L3) states: "Run aws sts get-caller-identity with short-lived, OIDC-issued credentials from Pulumi ESC. No static IAM keys, scoped by role, auditable in CloudTrail." The body further confirms: credentials are OIDC-iss…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L10 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "aws sts get-caller-identity returns the account, user ID, and ARN of the calling identity." → ✅ verified (evidence: The file at line 10 states exactly: "aws sts get-caller-identity returns the account, user ID, and ARN of the calling identity." The document also shows the expected JSON output with UserId, Account, and Arn fields, confirming this…; source: content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L10 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "Pulumi ESC issues short-lived AWS credentials brokered over OIDC, instead of long-lived AKIA... keys in ~/.aws/credentials." → ✅ verified (evidence: The file at L10 states verbatim: "This guide shows how to run aws sts get-caller-identity using short-lived AWS credentials brokered by Pulumi ESC over OIDC, instead of long-lived AKIA... keys in ~/.aws/credentials."…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L14 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "* Why dynamic credentials beat static IAM keys" → ➖ not-a-claim (evidence: The line "* Why dynamic credentials beat static IAM keys" is a section heading/bullet in the PR author's own documentation article, describing the structure of their own content. It is not a falsifiable third-party-attributed assertion — i…; source: WebSearch ran query "dynamic credentials vs static IAM keys AWS security advantages"; docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
L22 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "## Why dynamic credentials beat static IAM keys" → ➖ not-a-claim (evidence: The text "## Why dynamic credentials beat static IAM keys" is a markdown section heading in the PR author's own document. It is a descriptive label for the author's own content/design, not a falsifiable third-party-attributed assertion.; source: content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md L22)
L26 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "Pulumi ESC issues a fresh AccessKeyId, SecretAccessKey, and SessionToken on every esc run invocation." → ✅ verified (evidence: The file at L26 states verbatim: "Pulumi ESC issues a fresh AccessKeyId, SecretAccessKey, and SessionToken on every esc run. Nothing lingers in ~/.aws/credentials." This is the PR author's own description of the behavior they are…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md, L26)
L26 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "Pulumi ESC dynamic credentials do not linger in ~/.aws/credentials." → ✅ verified (evidence: The file at L26 (in the bullet point section) explicitly states: "Pulumi ESC issues a fresh AccessKeyId, SecretAccessKey, and SessionToken on every esc run. Nothing lingers in ~/.aws/credentials." This is a direct match for the c…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L28 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "ESC-issued AWS sessions expire after the duration configured in the ESC environment, with a default of 1 hour." → 🤷 unverifiable (evidence: All Pulumi ESC docs consistently show duration: 1h as an explicitly configured example value in YAML snippets, but no authoritative source states that 1 hour is the default when duration is omitted. The aws-login provider docs and OI…; source: WebSearch ran query "Pulumi ESC aws-login OIDC duration default value schema"; top results show duration: 1h only as an example, not as a documented default.; intuition: The claim conflates the commonly shown example value (1h) with a system default — no docs page explicitly states the de…)
L29 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "CloudTrail records ESC-brokered calls under the assumed-role ARN, with sessionName from the ESC environment." → ✅ verified (evidence: The file at L29 states verbatim: "CloudTrail records the call under the assumed-role ARN, with sessionName from the ESC environment, so it's clear which Pulumi org and user triggered the command." This is an exact match to the claim.; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L35 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "* The Pulumi CLI and Pulumi ESC CLI installed" → ✅ verified (evidence: The file at L35 contains exactly "The Pulumi CLI and Pulumi ESC CLI installed", and content/docs/install/_index.md exists as a valid page titled "Download & Install Pulumi" covering Pulumi CLI inst…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md and repo:content/docs/install/_index.md)
L36 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "* A Pulumi Cloud account and access to an organization" → ✅ verified (evidence: Line 36 of the file reads exactly: "* A Pulumi Cloud account and access to an organization", which matches the claim verbatim.; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L37 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "* The AWS CLI v2 installed locally" → ✅ verified (evidence: The URL https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html resolves to the official AWS page titled "Installing or updating to the latest version of the AWS CLI," which covers AWS CLI v2 installation. The page co…; source: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
L38 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "* An IAM role with OIDC trust configured for Pulumi (see Configuring OIDC between Pulumi and AWS)" → ✅ verified (framing: strengthened — the page title is "Configuring OpenID Connect for AWS" while the claim calls it "Configuring OIDC between Pulumi and AWS"; the alias URL matches…; evidence: The file content/docs/esc/guides/configuring-oidc/aws.md exists with aliases: - /docs/esc/environments/configuring-oidc/aws/, confirming the linked URL /docs/esc/environments/configuring-oidc/aws/ is a valid alias for the AWS OIDC co…; source: repo:content/docs/esc/guides/configuring-oidc/aws.md)
L40 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "For aws sts get-caller-identity, the IAM role needs no managed policies — STS GetCallerIdentity is allowed for any authenticated principal." → ✅ verified (evidence: The file itself states at L40: "the IAM role needs no managed policies — STS get-caller-identity is allowed for any authenticated principal," and the FAQ section reinforces: "AWS explicitly allows any authenticated principal to call `GetCa…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L50 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "Follow the browser prompt or paste an access token from https://app.pulumi.com/account/tokens." → ➖ not-a-claim (evidence: The text is a UI instruction directing users to a well-known Pulumi console URL (app.pulumi.com/account/tokens) to obtain an access token. This is a standard navigation instruction, not a falsifiable factual assertion about product behavio…; source: content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md L50)
L54 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "The Pulumi OIDC + AWS guide instructs users to create an IAM role whose trust policy accepts a JWT from api.pulumi.com/oidc." → ✅ verified (evidence: The guide at content/docs/esc/guides/configuring-oidc/aws.md (aliased as /docs/esc/environments/configuring-oidc/aws/) instructs users to set the Provider URL to https://api.pulumi.com/oidc and shows a trust policy with `"Federated":…; source: repo:content/docs/esc/guides/configuring-oidc/aws.md)
L56 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "### 3. Create a new Pulumi ESC environment" → ➖ not-a-claim (evidence: The text "### 3. Create a new Pulumi ESC environment" is a section heading in a numbered list of steps — it is a structural/navigational label, not a falsifiable assertion about any fact, version, or capability.; source: content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md, L56)
L58 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "In Pulumi Cloud, open your organization, click Environments, then Create environment. Name it something like aws-prod-env." → ➖ not-a-claim (evidence: The text is a UI walkthrough instruction authored by the PR author describing steps to take in Pulumi Cloud (open org, click Environments, click Create environment, name it). The linked URL https://app.pulumi.com/ is simply the Pulumi Cl…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L79 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "The fn::open::aws-login function exchanges the Pulumi-issued OIDC token for AWS STS credentials." → ✅ verified (evidence: The file at L79 states verbatim: "The fn::open::aws-login function exchanges the Pulumi-issued OIDC token for AWS STS credentials." The surrounding YAML shows fn::open::aws-login with an oidc block (roleArn, sessionName) and the outp…; source: content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L79 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "The environmentVariables block in a Pulumi ESC environment exposes credentials to any subprocess started by esc run." → ✅ verified (evidence: The file at line ~79 states verbatim: "The environmentVariables block exposes them to any subprocess started by esc run." — an exact match to the claim.; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L101 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "'Arn': 'arn:aws:sts::123456789012:assumed-role/pulumi-esc-role/pulumi-environments-session'" → ➖ not-a-claim (evidence: The ARN arn:aws:sts::123456789012:assumed-role/pulumi-esc-role/pulumi-environments-session is a placeholder example in a documentation code block showing expected CLI output. The account ID 123456789012 is the canonical AWS placeholder…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L109 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "The session name in the aws sts get-caller-identity response (pulumi-environments-session) matches the sessionName field in the ESC YAML configuration." → ✅ verified (evidence: The file explicitly states: "The session name (pulumi-environments-session) matches the sessionName field in your YAML — useful for filtering CloudTrail." The ESC YAML configuration in step 4 sets `sessionName: pulumi-environments-sess…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L113 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "Within approximately 5 minutes, an aws sts get-caller-identity call appears in CloudTrail with eventName=GetCallerIdentity." → ✅ verified (framing: strengthened — claim narrows the general "about 5 minutes" delivery time to the specific context of a GetCallerIdentity event; source's broader form proves the…; evidence: AWS official docs and FAQs confirm: "CloudTrail typically delivers logs within an average of about 5 minutes of an API call" and "CloudTrail publishes log files multiple times an hour, about every 5 minutes." The claim's "approximately 5 m…; source: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html)
L119 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "'arn': 'arn:aws:sts::123456789012:assumed-role/pulumi-esc-role/pulumi-environments-session'," → ➖ not-a-claim (evidence: The line is part of an illustrative CloudTrail JSON example block in the documentation, using the standard AWS placeholder account ID 123456789012 and a fictional role ARN. It is example output showing what a CloudTrail record looks like…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L123 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "'arn': 'arn:aws:iam::123456789012:role/pulumi-esc-role'" → ➖ not-a-claim (evidence: The string "arn": "arn:aws:iam::123456789012:role/pulumi-esc-role" appears in the file's CloudTrail example JSON block as a documentation placeholder using the well-known AWS example account ID 123456789012. It is a fictional/illustrat…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L136 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "The default session duration for ESC-issued AWS credentials is 1 hour, controlled by the duration field in the ESC environment." → ✅ verified (framing: strengthened — the document's prose confirms "1 hour by default" and the duration field as the control mechanism, matching the claim exactly.; evidence: The file itself states "Sessions expire after the duration in the ESC environment (1 hour by default, configurable up to the IAM role's MaxSessionDuration)" and the Common errors table notes "Session exceeded duration (default 1h)". Th…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L137 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "An AccessDenied on AssumeRoleWithWebIdentity is caused by an OIDC trust policy mismatch, and the fix involves checking roleArn, the trust policy's sub…" → ✅ verified (evidence: The "Common errors" table in the file at the relevant line states exactly: "AccessDenied on AssumeRoleWithWebIdentity | OIDC trust policy mismatch | Check roleArn, the trust policy's sub claim, and that the audience matches `api.pulu…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L145 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "AWS explicitly allows any authenticated principal to call GetCallerIdentity, regardless of attached IAM policies." → ✅ verified (framing: strengthened — claim frames this as AWS "explicitly allows any authenticated principal … regardless of attached IAM policies"; the source's broader form ("no p…; evidence: (escalated from pass1) Official AWS STS API docs state: "No permissions are required to perform this operation. If an administrator attaches a policy to your identity that explicitly denies access to the sts:GetCallerIdentity action, you c…; source: https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html)
L149 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "The assumed-role/<role-name>/<session-name> ARN format is how STS reports any principal that arrived via AssumeRole, AssumeRoleWithWebIdentity, or Assum…" → ✅ verified (framing: strengthened — claim narrows the general AWS STS assumed-role ARN format to include Pulumi ESC OIDC sessions specifically; since Pulumi ESC uses AssumeRoleWith…; evidence: (escalated from pass1) AWS official docs confirm all three AssumeRole variants return the same ARN format. The GetCallerIdentity API reference shows arn:aws:sts::123456789012:assumed-role/my-role-name/my-role-session-name` for AssumeRole…; source: https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html)
L153 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "The maximum ESC-issued AWS session duration is bounded by the IAM role's MaxSessionDuration attribute, up to 12 hours for role chaining and 1 hour for OIDC b…" → ❌ contradicted (framing: shifted — claim states "up to 12 hours for role chaining and 1 hour for OIDC by default" but AWS docs say role chaining is capped at 1 hour and OIDC (AssumeRol…; evidence: AWS docs state the opposite: "Using the credentials from one role to assume a different role is called role chaining. When you use role chaining, the role's session duration is limited to one hour." The general MaxSessionDuration cap of up…; source: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html)
L157 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "The Pulumi GitHub Action, GitLab integration, and esc open / esc run in any CI runner all work the same way for using ESC-issued credentials in CI/CD." → 🤷 unverifiable (framing: shifted — the cited source covers only esc run for AWS CLI; the claim extends this to assert equivalence across the Pulumi GitHub Action, GitLab integration,…; evidence: The cited blog post /blog/esc-env-run-aws/ focuses narrowly on using esc run for dynamic AWS CLI credentials and does not discuss the Pulumi GitHub Action, GitLab integration, or esc open as working "the same way." While other Pulumi d…; source: https://www.pulumi.com/blog/esc-env-run-aws/ (WebSearch dispatched but verification did not converge within the turn budget))
L161 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "Inside esc run, aws configure list reports access_key with Type=env, indicating it came from environment variables injected by ESC." → 🤷 unverifiable (evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697…)
L165 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "For OIDC AssumeRoleWithWebIdentity, Pulumi ESC uses the regional endpoint matching AWS_REGION if set, otherwise the global endpoint." → 🤷 unverifiable (evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697…)
L169 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "aws sts get-caller-identity works for any principal type (user, role, assumed-role session) and needs no permissions." → ✅ verified (evidence: The file's FAQ section states: "None. AWS explicitly allows any authenticated principal to call GetCallerIdentity, regardless of attached IAM policies." The document also notes the command works for IAM users, assumed-role sessions (via…; source: content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md (FAQ section and intro paragraph))
L169 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "iam get-user only works for IAM users, requires the iam:GetUser permission, and fails when the caller is a role session." → 🤷 unverifiable (evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697…)

github-actions · 2026-05-20T17:00:37Z

continued from previous comment

L173-174 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "* Configuring OIDC between Pulumi and AWS" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
L175-177 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "* Resolve Unable to locate credentials" → ✅ verified (evidence: The file content/what-is/resolve-unable-to-locate-credentials.md exists in the repo with the title "Unable to locate credentials", confirming the link target /what-is/resolve-unable-to-locate-credentials/ is valid and the link text mat…; source: repo:content/what-is/resolve-unable-to-locate-credentials.md)
L178-179 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "* Run aws iam list-users with dynamic credentials" → ✅ verified (evidence: The file content/what-is/run-aws-iam-list-users-with-dynamic-credentials.md exists in the repo with the title "Run 'aws iam list-users' using Dynamic Credentials", confirming the linked page and its description are accurate.; source: repo:content/what-is/run-aws-iam-list-users-with-dynamic-credentials.md)
L181 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "Join our community on Slack to discuss further, and let us know what you build." → ➖ not-a-claim (evidence: The line is a standard boilerplate call-to-action footer linking to https://slack.pulumi.com/ — a well-known, stable Pulumi community URL used consistently across Pulumi documentation. This is not a falsifiable factual assertion about a th…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L3 in content/what-is/what-is-a-github-action-secret.md "GitHub Actions secrets support scopes: repository, environment, and organization." → 🤷 unverifiable (evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697…)
L10 in content/what-is/what-is-a-github-action-secret.md "A GitHub Actions secret is an encrypted variable scoped to a repository, environment, or organization that GitHub injects into workflow runs as an environment…" → ✅ verified (framing: strengthened — claim omits the trailing clause "with automatic redaction in logs and no exposure to forked pull requests by default"; source's broader form pro…; evidence: The file's opening bold sentence reads: "A GitHub Actions secret is an encrypted variable scoped to a repository, environment, or organization that GitHub injects into workflow runs as an environment variable or step input, with automatic…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L12 in content/what-is/what-is-a-github-action-secret.md "Modern GitHub Actions workflows can use OIDC federation to mint cloud credentials per run instead of storing secrets." → ✅ verified (framing: strengthened — claim narrows the source's general OIDC capability to "mint cloud credentials per run instead of storing secrets"; source's broader form proves…; evidence: Official GitHub Docs confirm: "After you have established a trust connection with a cloud provider that supports OIDC, you can configure your workflow to request a short-lived access token directly from the cloud provider," and "With OIDC,…; source: https://docs.github.com/en/actions/concepts/security/openid-connect)
L12 in content/what-is/what-is-a-github-action-secret.md "The GitHub Actions log redactor uses real-time text matching, so transformations like echo $MY_SECRET | base64 or set -x can still expose secret values in…" → 🤷 unverifiable (framing: shifted — the cited source (REST API for secrets management) does not discuss log redaction; the correct source would be the GitHub Actions security guide; evidence: Official GitHub docs confirm the redactor uses exact-match text matching and that base64 transformations can bypass it ("redaction largely relies on finding an exact match"), but the specific framing "real-time text matching" and the set…; source: WebSearch ran query "GitHub Actions log redactor secret masking base64 set -x bypass"; https://docs.github.com/en/actions/reference/security/secure-use; intuition: The set -x` bypass claim is plausible (shell xtrace prints expanded variable values) but is not explicitly documented…)
L37 in content/what-is/what-is-a-github-action-secret.md "Repository, environment, and organization variables in GitHub Actions are not encrypted and not redacted in logs." → ✅ verified (evidence: The file at L37 states: "Variables aren't encrypted but also aren't redacted — they're meant for things that can safely appear in logs." This directly confirms that repository, environment, and organization variables are not encrypted and…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L41 in content/what-is/what-is-a-github-action-secret.md "GitHub Actions secrets live at three scopes: repository, environment, and organization." → ✅ verified (evidence: The file at line 41 states: "GitHub Actions secrets live at three scopes that determine where they can be referenced and which workflows can read them." The accompanying table explicitly lists the three scopes as Repository, Environment, a…; source: content/what-is/what-is-a-github-action-secret.md)
L45-47 in content/what-is/what-is-a-github-action-secret.md "Environment-scoped GitHub Actions secrets are available only to jobs that specify environment: for that environment, with optional approval gates." → ✅ verified (evidence: The file's scope table explicitly states for Environment secrets: "Jobs that environment: into that environment, with optional approval gates" — exactly matching the claim's framing.; source: repo:content/what-is/what-is-a-github-action-secret.md)
L49 in content/what-is/what-is-a-github-action-secret.md "Environment-scoped secrets allow requiring manual approval, wait timers, and deployment-branch policies before a job can read production credentials." → ➖ not-a-claim (evidence: The text at L49 is the PR author's own description of GitHub Actions environment-scoped secrets in the file being authored. It faithfully describes GitHub's documented environment protection rules (required reviewers, wait timers, deployme…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L53 in content/what-is/what-is-a-github-action-secret.md "The repository or organization holds a public key; the secret is encrypted with that key client-side; only GitHub holds the corresponding private key to decryp…" → ❌ contradicted (framing: shifted — source says GitHub decrypts server-side and injects into the workflow runtime; claim says decryption happens "on the runner", which is a different su…; evidence: GitHub docs confirm client-side encryption with libsodium sealed boxes and that GitHub holds the private key, but state "Once the secret is uploaded, GitHub is then able to decrypt it so that it can be injected into the workflow runtime" —…; source: https://docs.github.com/en/actions/concepts/security/secrets)
L57-59 in content/what-is/what-is-a-github-action-secret.md "GitHub Actions secrets use NaCl crypto_box_seal for sealed-box encryption during submission." → 🤷 unverifiable (evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697…)
L62 in content/what-is/what-is-a-github-action-secret.md "GitHub Actions secrets are discarded with the ephemeral runner after the job ends." → 🤷 unverifiable (evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697…)
L64 in content/what-is/what-is-a-github-action-secret.md "GitHub itself can decrypt secrets to deliver them to runners, so the trust boundary is GitHub plus the runner." → ➖ not-a-claim (evidence: The text at L64 of the file reads: "GitHub itself can decrypt your secrets to deliver them to runners, so the trust boundary is GitHub plus your runner." This is the PR author's own explanatory statement about GitHub Actions secret archite…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L86 in content/what-is/what-is-a-github-action-secret.md "Workflows triggered by pull_request from a fork get an empty secrets context unless you explicitly opt in with pull_request_target." → ✅ verified (evidence: The file at L86 states: "Workflows triggered by pull_request from a fork get an empty secrets context unless you explicitly opt in with pull_request_target (which has its own security considerations)." This matches the claim exactly…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L87 in content/what-is/what-is-a-github-action-secret.md "Composite and reusable actions don't inherit secrets automatically; you have to pass them in as inputs: or use secrets: inherit when calling a reusable wor…" → ✅ verified (evidence: The file at L87 contains the exact claim: "Composite and reusable actions don't inherit secrets automatically. You have to pass them in as inputs: or use secrets: inherit when calling a reusable workflow." This accurately reflects GitH…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L88 in content/what-is/what-is-a-github-action-secret.md "GITHUB_TOKEN is a special, auto-issued, short-lived secret scoped to the current repository." → ✅ verified (evidence: The file at the relevant section reads verbatim: "GITHUB_TOKEN is a special, auto-issued, short-lived secret scoped to the current repository. Prefer it to a personal access token whenever you can." This is an exact match to the claim.; source: repo:content/what-is/what-is-a-github-action-secret.md)
L92 in content/what-is/what-is-a-github-action-secret.md "Per GitHub's documentation:" → ✅ verified (evidence: The URL https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions resolves to a live GitHub Docs page titled "Using secrets in GitHub Actions," confirming it is a valid GitHub documentation link.; source: https://docs.github.com/actions/security-guides/using-secrets-in-github-actions)
L94-95 in content/what-is/what-is-a-github-action-secret.md "GitHub Actions supports up to 1,000 secrets per repository, 100 per environment, and 1,000 per organization." (also L168, L172) → ❌ contradicted (framing: shifted — claim states "1,000 secrets per repository" but the source says 100 per repository and 1,000 per organization; the repository and organization limits…; evidence: GitHub's official docs state: "You can store up to 1,000 organization secrets, 100 repository secrets, and 100 environment secrets." The claim inverts the repository and organization limits, asserting 1,000 per repository (correct for orga…; source: https://docs.github.com/en/code-security/getting-started/understanding-github-secret-types)
L96 in content/what-is/what-is-a-github-action-secret.md "GitHub does not natively expire or rotate GitHub Actions secret values." → ✅ verified (evidence: The file at L96 (limits section) states: "No native rotation. GitHub doesn't expire or rotate values for you; you have to update them out of band (or use OIDC to avoid storing them at all)." This directly confirms the claim.; source: repo:content/what-is/what-is-a-github-action-secret.md)
L97 in content/what-is/what-is-a-github-action-secret.md "Any workflow in the repository can read any repo-scoped secret; environments are the only way to gate access to a subset." → ❌ contradicted (framing: shifted — the claim conflates "environments gate access to environment-scoped secrets" with "environments gate access to repo-scoped secrets"; these are differ…; evidence: The claim states "Environments are the only way to gate access to a subset" of repo-scoped secrets, but this is misleading: environments gate environment-scoped secrets (secrets defined under an environment), not repo-scoped secrets. Any…; source: repo:content/what-is/what-is-a-github-action-secret.md (L97 area) and GitHub Actions secrets scoping model)
L98 in content/what-is/what-is-a-github-action-secret.md "The GitHub audit log records secret-management events (create/update/delete) but not which workflow runs read a given secret." → ❌ contradicted (framing: shifted — claim says audit log records create/update/delete but NOT which workflow runs read a secret; source confirms workflow job prepared events DO include…; evidence: (escalated from pass1) The GitHub Changelog (Feb 2021) states that when a workflow job is prepared, the audit log event "will include the list of secrets that were provided to the runner" — directly contradicting the claim that the audit l…; source: https://github.blog/changelog/2021-02-23-github-actions-workflow-run-events-are-now-included-in-the-audit-log/)
L99 in content/what-is/what-is-a-github-action-secret.md "Updating a GitHub Actions secret overwrites the previous value with no first-class versioning." → ✅ verified (evidence: The file at L99 area explicitly states under the limits section: "No first-class versioning. Updating a secret overwrites the previous value." This is a direct match to the claim.; source: repo:content/what-is/what-is-a-github-action-secret.md)
L103 in content/what-is/what-is-a-github-action-secret.md "GitHub Actions OIDC lets workflows request a short-lived OIDC token that the cloud provider exchanges for temporary credentials, with nothing stored as a secre…" → ✅ verified (framing: strengthened — claim narrows the source's general OIDC description to a specific summary of the token-exchange flow; source's broader form proves the claim as…; evidence: The official GitHub docs confirm: "you can configure your workflow to request a short-lived access token directly from the cloud provider" and "No cloud secrets: You won't need to duplicate your cloud credentials as long-lived GitHub secre…; source: https://docs.github.com/en/actions/concepts/security/openid-connect)
L107-108 in content/what-is/what-is-a-github-action-secret.md "Stored secrets have a credential lifetime until manually rotated (often months), while OIDC + cloud role credentials last only minutes (provider-controlled) an…" → ✅ verified (framing: strengthened — claim narrows the source's general "short-lived … available only for the duration of the job" to the specific "minutes (provider-controlled)"; s…; evidence: GitHub's official OIDC docs confirm that cloud providers issue "a short-lived cloud access token that is available only for the duration of the job," and that "every token is scoped, auditable, and automatically rotated per workflow run."…; source: https://docs.github.com/en/actions/concepts/security/openid-connect)
L108 in content/what-is/what-is-a-github-action-secret.md "OIDC + cloud role credentials have a lifetime of minutes, controlled by the provider, and are automatically rotated per run." → ✅ verified (evidence: The file's comparison table explicitly states for "OIDC + cloud role": "Credential lifetime: Minutes (provider-controlled)" and "Rotation: Automatic per run", matching the claim exactly.; source: repo:content/what-is/what-is-a-github-action-secret.md (table under "What is OIDC and how does it compare to stored secrets?"))
L110 in content/what-is/what-is-a-github-action-secret.md "For AWS, Azure, GCP, HashiCorp Vault, and Pulumi ESC, OIDC is the recommended path for GitHub Actions workflows." (also L114, L184) → ✅ verified (framing: strengthened — claim narrows 'most modern cloud providers' to the specific named list (AWS, Azure, GCP, HashiCorp Vault, Pulumi ESC); source's broader form pro…; evidence: The file at the relevant section states: "For AWS, Azure, GCP, HashiCorp Vault, Pulumi ESC, and most modern cloud providers, OIDC is the recommended path." The claim accurately lists those specific providers and correctly…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L114 in content/what-is/what-is-a-github-action-secret.md "AWS, Azure, GCP, Vault, and Pulumi ESC support OIDC federation for GitHub Actions." → ✅ verified (framing: strengthened — claim narrows "most modern cloud providers" to the specific named list (AWS, Azure, GCP, Vault, Pulumi ESC); source's broader form proves the cl…; evidence: The article at L114 area explicitly states "For AWS, Azure, GCP, HashiCorp Vault, Pulumi ESC, and most modern cloud providers, OIDC is the recommended path." The ESC dynamic login credentials page confirms aws-login, azure…; source: repo:content/what-is/what-is-a-github-action-secret.md and repo:content/docs/esc/integrations/dynamic-login-credentials/_index.md)
L116 in content/what-is/what-is-a-github-action-secret.md "* Use the smallest scope that works. Repo > environment > org isn't a hierarchy of 'more powerful' — it's a hierarchy of blast radius. Pick the tightest on…" → ✅ verified (framing: strengthened — the claim reframes the scope hierarchy as "blast radius" rather than "power"; the source's access-breadth descriptions (environment < repo < org…; evidence: GitHub docs and multiple authoritative sources confirm that environment, repository, and organization represent three distinct scopes with different blast radii: environment secrets are scoped to a specific environment (tightest), reposito…; source: https://docs.github.com/en/code-security/reference/secret-security/understanding-github-secret-types — "Repository secret: all workflows in the repository can access the secret. Environment secret: secret is limited to jobs referencing that particular environment. Organization secret: all workflows in the repositories that have been granted access by the organization can access the organization secrets.")
L119 in content/what-is/what-is-a-github-action-secret.md "* Block secrets in forked PRs. The default is already to not pass them; resist any workflow design that requires pull_request_target with secrets unless…" → ✅ verified (evidence: GitHub's default behavior is to not pass secrets to workflows triggered by forked PRs. Multiple authoritative sources confirm this: "GitHub prevents PRs from forks from accessing secrets by default" and that pull_request_target is the me…; source: https://michaelheap.com/access-secrets-from-forks/ ; https://dev.to/petrsvihlik/using-environment-protection-rules-to-secure-secrets-when-building-external-forks-with-pullrequesttarget-hci ; https://blog.teddykatz.com/2021/03/17/github-actions-write-access.html)
L124 in content/what-is/what-is-a-github-action-secret.md "Pulumi's GitHub Actions integration uses a PULUMI_ACCESS_TOKEN for talking to the Pulumi Cloud backend and cloud-provider credentials (or OIDC) for the actua…" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
L126 in content/what-is/what-is-a-github-action-secret.md "A typical workflow with OIDC and Pulumi ESC:" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
L138 in content/what-is/what-is-a-github-action-secret.md "The pulumi/auth-actions action is available at version v1." → ✅ verified (evidence: The pulumi/auth-actions repository has releases v1.0.0 and v1.0.1, confirming the action is available at version v1.; source: gh release list -R pulumi/auth-actions --limit 10)
L142 in content/what-is/what-is-a-github-action-secret.md "The pulumi/actions action is available at version v6." → ✅ verified (framing: strengthened — v6 exists and is valid, but v7.0.0 is now the latest; the claim is technically correct as a subset of available versions; evidence: The pulumi/actions repository has multiple v6.x releases (v6.0.0 through v6.6.1), confirming that version v6 is available. Note that v7.0.0 is now the latest release as of 2026-05-04, so the claim is accurate but potentially outdated.; source: gh release list -R pulumi/actions --limit 10)
L150 in content/what-is/what-is-a-github-action-secret.md "Using the OIDC flow with pulumi/auth-actions, no PULUMI_ACCESS_TOKEN needs to be stored in GitHub; the OIDC flow exchanges the workflow's identity for a sh…" → ✅ verified (evidence: The pulumi/docs repo confirms: "Rather than storing a long-lived Pulumi access token as a repository secret, OIDC allows GitHub Actions to exchange a short-lived identity token for a scoped Pulumi access token at runtime." The pulumi/auth-…; source: gh search code --owner pulumi "auth-actions" (pulumi/docs:content/docs/esc/integrations/dev-tools/github.md and pulumi/auth-actions:README.md))
L151 in content/what-is/what-is-a-github-action-secret.md "Pulumi ESC brokers AWS/Azure/GCP credentials and rotates them on every run." → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
L154 in content/what-is/what-is-a-github-action-secret.md "Pulumi's GitHub Actions integration supports IaC pipelines in TypeScript, Python, Go, C#, Java, or YAML." → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
L160 in content/what-is/what-is-a-github-action-secret.md "GitHub Actions secrets are encrypted with a libsodium sealed box before they are transmitted to GitHub, stored encrypted at rest, and decrypted only on the run…" → ✅ verified (evidence: The file's "How are GitHub Actions secrets encrypted?" section states: "Secrets are encrypted with a libsodium sealed box before they're transmitted to GitHub," and the accompanying table confirms "Encrypted at rest in GitHub's storage" an…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L164 in content/what-is/what-is-a-github-action-secret.md "For a repository: Settings → Secrets and variables → Actions → New repository secret. For an environment: *Settings → Environments → <env> → Add secret…" → ➖ not-a-claim (evidence: The text at L164 describes GitHub's own UI navigation paths for creating secrets (a third-party interface). The same file's table (around line 40-46) corroborates these paths: "Repository → Settings → Secrets and variables → Actions", "Rep…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L168 in content/what-is/what-is-a-github-action-secret.md "The maximum size of a GitHub Actions secret is 64 KB." → ❌ contradicted (evidence: GitHub's official documentation states "Secrets are limited to 48 KB in size," not 64 KB as claimed. This is confirmed on both the Secrets reference page and the "Using secrets in GitHub Actions" guide.; source: https://docs.github.com/en/actions/reference/security/secrets and https://docs.github.com/actions/security-guides/using-secrets-in-github-actions; intuition: 64 KB is a plausible-sounding round number but is incorrect; the actual GitHub limit is 48 KB.)
L172 in content/what-is/what-is-a-github-action-secret.md "GitHub Actions supports up to 1,000 secrets per repository, 100 per environment, and 1,000 per organization." → ❌ contradicted (framing: shifted — claim states "1,000 secrets per repository" but source says 100 per repository; claim also states "1,000 per organization" which is correct, but the…; evidence: (escalated from pass1) Official GitHub Docs state: "You can store up to 1,000 organization secrets, 100 repository secrets, and 100 environment secrets." The claim inverts the repository and organization limits, asserting 1,000 per reposit…; source: https://docs.github.com/en/code-security/getting-started/understanding-github-secret-types)
L176 in content/what-is/what-is-a-github-action-secret.md "pull_request_target passes secrets to forked pull request workflows but executes against the base branch's workflow definition." → ✅ verified (evidence: (escalated from pass1) GitHub's official blog confirms both parts: pull_request_target "runs against the workflow and code from the base of the pull request" (not the fork), and "is given access to a read/write token as well as secrets."…; source: https://github.blog/news-insights/product-news/github-actions-improvements-for-fork-and-pull-request-workflows/)
L180 in content/what-is/what-is-a-github-action-secret.md "GitHub scans log output for known secret values and replaces matches with ***, but this does not work for transformations such as echo $MY_SECRET | base64,…" → ✅ verified (framing: strengthened — the file's intro broadly states the redactor can't catch transformations like base64 and set -x; the claim at L180 enumerates specific bypass sc…; evidence: The file itself states "Logs are scanned for secret values and automatically redacted, but the protection is real-time text matching — echo $MY_SECRET | base64 or set -x can still expose values in ways the redactor can't reliably catch…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L184 in content/what-is/what-is-a-github-action-secret.md "AWS, Azure, GCP, Vault, and Pulumi ESC support OIDC for GitHub Actions, issuing short-lived credentials per workflow run." → ➖ not-a-claim (evidence: The text at L184 is the PR author's own prose describing OIDC support: "For AWS, Azure, GCP, HashiCorp Vault, Pulumi ESC, and most modern cloud providers, OIDC is the recommended path." This is the author's own design/cont…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L188 in content/what-is/what-is-a-github-action-secret.md "Organization-level secrets in GitHub Actions allow selecting which repositories can access them." → ✅ verified (evidence: The file's scope table explicitly states that organization-level secrets are "Available to: Selected (or all) repositories in the org," confirming that organization-level secrets allow selecting which repositories can access them.; source: repo:content/what-is/what-is-a-github-action-secret.md)
L192 in content/what-is/what-is-a-github-action-secret.md "GITHUB_TOKEN is encrypted, redacted in logs, scoped to the job, and GitHub issues a fresh GITHUB_TOKEN for every workflow run and discards it at the end." → ❌ contradicted (framing: shifted — source says "scoped to the current repository"; claim says "scoped to the job" — different scope granularity; evidence: The file at the relevant passage states "GITHUB_TOKEN is a special, auto-issued, short-lived secret scoped to the current repository," but the claim asserts it is "scoped to the job" — a direct mismatch in scope. The claim also adds "Git…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L196 in content/what-is/what-is-a-github-action-secret.md "GitHub does not natively refresh stored secret values on a schedule; rotation requires updating the secret via the GitHub REST/GraphQL API or using OIDC." → ✅ verified (framing: strengthened — claim narrows "update them out of band" to specifically "via the GitHub REST/GraphQL API"; source's broader form proves the claim as a subset si…; evidence: The file itself states under limits: "No native rotation. GitHub doesn't expire or rotate values for you; you have to update them out of band (or use OIDC to avoid storing them at all)." The OIDC comparison table also confirms rotation is…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L196 in content/what-is/what-is-a-github-action-secret.md "Secrets can be rotated by updating them via the GitHub REST/GraphQL API from another workflow." → ✅ verified (framing: strengthened — the source broadly describes out-of-band rotation; the claim narrows this to the specific mechanism of REST/GraphQL API calls from another workf…; evidence: The file content confirms the document discusses GitHub secrets management and rotation. GitHub's REST API (PUT /repos/{owner}/{repo}/actions/secrets/{secret_name}) and GraphQL API do support creating/updating secrets, and these APIs can…; source: repo:content/what-is/what-is-a-github-action-secret.md)
L200 in content/what-is/what-is-a-github-action-secret.md "Pulumi pairs with GitHub Actions through OIDC and Pulumi ESC so cloud credentials never live in the repository, with workflows authenticating by identity and E…" → ➖ not-a-claim (evidence: The claim is a summary of the PR author's own content design: the new file describes Pulumi ESC and OIDC as alternatives to stored secrets in GitHub Actions. The master-branch version of the file (7469 bytes) contains no such content — it'…; source: gh api repos/pulumi/docs/contents/content/what-is/what-is-a-github-action-secret.md (master branch, 7469 bytes, no OIDC/ESC content))
L204-209 in content/what-is/what-is-a-github-action-secret.md "The page cross-references /what-is/what-is-a-cloudflare-secret/ as a related resource." → 🤷 unverifiable (evidence: (escalated from pass1) Both /what-is/what-is-a-github-action-secret/ and /what-is/what-is-a-cloudflare-secret/ are confirmed live Pulumi pages, but the rendered page content returned by search does not include the related-resources sec…; source: WebSearch ran query "pulumi 'what-is-a-github-action-secret' 'what-is-a-cloudflare-secret' related"; top results showed both pages exist but did not surface the related-resources section of the source file.)

Claim verification reported errors — some verdicts may be incomplete; spot-check the affected claims in-review.

🚨 Outstanding in this PR

These must be resolved or refuted before merging.

[L53] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Bigtable supports GoogleSQL (in preview) as a query interface." — verdict: contradicted; GoogleSQL for Bigtable is now GA (announced August 2024, multiple GA milestones since). Drop the preview qualifier.
```
- | Query interface | DynamoDB API, PartiQL | HBase API, Bigtable client libraries, GoogleSQL (preview) |
+ | Query interface | DynamoDB API, PartiQL | HBase API, Bigtable client libraries, GoogleSQL |
```
[L103] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Both DynamoDB and Bigtable target single-digit-millisecond p99 latency for well-designed workloads." — verdict: contradicted; only Bigtable explicitly targets single-digit ms at p99 — AWS frames DynamoDB latency as "Average SuccessfulRequestLatency", not p99. Re-frame so each side is described per its own vendor's metric, or drop "p99".
```
- Both services target **single-digit-millisecond p99 latency** for well-designed workloads, but the operational profile differs.
+ Both services target **single-digit-millisecond latency** for well-designed workloads (Bigtable explicitly at p99; DynamoDB on average), but the operational profile differs.
```
The "Is DynamoDB or Bigtable faster?" FAQ (L214) repeats the same p99 framing — apply the same fix there.

[L106] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Bigtable delivers consistent low latency for reads and writes proportional to the number of nodes in a cluster." — verdict: contradicted; Google's own docs describe throughput as scaling linearly with nodes, not latency. Latency stays low under load because per-node load drops; calling it "proportional to nodes" is wrong-shaped. The very next sentence already says throughput scales linearly — make the lead match.

- * **Bigtable** delivers consistent low latency for reads and writes proportional to the number of nodes in a cluster. Throughput scales linearly with nodes (roughly 10,000 ops/second/node on SSD), and large sequential scans are particularly efficient because data is stored in row-key order.
+ * **Bigtable** sustains low read and write latency by scaling **throughput** linearly with nodes (roughly 10,000 ops/second/node on SSD), so per-node load stays low as you grow the cluster. Large sequential scans are particularly efficient because data is stored in row-key order.

[L139] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Backups and import/export to Cloud Storage" (table cell) — verdict: contradicted; Google's docs are explicit: "You cannot export, copy, or move a Bigtable backup to another service, such as Cloud Storage." Backups live inside Bigtable; the Cloud Storage path is a separate Dataflow-based data import/export. Split the two.
```
- | Backup and restore | PITR (35 days), on-demand backups | Backups and import/export to Cloud Storage |
+ | Backup and restore | PITR (35 days), on-demand backups | In-instance backups; data import/export to Cloud Storage via Dataflow |
```

[L154] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Dataflow is the standard way to land streaming data into Bigtable tables." — verdict: contradicted (narrowed framing); Google now also documents Pub/Sub Bigtable subscriptions for direct streaming. Soften to "common" so the prose doesn't go stale as alternatives mature.

- Bigtable plugs into Google's analytics stack — BigQuery can query Bigtable directly, and Dataflow is the standard way to land streaming data into Bigtable tables.
+ Bigtable plugs into Google's analytics stack — BigQuery can query Bigtable directly, and Dataflow is a common way to land streaming data into Bigtable tables (Pub/Sub Bigtable subscriptions are another option).

[L238] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Bigtable supports GoogleSQL (in preview) and is also queryable from BigQuery via federation." — verdict: contradicted; same GoogleSQL-GA issue as L53 — repeat fix in the FAQ.

- DynamoDB supports a subset of SQL through PartiQL. Bigtable supports GoogleSQL (in preview) and is also queryable from BigQuery via federation.
+ DynamoDB supports a subset of SQL through PartiQL. Bigtable supports GoogleSQL and is also queryable from BigQuery via federation.

[L242] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Bigtable supports backups stored in the same instance and import/export to Cloud Storage." — verdict: contradicted; same backup/data conflation as L139 — repeat fix in the FAQ.

- Yes. DynamoDB supports point-in-time recovery (PITR) for 35 days and on-demand backups. Bigtable supports backups stored in the same instance and import/export to Cloud Storage.
+ Yes. DynamoDB supports point-in-time recovery (PITR) for 35 days and on-demand backups. Bigtable backups are stored inside the Bigtable instance (they can't be exported); for portability, use Bigtable's separate data import/export to Cloud Storage via Dataflow.

[L246] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Existing HBase applications can typically point at Bigtable with minor configuration changes." — verdict: contradicted; Google's own migration docs describe API-version updates, IAM auth conversion, and schema translation — not just config. Soften "minor configuration changes".

- No. The HBase API is specific to Bigtable. DynamoDB uses its own API (and PartiQL). Existing HBase applications can typically point at Bigtable with minor configuration changes.
+ No. DynamoDB uses its own API (and PartiQL). Bigtable speaks the open-source Apache HBase API via Google's HBase client for Bigtable, so existing HBase applications can usually port to Bigtable, but it isn't always drop-in — expect to swap the client library, update authentication to IAM, and account for HBase API version differences.

[L246] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "The HBase API is specific to Bigtable; DynamoDB uses its own API and PartiQL." — verdict: contradicted; the HBase API is an Apache project that predates Bigtable — Bigtable supports it, but it isn't Bigtable's. Folded into the L246 rewrite above (the new text drops "The HBase API is specific to Bigtable" and reframes Bigtable as speaking the HBase API).

[L153] content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md — "...up to 12 hours for role chaining and 1 hour for OIDC by default." — verdict: contradicted; the parenthetical has the two cases inverted. AWS caps role chaining at 1 hour, while AssumeRoleWithWebIdentity (OIDC) can go up to the role's MaxSessionDuration (up to 12 hours).

- By default, 1 hour, controlled by the `duration` field in the ESC environment. The maximum is bounded by the IAM role's `MaxSessionDuration` attribute (up to 12 hours for role chaining and 1 hour for OIDC by default).
+ By default, 1 hour, controlled by the `duration` field in the ESC environment. The maximum is bounded by the IAM role's `MaxSessionDuration` attribute — up to 12 hours for OIDC (`AssumeRoleWithWebIdentity`), with role chaining always capped at 1 hour regardless of `MaxSessionDuration`.

[L53] content/what-is/what-is-a-github-action-secret.md — "...only GitHub holds the corresponding private key to decrypt it on the runner." — verdict: contradicted; GitHub decrypts secrets server-side and then injects them into the workflow runtime; the runner never sees the private key. This is also the reason GITHUB_TOKEN, env-var injection, and log redaction all work. Per GitHub's docs: "Once the secret is uploaded, GitHub is then able to decrypt it so that it can be injected into the workflow runtime."

- Secrets are encrypted with a [libsodium sealed box](https://doc.libsodium.org/public-key_cryptography/sealed_boxes) before they're transmitted to GitHub. The repository or organization holds a public key; the secret is encrypted with that key client-side; only GitHub holds the corresponding private key to decrypt it on the runner.
+ Secrets are encrypted with a [libsodium sealed box](https://doc.libsodium.org/public-key_cryptography/sealed_boxes) before they're transmitted to GitHub. The repository or organization holds a public key; the secret is encrypted with that key client-side; only GitHub holds the corresponding private key. GitHub decrypts the secret server-side and injects the plaintext into the workflow runtime when a job that references it runs.

Also update the L59 table row to match — "Delivery to runner | Decrypted only when a job that references the secret runs" reads as if the runner does the decryption.

[L94-95] content/what-is/what-is-a-github-action-secret.md — "64 KB maximum size... Up to 1,000 secrets per repository, 100 per environment, and 1,000 per organization." — verdict: contradicted; GitHub's official limits are 48 KB per secret, and 100 repository / 100 environment / 1,000 organization secrets. The current text inflates the size limit and inverts the repo/org counts.

- * **64 KB maximum size** per secret. Large credential bundles (full service-account JSON files, multi-line certs) may need to be base64-encoded to fit, or stored externally.
- * **Up to 1,000 secrets** per repository, **100** per environment, and **1,000** per organization.
+ * **48 KB maximum size** per secret. Large credential bundles (full service-account JSON files, multi-line certs) may need to be base64-encoded to fit, or stored externally.
+ * **Up to 100 secrets** per repository, **100** per environment, and **1,000** per organization.

The same two values are repeated in the FAQ at L168 and L172 — apply the same fix there.

[L98] content/what-is/what-is-a-github-action-secret.md — "The audit log records secret-management events (create/update/delete) but not which workflow runs read a given secret." — verdict: contradicted; GitHub's Feb 2021 changelog: workflow-job-prepared audit events "will include the list of secrets that were provided to the runner." Reframe to "limited visibility into which steps used the secret".

- * **Limited audit detail.** The audit log records secret-management events (create/update/delete) but not which workflow runs read a given secret.
+ * **Limited audit detail.** The audit log records secret-management events (create/update/delete) and workflow-job-prepared events that list which secrets were provided to the runner, but it doesn't tell you which individual step inside that job actually used the secret.

[L168] content/what-is/what-is-a-github-action-secret.md — "64 KB. For larger payloads..." (FAQ) — verdict: contradicted; same 48 KB issue as L94. The FAQ has the wrong number again.

- 64 KB. For larger payloads (full service-account JSON, multi-line certificates), base64-encode the value before storing it, or store the payload in an external secrets manager and use a smaller secret to authenticate to that store.
+ 48 KB. For larger payloads (full service-account JSON, multi-line certificates), base64-encode the value before storing it, or store the payload in an external secrets manager and use a smaller secret to authenticate to that store.

[L172] content/what-is/what-is-a-github-action-secret.md — "Up to 1,000 per repository, 100 per environment, and 1,000 per organization." (FAQ) — verdict: contradicted; same inverted repo/org count as L95.

- Up to 1,000 per repository, 100 per environment, and 1,000 per organization. Hitting these limits usually means the secrets should live in a centralized store like [Pulumi ESC](/product/esc/) or [HashiCorp Vault](/what-is/what-is-hashicorp-vault/) instead.
+ Up to 100 per repository, 100 per environment, and 1,000 per organization. Hitting these limits usually means the secrets should live in a centralized store like [Pulumi ESC](/product/esc/) or [HashiCorp Vault](/what-is/what-is-hashicorp-vault/) instead.

⚠️ Low-confidence

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

[L178] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Both the Pulumi AWS provider and Google Cloud provider expose the full service surface for DynamoDB and Bigtable, including IAM, replication, backups, and auto…" — verdict: unverifiable; framing: narrowed — the specific features (IAM, replication, backups, autoscaling) are verifiably present in both providers, but "full service surface" is an overclaim…; evidence: The pulumi-aws DynamoDB provider includes tableReplica.go, getBackups.go, and resourcePolicy.go; the pulumi-gcp Bigtable provider includes instanceIamPolicy/Binding/Member, tableIamPolicy/Binding/Member, AutoscalingConfig, and backup-relat…; source: gh api repos/pulumi/pulumi-aws/contents/sdk/go/aws/dynamodb; gh api repos/pulumi/pulumi-gcp/contents/sdk/go/gcp/bigtable Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L28] content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md — "ESC-issued AWS sessions expire after the duration configured in the ESC environment, with a default of 1 hour." — verdict: unverifiable; evidence: All Pulumi ESC docs consistently show duration: 1h as an explicitly configured example value in YAML snippets, but no authoritative source states that 1 hour is the default when duration is omitted. The aws-login provider docs and OI…; source: WebSearch ran query "Pulumi ESC aws-login OIDC duration default value schema"; top results show duration: 1h only as an example, not as a documented default.; intuition: The claim conflates the commonly shown example value (1h) with a system default — no docs page explicitly states the de… Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L157] content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md — "The Pulumi GitHub Action, GitLab integration, and esc open / esc run in any CI runner all work the same way for using ESC-issued credentials in CI/CD." — verdict: unverifiable; framing: shifted — the cited source covers only esc run for AWS CLI; the claim extends this to assert equivalence across the Pulumi GitHub Action, GitLab integration,…; evidence: The cited blog post /blog/esc-env-run-aws/ focuses narrowly on using esc run for dynamic AWS CLI credentials and does not discuss the Pulumi GitHub Action, GitLab integration, or esc open as working "the same way." While other Pulumi d…; source: https://www.pulumi.com/blog/esc-env-run-aws/ (WebSearch dispatched but verification did not converge within the turn budget) Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L161] content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md — "Inside esc run, aws configure list reports access_key with Type=env, indicating it came from environment variables injected by ESC." — verdict: unverifiable; evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697… Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L165] content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md — "For OIDC AssumeRoleWithWebIdentity, Pulumi ESC uses the regional endpoint matching AWS_REGION if set, otherwise the global endpoint." — verdict: unverifiable; evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697… Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L169] content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md — "iam get-user only works for IAM users, requires the iam:GetUser permission, and fails when the caller is a role session." — verdict: unverifiable; evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697… Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L173-174] content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md — " Configuring OIDC between Pulumi and AWS"* — verdict: unverifiable; evidence: verification did not converge within 8 turns Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L3] content/what-is/what-is-a-github-action-secret.md — "GitHub Actions secrets support scopes: repository, environment, and organization." — verdict: unverifiable; evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697… Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L12] content/what-is/what-is-a-github-action-secret.md — "The GitHub Actions log redactor uses real-time text matching, so transformations like echo $MY_SECRET | base64 or set -x can still expose secret values in…" — verdict: unverifiable; framing: shifted — the cited source (REST API for secrets management) does not discuss log redaction; the correct source would be the GitHub Actions security guide; evidence: Official GitHub docs confirm the redactor uses exact-match text matching and that base64 transformations can bypass it ("redaction largely relies on finding an exact match"), but the specific framing "real-time text matching" and the set…; source: WebSearch ran query "GitHub Actions log redactor secret masking base64 set -x bypass"; https://docs.github.com/en/actions/reference/security/secure-use; intuition: The set -x` bypass claim is plausible (shell xtrace prints expanded variable values) but is not explicitly documented… Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L57-59] content/what-is/what-is-a-github-action-secret.md — "GitHub Actions secrets use NaCl crypto_box_seal for sealed-box encryption during submission." — verdict: unverifiable; evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697… Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L62] content/what-is/what-is-a-github-action-secret.md — "GitHub Actions secrets are discarded with the ephemeral runner after the job ends." — verdict: unverifiable; evidence: verify-claims.py errored on this claim: RuntimeError: HTTP 429: {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your organization's rate limit of 2,000,000 input tokens per minute (org: 85d1a054-3697… Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L124] content/what-is/what-is-a-github-action-secret.md — "Pulumi's GitHub Actions integration uses a PULUMI_ACCESS_TOKEN for talking to the Pulumi Cloud backend and cloud-provider credentials (or OIDC) for the actua…" — verdict: unverifiable; evidence: verification did not converge within 8 turns Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L126] content/what-is/what-is-a-github-action-secret.md — "A typical workflow with OIDC and Pulumi ESC:" — verdict: unverifiable; evidence: verification did not converge within 8 turns Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L151] content/what-is/what-is-a-github-action-secret.md — "Pulumi ESC brokers AWS/Azure/GCP credentials and rotates them on every run." — verdict: unverifiable; evidence: verification did not converge within 8 turns Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L154] content/what-is/what-is-a-github-action-secret.md — "Pulumi's GitHub Actions integration supports IaC pipelines in TypeScript, Python, Go, C#, Java, or YAML." — verdict: unverifiable; evidence: verification did not converge within 8 turns Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)
[L204-209] content/what-is/what-is-a-github-action-secret.md — "The page cross-references /what-is/what-is-a-cloudflare-secret/ as a related resource." — verdict: unverifiable; evidence: (escalated from pass1) Both /what-is/what-is-a-github-action-secret/ and /what-is/what-is-a-cloudflare-secret/ are confirmed live Pulumi pages, but the rendered page content returned by search does not include the related-resources sec…; source: WebSearch ran query "pulumi 'what-is-a-github-action-secret' 'what-is-a-cloudflare-secret' related"; top results showed both pages exist but did not surface the related-resources section of the source file. Author: can you confirm this against an authoritative source and add a citation if it isn't obvious from the existing prose? (Verifier hit rate limits or couldn't converge.)

Style findings

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

_{Click each filename to expand.}

content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md (10 issues: 4 weasel word, 2 first person, 2 hyphenation, 1 filler, 1 wordiness)

line 32: [style] hyphenation — 'fully-managed' doesn't need a hyphen.
line 32: [style] hyphenation — 'fully-managed' doesn't need a hyphen.
line 32: [style] weasel word — 'very' is a weasel word!
line 73: [style] weasel word — 'very' is a weasel word!
line 73: [style] filler — Don't start a sentence with 'There are'.
line 84: [style] wordiness — 'prioritize' is too wordy.
line 130: [style] weasel word — 'very' is a weasel word!
line 214: [style] weasel word — 'very' is a weasel word!
line 216: [style] first person — Avoid first-person pronouns such as ' I '.
line 228: [style] first person — Avoid first-person pronouns such as ' I '.

content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md (7 issues: 3 first person, 1 difficulty qualifier, 1 substitution, 1 units, 1 wordiness)

line 24: [style] difficulty qualifier — Avoid difficulty qualifier 'easily' -- it judges difficulty for the reader (STYLE-GUIDE.md §Inclusive Language).
line 58: [style] substitution — Use 'select' instead of 'click' (STYLE-GUIDE.md).
line 136: [style] units — Put a nonbreaking space between the number and the unit in '1h'.
line 145: [style] first person — Avoid first-person pronouns such as ' I '.
line 153: [style] wordiness — 'maximum' is too wordy.
line 155: [style] first person — Avoid first-person pronouns such as ' I '.
line 159: [style] first person — Avoid first-person pronouns such as ' I '.

content/what-is/what-is-a-github-action-secret.md (10 issues: 6 first person, 2 wordiness, 1 directional reference, 1 weasel word)

line 64: [style] directional reference — Directional reference ('see below') -- link directly to the target (an #anchor or relative path) rather than relying on 'above'/'below' (STYLE-GUIDE.md §Inclusive Language).
line 94: [style] wordiness — 'maximum' is too wordy.
line 162: [style] first person — Avoid first-person pronouns such as ' I '.
line 166: [style] wordiness — 'maximum' is too wordy.
line 170: [style] first person — Avoid first-person pronouns such as ' I '.
line 172: [style] weasel word — 'usually' is a weasel word!
line 174: [style] first person — Avoid first-person pronouns such as 'my'.
line 182: [style] first person — Avoid first-person pronouns such as ' I '.
line 186: [style] first person — Avoid first-person pronouns such as ' I '.
line 194: [style] first person — Avoid first-person pronouns such as ' I '.

github-actions · 2026-05-20T17:00:38Z

📋 Triaged verifier findings

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

[L152] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "DynamoDB supports the AWS SDKs and PartiQL as query interfaces." — verdict: contradicted. Spurious: the verifier flagged a wording mismatch with the at-a-glance table ("DynamoDB API, PartiQL") in the same file, but the ecosystem table (L152) describes "API compatibility" — and the AWS SDKs are how applications call the DynamoDB API in practice. Different framing for the same fact, not a contradiction.
[L97] content/what-is/what-is-a-github-action-secret.md — "Any workflow in the repository can read any repo-scoped secret; environments are the only way to gate access to a subset." — verdict: contradicted. Spurious: the verifier read this as "environments gate repo-scoped secrets", but in context the sentence means "environments are GitHub's only mechanism for finer-grained gating within a repo" — which is accurate; you move a secret to environment scope to gate it. The prose is fine.
[L192] content/what-is/what-is-a-github-action-secret.md — "GITHUB_TOKEN...scoped to the job..." — verdict: contradicted. Spurious: the verifier compared this against the earlier "scoped to the current repository" passage, but the two are describing different dimensions — GITHUB_TOKEN's permissions are scoped to the current repository and its lifetime is scoped to the job (it's issued per job and expires when the job ends, per GitHub's docs).

💡 Pre-existing issues in touched files (optional)

No pre-existing issues in touched files.

✅ Resolved since last review

No items resolved since the last review.

📜 Review history

2026-05-20T16:52:02Z — 15 factual contradictions surfaced across all three pages (GitHub Actions limits, Bigtable GoogleSQL/backups, STS MaxSessionDuration); 3 verifier findings triaged as spurious. (5c8889d)

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.)

Rewrite for SEO and AEO: quotable opening definition, semantic chunking with question-style H2s, FAQ section targeting doubt-removers, citable claims, and cross-links to secrets management resources. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

alexleventer had a problem deploying to testing May 20, 2026 16:46 — with GitHub Actions Failure

github-actions Bot added review:triaging Claude Triage is currently classifying the PR domain:docs PR touches technical docs review:in-progress Claude review is currently running and removed review:triaging Claude Triage is currently classifying the PR labels May 20, 2026

github-actions Bot added review:outstanding-issues Claude review completed; outstanding has author-actionable findings and removed review:in-progress Claude review is currently running labels May 20, 2026

alexleventer force-pushed the aleventer/github-action-secret-rewrite branch from 5c8889d to b2bdd3b Compare May 20, 2026 18:00

alexleventer had a problem deploying to testing May 20, 2026 18:00 — with GitHub Actions Failure

github-actions Bot added review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention and removed review:outstanding-issues Claude review completed; outstanding has author-actionable findings labels May 20, 2026

alexleventer marked this pull request as draft May 20, 2026 18:03

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

content(what-is): expand the GitHub Actions secret explainer#19263

content(what-is): expand the GitHub Actions secret explainer#19263
alexleventer wants to merge 1 commit into
masterfrom
aleventer/github-action-secret-rewrite

alexleventer commented May 20, 2026

Uh oh!

github-actions Bot commented May 20, 2026

Uh oh!

github-actions Bot commented May 20, 2026

Uh oh!

github-actions Bot commented May 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

alexleventer commented May 20, 2026

Summary

What changed

Test plan

Uh oh!

github-actions Bot commented May 20, 2026

Pre-merge Review — Last updated 2026-05-20T16:52:02Z

🔍 Verification trail

Uh oh!

github-actions Bot commented May 20, 2026

🚨 Outstanding in this PR

⚠️ Low-confidence

Style findings

Uh oh!

github-actions Bot commented May 20, 2026

📋 Triaged verifier findings

💡 Pre-existing issues in touched files (optional)

✅ Resolved since last review

📜 Review history

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant