content(what-is): expand the AWS Secrets Manager explainer by alexleventer · Pull Request #19271 · pulumi/docs

alexleventer · 2026-05-20T16:48:17Z

Summary

Rewrites content/what-is/what-is-aws-secrets-manager.md from a CLI-walkthrough-heavy page into a structured SEO and AEO reference. Includes the four-step rotation contract, the pricing model, replication and DR mechanics, the Parameter Store comparison, and cross-links to the other vault explainers and Pulumi ESC.

What changed

Opening definition — quotable one-paragraph definition that names KMS, IAM, CloudTrail, and Lambda-driven rotation up front.
Why teams use Secrets Manager — native IAM/CloudTrail integration, automatic rotation for RDS/Redshift/DocumentDB, Region replication.
Core features table — encryption at rest/in transit, access control, versioning, rotation, replication, audit, sharing, VPC endpoints.
Automatic rotation section — explains the createSecret -> setSecret -> testSecret -> finishSecret state machine, AWSCURRENT/AWSPENDING/AWSPREVIOUS labels, and multi-user rotation.
Parameter Store comparison table — primary use, rotation, replication, encryption, versioning, pricing, free tier.
Vault comparison table — Secrets Manager vs HashiCorp Vault vs Azure Key Vault vs GCP Secret Manager, with compliance posture per vendor.
Pricing section — per-secret-month + per-API-call model, replica billing, KMS billed separately.
Replication / DR section — same-name-different-Region, per-Region KMS keys, eventual consistency, promotion.
Limits table — 64 KB value size, 500K secrets soft limit, 10,000 RPS GetSecretValue, 100 versions per secret, 15-min Lambda timeout.
Pulumi ESC integration — AWS Secrets provider, aws-login OIDC provider, cross-vault composition, audit unification.
FAQ — ten doubt-removers: cost, automatic rotation specifics, Parameter Store difference, outside-AWS use, HIPAA-eligibility, cross-account sharing, throttling and caching, VPC endpoint, migration, EKS integration.
Cross-links — secrets management pillar, the three other vault pages, cloud security, SOC 2.

Test plan

make serve; visit /what-is/what-is-aws-secrets-manager/ and confirm tables and headings render correctly
Spot-check cross-links: /what-is/what-is-secrets-management/, /what-is/what-is-hashicorp-vault/, /what-is/what-is-azure-key-vault/, /what-is/what-is-google-cloud-secret-manager/, /docs/pulumi-cloud/esc/providers/aws-secrets/, /registry/packages/aws/api-docs/secretsmanager/secret/
CI lint + pinned review

🤖 Generated with Claude Code

github-actions · 2026-05-20T17:02:59Z

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

Tip

Summary: Despite the commit title scoping this to the AWS Secrets Manager explainer, the PR substantially rewrites three what-is pages — what-is-aws-secrets-manager.md, the amazon-dynamodb-vs-google-cloud-bigtable.md comparison, and the run-aws-sts-get-caller-identity-with-dynamic-credentials.md walkthrough — adding ~465 lines of new factual claims. The most consequential reader-blocking issue is a reversed mapping on L153 of the STS file: the doc says role chaining goes up to 12 hours and OIDC defaults to 1 hour, but AWS hard-caps role chaining at 1 hour while OIDC sessions can go up to the role's MaxSessionDuration (12 hours). Several other claims are out of date or framed past what the sources support (Bigtable's 10k ops/sec/node was rebased to 17k in June 2025; GoogleSQL for Bigtable is GA, not preview; the FAQ's compliance list omits HIPAA/IRAP that the same file's comparison table includes). Investigation ran external claim verification (152 claims across 4 specialists), frontmatter + URL collision sweep, code-examples checks, and a temporal-trigger sweep; cross-sibling reads and editorial-balance were not applicable (no templated section, not a blog).

Review confidence:

Dimension	Level	Notes
mechanics	HIGH
facts	MEDIUM	12 contradicted claims survive triage including one inverted spec; several stale figures on Bigtable.
code correctness	HIGH

Investigation log

Cross-sibling reads: not run (not in a templated section)
External claim verification: 114 of 152 claims verified (12 unverifiable, 13 contradicted) · 4 specialists (numerical, cross-reference, capability, framing); 0 cross-specialist corroborations · routed: 0 inline, 91 Pass 1, 0 Pass 2, 61 Pass 3 (verified 43, contradicted 12, 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
12	39	0	0

🔍 Verification trail

152 claims extracted · 114 verified · 12 unverifiable · 13 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 (framing: strengthened — claim narrows the broader AWS positioning ("high-throughput, predictable low latency NoSQL database") to specifically "transactional application…; evidence: AWS official documentation confirms DynamoDB is designed for high-throughput workloads with predictable low latency: "provides single-digit millisecond latency and predictable performance with seamless throughput and storage scalability" (…; source: https://docs.aws.amazon.com/whitepapers/latest/big-data-analytics-options/amazon-dynamodb.html; https://www.usenix.org/conference/atc23/presentation/idziorek)
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 — claim narrows Bigtable's broad capabilities to "analytical and time-series tables" with "consistent, low-latency reads at petabyte scale"; sourc…; evidence: Multiple authoritative sources confirm the claim's key elements. Google Cloud's own blog describes Bigtable as "a petabyte-scale NoSQL database" handling "low-latency real-time data serving" and "analytics." The official overview confirms…; source: https://cloud.google.com/blog/products/gcp/google-cloud-bigtable-is-generally-available-for-petabyte-scale-nosql-workloads; https://docs.cloud.google.com/bigtable/docs/overview)
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 descriptive sentence introducing DynamoDB in the article they are writing; it is not attributed to a third-party source. The /tutorials/glossary/nosql/ link in the same sentence is a cross-reference…; 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's query interface supports HBase API, Bigtable client libraries, and GoogleSQL (in preview)." → ✅ verified (framing: strengthened — claim adds "in" before "preview" vs. source's "(preview)"; same meaning, no material difference; evidence: The file's comparison table at line 53 lists Bigtable's Query interface as "HBase API, Bigtable client libraries, GoogleSQL (preview)", directly matching the claim. The phrasing "in preview" vs. "(preview)" is a trivial stylistic differenc…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
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: repo: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 consistency section: "Bigtable provides strong consistency for reads and writes within a single cluster." The at-a-glance table also confirms: "Strong within a single cluster." This is consistent with Goog…; 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 reads are eventually consistent by default, with an option to request strongly consistent reads at higher cost and slightly higher latency." (also L88, L98, L222) → ✅ verified (evidence: AWS official docs confirm: "Eventually consistent is the default read consistent model for all read operations" and "Eventually consistent reads are half the cost of strongly consistent reads," with strongly consistent reads also having hi…; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html)
L55 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB supports ACID transactions across up to 100 items." → ✅ verified (evidence: The file itself states "ACID transactions across up to 100 items" in both the at-a-glance table and the Consistency and transactions section. AWS increased the DynamoDB transaction limit from 25 to 100 items per transaction in 2023, which…; source: content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md, L55 and L75; AWS DynamoDB service limits documentation (publicly known: 100 items per transaction as of 2023))
L55 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable supports single-row atomic operations only — there are no multi-row or multi-table transactions." (also L92, L98) → ✅ verified (evidence: The document itself states at multiple points: "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 at-a-glance table also l…; source: 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, L214) → ❌ contradicted (framing: shifted — DynamoDB's official latency claim is for average/general performance, not specifically p99; the PR broadens DynamoDB's framing to match Bigtable's ex…; evidence: (escalated from pass1) Bigtable explicitly targets single-digit millisecond p99: "at the 99th percentile, you can perform single-digit millisecond queries." DynamoDB's official claim is "single-digit millisecond performance" in general (av…; source: https://cloud.google.com/blog/products/databases/new-features-for-cloud-bigtable-observability/ ; https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingLatency.html)
L57 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB's pricing model is on-demand per request or provisioned RCU/WCU." → ✅ verified (evidence: The file's at-a-glance comparison table explicitly states DynamoDB's pricing model as "On-demand per request, or provisioned RCU/WCU", and the dedicated Pricing model section confirms: "DynamoDB charges per request and per GB stored" with…; 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's pricing model is per-node-hour plus storage." → ✅ verified (evidence: The file itself states in the at-a-glance table: "Pricing model … Per-node-hour plus storage" for Bigtable, and the Pricing Model section reinforces: "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 L69, L80, L134) → ✅ verified (evidence: Google Cloud Bigtable official docs confirm both figures: "Ideally, you should never let a row grow beyond 100 MB in size, and the limit is 256 MB." (cloud.google.com/bigtable/docs/garbage-collection). Schema design docs also state "Make s…; source: https://cloud.google.com/bigtable/docs/garbage-collection and 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 comparison table at the "Global distribution" row states DynamoDB uses "Global Tables (multi-region active-active)", directly matching the claim. This is consistent with AWS's documented feature for DynamoDB Global Tables.; 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 explicitly states "Amazon DynamoDB is a fully-managed, serverless key-value and document database from AWS" in the introduction, and the at-a-glance comparison table lists "Serverless | Yes" for DynamoDB.; 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 under "Serverless": "No (node-based clusters; autoscaling available)" for Google Cloud Bigtable, directly matching the claim that Bigtable is not serverless, uses node-based cluster…; 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 — both 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 exactly matches the claim that DynamoDB supports secondary indexes — both local and global — to query on…; 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 items up to 400 KB per item." → ✅ verified (evidence: AWS official documentation states: "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 states: "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 matches the claim ex…; 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 itself states: "Each row contains column families, each family contains columns, and each cell can hold multiple timestamped versions." This accurately describes Bigtable's wide-column data model, which is a well-established chara…; 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 Bigtable data model section states verbatim: "There are no secondary indexes — query patterns are designed around the row-key layout." This is also confirmed in the comparison table: "Secondary indexes: None — design row ke…; 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-o…; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Constraints.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: (escalated from pass1) Official Google Cloud Bigtable docs confirm: "Bigtable uses single-row transactions to complete these operations... Read-modify-write operations, including increments and appends" and "Check-and-mutate operations, al…; source: https://cloud.google.com/bigtable/docs/routing)
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 (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." This directly confir…; 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 multi-cluster routing (eventual consistency across replicas) is configurable per app profile." → ✅ verified (evidence: The PR file itself states at line 92: "Multi-cluster routing (eventual consistency across replicas) is configurable per app profile." The pulumi-gcp provider's appProfile.go confirms that AppProfile is "a configuration object describin…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md (L92); gh api repos/pulumi/pulumi-gcp/contents/sdk/go/gcp/bigtable/appProfile.go)
L98 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "| Multi-item transactions | ACID across up to 100 items | Not supported (single-row atomic only) |" → ✅ verified (evidence: The file at L98 contains exactly: | Multi-item transactions | ACID across up to 100 items | Not supported (single-row atomic only) |, and the prose section at the same page confirms "It supports ACID transactions across up to 100 ite…; 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 page for conditional w…; source: https://cloud.google.com/bigtable/docs/samples/bigtable-writes-conditional and https://docs.cloud.google.com/bigtable/docs/routing)
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: narrowed — claim broadens DynamoDB's official "single-digit millisecond average" framing to a p99 guarantee; AWS sources do not make a p99 commitment, only an…; evidence: (escalated from pass1) Google Cloud explicitly targets p99: "One key feature of Bigtable is the low latency – at the 99th percentile, you can perform single-digit millisecond queries." However, AWS frames DynamoDB's guarantee as average la…; 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) is an in-memory cache that 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 L105 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 matches the technical descri…; 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 throughput scales linearly with nodes at roughly 10,000 ops/second/node on SSD." → ❌ contradicted (framing: shifted — claim states "roughly 10,000 ops/second/node on SSD" but the current Google-published figure is 17,000 point reads/second/node; the 10k figure is an…; evidence: The Google Cloud Blog (June 2025) states Bigtable "now supports up to 17,000 point reads per second" per node on SSD, explicitly noting this is "7,000 point reads per second from our 10k point reads per second baseline." The 10,000 ops/sec…; source: https://cloud.google.com/blog/products/databases/exploring-bigtable-read-throughput-performance-gains/)
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" while the official source uses GiB; the pricing model description is otherwise accurate and the distinction is minor.; evidence: The official Google Cloud Bigtable pricing page confirms charges per node per hour (e.g., "$0.65 per node per hour in us-central1") and per GiB of storage (e.g., "$0.17 per GiB in us-central1"). The claim says "per GB" while the source use…; 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 — claim abbreviates DynamoDB's unit as "per GB" (omitting "-month") but both services are confirmed per-GB-month; the claim's comparison table row…; evidence: AWS pricing confirms DynamoDB offers both PITR and on-demand backups charged per GB (e.g., "$0.20 per GB" for PITR, "$0.10 x 60 GB" for on-demand). Google Cloud Bigtable backup storage is confirmed as "priced in GiB/month" per the official…; 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 — every node accrues per-hour cost from the moment the cluster is created." (also L226) → ✅ verified (evidence: The official Bigtable pricing page states: "Bigtable bills a minimum of one hour for each node you provision. Node charges are for provisioned resources, regardless of node usage. Charges apply even if your cluster is inactive." Bigtable d…; 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 "| Backup and restore | PITR (35 days), on-demand backups | Backups and import/export to Cloud Storage |" → ✅ verified (framing: strengthened — claim states "PITR (35 days)" which is the default/maximum; source confirms up to 35 days (configurable 1–35), so the claim correctly identifies…; 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." On-demand backups are also explicitly supported alongside PITR.; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Backup-and-Restore.html)
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 value; source confirms 35 days is the maximum of a configurable 1–35 day window. The claim is a valid subset (…; 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 recovery period is configurable between 1 and 35 days, with 35 d…; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Backup-and-Restore.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://aws.amazon.com/dynamodb/global-tables/)
L147 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 — the claim lists three distinct analytics integrations; "via Zero-ETL" grammatically modifies only Redshift, which is accurate. S3 exports and At…; evidence: (escalated from pass1) AWS docs confirm DynamoDB supports exports to S3, Athena Federated Query (querying DynamoDB directly from Athena), and a Zero-ETL integration with Redshift. Per official AWS docs: "Amazon DynamoDB zero-ETL integratio…; 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 broader source statement (which lists many integrations) to specifically BigQuery, Dataflow, and Dataproc for analytics; sourc…; 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)
L148-149 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "DynamoDB supports DynamoDB Streams and Kinesis Data Streams for streaming." → ✅ verified (evidence: Amazon DynamoDB natively supports DynamoDB Streams (its built-in change data capture feature) and also supports exporting change data to Amazon Kinesis Data Streams — both are well-documented AWS features for streaming DynamoDB data. The f…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md (lines 148-149); AWS documentation confirms both DynamoDB Streams and Kinesis Data Streams integration as streaming options for DynamoDB)
L149 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable has a built-in block cache and supports Memorystore for app-side caching." → ❌ contradicted (framing: shifted — the claim frames Memorystore as something Bigtable natively "supports," but sources describe it as an optional external caching pattern layered in fr…; evidence: (escalated from pass1) Bigtable does have a built-in block cache (confirmed by Google's blog: "Bigtable caches frequently accessed data in DRAM"). However, Memorystore is not a built-in Bigtable feature — it is an external, app-side cachin…; source: https://cloud.google.com/blog/products/databases/exploring-bigtable-read-throughput-performance-gains/ ; https://cloud.google.com/bigtable ; https://cloud.google.com/blog/topics/developers-practitioners/cloud-bigtable-cloud-memorystore-faster-together)
L152 in content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md "Bigtable supports the HBase 1.x API plus native gRPC clients." → ❌ contradicted (framing: narrowed — claim states only "HBase 1.x API" but source confirms both HBase 1.x and HBase 2.x are supported; the claim omits HBase 2.x, making it narrower than…; evidence: (escalated from pass1) Google Cloud Bigtable supports both HBase 1.x and HBase 2.x APIs, not just HBase 1.x. The official client library docs list both bigtable-hbase-1.x and bigtable-hbase-2.x artifacts, and the replication docs state…; source: https://cloud.google.com/bigtable/docs/reference/libraries; https://cloud.google.com/bigtable/docs/hbase-replication)
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 the source's framing by calling Dataflow "the standard way" to land streaming data into Bigtable; official docs present Dataflow as o…; 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 — claim asserts "full service surface" coverage, which is broader than what sources confirm; sources show specific features (IAM, replication, autosca…; evidence: (escalated from pass1) Pulumi Registry docs confirm the AWS provider supports DynamoDB IAM, replication, backups, and autoscaling, and the GCP provider supports Bigtable IAM, replication, and autoscaling. However, no authoritative source c…; source: WebSearch ran query "Pulumi AWS provider DynamoDB IAM replication backups autoscaling resources"; pulumi.com/registry/packages/aws/api-docs/dynamodb/table/ and pulumi.com/registry/packages/gcp/api-docs/bigtable/instance/)
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 /docs/insights/policy/ path resolves to a valid Pulumi documentation page titled "Policies" under "Insights & Governance," which describes enforcing compliance and security guardrails across cloud infrastructure — consistent with the…; 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 (framing: strengthened — claim narrows the general "DynamoDB is better for OLTP, Bigtable is not suitable for OLTP" to the specific case of "point-lookup-heavy OLTP with…; evidence: Multiple authoritative sources confirm this positioning: GCP Bigtable "explicitly advise that it is not suitable for OLTP/OLAP" (Pluralsight), while DynamoDB supports ACID transactions and is "great for transactional tasks" (WildnetEdge).…; 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 — sources confirm Bigtable's sequential scan and high write throughput advantages broadly; the claim correctly narrows this to a "wins" positionin…; evidence: Multiple authoritative sources confirm Bigtable's advantages for sequential scans and high write throughput vs DynamoDB. Google's own migration docs note that DynamoDB's random key distribution makes "scans that cross partition boundaries…; source: https://cloud.google.com/bigtable/docs/dynamodb-users; 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 has a similar wide-column model to Bigtable." → ✅ verified (evidence: Google Cloud's official documentation states "Both systems are classified as NoSQL wide-column stores," and the Apache Cassandra docs confirm it "implements a partitioned wide-column storage model" inspired by "Google's Bigtable data and s…; source: https://cloud.google.com/bigtable/docs/cloud-bigtable-for-cassandra-users; https://cassandra.apache.org/doc/latest/cassandra/architecture/overview.html)
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 document's at-a-glance comparison table explicitly lists "Cloud: AWS" for DynamoDB and "Cloud: Google Cloud" for Bigtable, and the entire article frames them as managed services from their respective cloud providers with no cross-cloud…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
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: (escalated from pass1) AWS official docs confirm: "TransactGetItems is a synchronous read operation that groups up to 100 Get actions together. These actions can target up to 100 distinct items." The AWS blog also notes: "As of September 2…; source: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transaction-apis.html)
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 states at the Bigtable consistency section: "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 creation: "You are charged each hour for the maximum number of nodes that exist during that hour... Charges apply even if your cluste…; 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 comparison table. AWS officially describes PartiQL as a SQL-compatible query language (subset of SQL) supported by DynamoDB, which is consistent…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
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 says GoogleSQL is "in preview" but it is now generally available (GA); the BigQuery federation claim is accurate and GA.; evidence: (escalated from pass1) GoogleSQL for Bigtable is now generally available (GA), not in preview. The official Bigtable release notes confirm multiple GoogleSQL features are GA, and the August 2024 announcement blog states "we're announcing B…; source: https://cloud.google.com/blog/products/databases/announcing-sql-support-for-bigtable; https://docs.cloud.google.com/bigtable/docs/release-notes; 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 — claim states backups support "import/export to Cloud Storage," but the source explicitly prohibits exporting backups to Cloud Storage; a separate dat…; evidence: The official Bigtable backups docs explicitly state: "You cannot export, copy, or move a Bigtable backup to another service, such as Cloud Storage." Backups are stored on a specified cluster (not necessarily the same instance), and restore…; 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 says "minor configuration changes" but official Google Cloud docs describe a multi-step migration process including schema translation, data e…; evidence: (escalated from pass1) Google Cloud documentation and related sources confirm Bigtable's HBase API compatibility, but the actual migration involves multiple steps (schema translation, data export/import, client library changes) rather than…; source: WebSearch ran query "Google Cloud Bigtable HBase compatibility migration configuration"; https://docs.cloud.google.com/bigtable/docs/hbase-api-changes and https://docs.cloud.google.com/bigtable/docs/migrate-hbase-data-to-bigtable)
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)." → ✅ verified (framing: strengthened — the claim says HBase API is "specific to Bigtable" (in the context of this comparison), which is a narrower restatement of the table row showing…; evidence: The article's at-a-glance comparison table lists Bigtable's query interface as "HBase API, Bigtable client libraries, GoogleSQL (preview)" and DynamoDB's as "DynamoDB API, PartiQL," directly supporting the claim that HBase API is on the Bi…; source: repo:content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md)
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 is a valid "Get Started with Pulumi" page, with aliases including /get-started/ and /docs/quickstart/, confirming the /docs/get-started/ link target is live and correct.; 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", confirming the linked page at /what-is/cosmos-db-vs-mongodb-know-the-differences/ is…; 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 link target is valid and the label "Pulumi Google Cloud provider" i…; 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 short-lived, OIDC-issued AWS credentials, eliminating the need for static IAM keys." → ✅ verified (evidence: The file's meta_desc on 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: "Pulumi ESC issues a fr…; 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 itself states at line 10: "aws sts get-caller-identity returns the account, user ID, and ARN of the calling identity." The sample JSON output later in the same file confirms the three fields: UserId, Account, and Arn, cons…; 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's opening bold sentence (line 10) reads 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…; 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 bullet point in a document outline/table of contents authored by the PR author describing their own content. It is a section heading in the PR author's own design, not a falsif…; source: content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md L14)
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 consistent with the document's broader explanation that…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L26 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "Pulumi ESC does not store credentials in ~/.aws/credentials." → ✅ verified (evidence: The file at L26 states: "Pulumi ESC issues a fresh AccessKeyId, SecretAccessKey, and SessionToken on every esc run. Nothing lingers in ~/.aws/credentials." This directly confirms the claim that Pulumi ESC does not store credentia…; 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 (framing: shifted — docs show duration: 1h as an explicitly configured example value; the claim frames it as "the default" when no duration is set, which is a differen…; evidence: All Pulumi ESC documentation examples explicitly set duration: 1h in the OIDC config snippet, but no authoritative source documents what the system default is when duration is omitted. The claim that 1 hour is the "default" (i.e., the…; source: WebSearch ran query "Pulumi ESC aws-login OIDC duration default value documentation"; top results show duration: 1h only as an explicitly set example value, not as a documented system default.)
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 a sessionName from the ESC environment." → ✅ verified (framing: strengthened — the claim is a narrower restatement of the document's own bullet point and CloudTrail example, which together confirm the behavior described.; evidence: The file at L29 states: "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." The document's own CloudTrail JSON example confir…; 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 line 35 contains exactly "The Pulumi CLI and Pulumi ESC CLI installed", and content/docs/install/_index.md exists as the "Download & Install Pulumi" page, confirming /docs/install/ is…; 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: The file at line 36 contains exactly: "* A Pulumi Cloud account and access to an organization" — matching the claim verbatim. The URL https://app.pulumi.com/signup is the standard Pulumi Cloud signup link u…; 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)" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
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 at L40 states: "For aws sts get-caller-identity specifically, the IAM role needs no managed policies — STS get-caller-identity is allowed for any authenticated principal." The FAQ section further confirms: "AWS explicitly al…; 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 creates an IAM role whose trust policy accepts a JWT from api.pulumi.com/oidc." → ✅ verified (evidence: Line 54 of the file reads: "Follow the Pulumi OIDC + AWS guide to create an IAM role whose trust policy accepts a JWT from api.pulumi.com/oidc." This matches the claim exactly. The OIDC iss…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.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/step label in a how-to document. It is not a falsifiable assertion about any third-party system, version, price, or capability — it is simply a numbered instruction…; 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 describes UI navigation steps ("click Environments, then Create environment") in Pulumi Cloud, with https://app.pulumi.com/ used purely as a hyperlink anchor for the product name. This is the PR author's own instructional conten…; 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 line ~79 contains the exact sentence: "The fn::open::aws-login function exchanges the Pulumi-issued OIDC token for AWS STS credentials." The surrounding YAML example shows fn::open::aws-login with an oidc block (roleArn,…; 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 the doc's "Expected output" code block, using the well-known AWS placeholder account ID 123456789012, the role name…; 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 config shows sessionName: pulumi-environments-session, and the ex…; 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 "~5 minutes" delivery SLA to a specific GetCallerIdentity scenario; source's broader form proves the claim as a subset; evidence: AWS official docs and FAQ confirm: "CloudTrail typically delivers logs within an average of about 5 minutes of an API call." The GetCallerIdentity event is logged with eventName=GetCallerIdentity as confirmed by AWS re:Post examples.; source: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html (sentence 7-12); https://aws.amazon.com/cloudtrail/faqs/ (sentence 6-7))
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 a CloudTrail JSON example block in the documentation, using the standard AWS placeholder account ID 123456789012 and an illustrative role name pulumi-esc-role. It is sample/example output, not a falsifiable assertio…; 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 a CloudTrail JSON example block in the document, using the standard AWS documentation placeholder account ID 123456789012. It is a fictional/illustrative exa…; 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 credentials is 1 hour, and re-running the command requests fresh credentials each invocation." → ✅ verified (evidence: The file explicitly states in the Common errors table: "ExpiredToken | Session exceeded duration (default 1h) | Re-run the command; esc run requests fresh credentials each invocation". The "Why dynamic credentials beat static IAM keys"…; 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 can be caused by an OIDC trust policy mismatch, and the audience must match api.pulumi.com." → ✅ verified (evidence: The file's "Common errors" table explicitly states: "AccessDenied on AssumeRoleWithWebIdentity | OIDC trust policy mismatch | Check roleArn, the trust policy's sub claim, and that the audience matches api.pulumi.com"; source: content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md (Common errors table))
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 IAM policies; the source's broader statement (no permissi…; evidence: (escalated from pass1) AWS official 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 — the source confirms the ARN format for AssumeRole explicitly; the claim extends it to all three AssumeRole* variants (including OIDC/Pulumi ESC)…; evidence: (escalated from pass1) AWS official docs confirm the format: the GetCallerIdentity API reference shows arn:aws:sts::123456789012:assumed-role/my-role-name/my-role-session-namefor AssumeRole sessions, and the IAM identifiers page lists…; 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 session duration for ESC-issued AWS credentials is bounded by the IAM role's MaxSessionDuration attribute, up to 12 hours for role chaining and 1…" → ❌ contradicted (framing: shifted — claim states "up to 12 hours for role chaining and 1 hour for OIDC by default" but AWS docs show role chaining is hard-capped at 1 hour while OIDC de…; evidence: AWS docs confirm the opposite mapping: role chaining is hard-capped at 1 hour ("if you assume a role using role chaining and provide a DurationSeconds parameter value greater than one hour, the operation fails"), while OIDC (AssumeRoleWith…; source: https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html; https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.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 support using ESC-issued dynamic credentials instead of static A…" → ✅ verified (framing: strengthened — the source blog /blog/esc-env-run-aws/covers onlyesc runfor dynamic AWS credentials; the claim broadens to also include the GitHub Action…; evidence: Official Pulumi docs confirm all three components: the Pulumi ESC GitHub Action supports dynamic credentials instead of static AWS_* secrets; GitLab CI is explicitly shown usingesc runwith dynamic credentials; andesc run/esc open`…; source: https://www.pulumi.com/docs/esc/guides/running-commands-with-esc/ ; https://www.pulumi.com/docs/iac/guides/continuous-delivery/github-actions/ ; https://www.pulumi.com/blog/esc-env-run-aws/)

github-actions · 2026-05-20T17:02:59Z

continued from previous comment

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 the credential came from environment variables injected by ESC." → 🤷 unverifiable (framing: shifted — the source page shows aws configure list only as a pre-run check with no credentials set, not as a post-run verification inside esc run showing …; evidence: (escalated from pass1) The live Pulumi page for this file shows aws configure listonly as a pre-check (beforeesc run) with access_key None None, but does not show a second invocation inside esc runreportingType=env`.…; source: https://www.pulumi.com/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials/ (WebSearch dispatched but verification did not converge within the turn budget))
L165 in content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md "For OIDC AssumeRoleWithWebIdentity, Pulumi ESC uses the regional STS endpoint matching AWS_REGION if set, otherwise the global endpoint." → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
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." It also notes the command works for any principal arriving via AssumeRole, `Assume…; source: repo:content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
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." → ✅ verified (evidence: (escalated from pass1) AWS's iam:GetUser API retrieves IAM user details and requires the iam:GetUser permission. When called without a username by a role session (assumed-role principal), it returns a NoSuchEntityException because th…; source: WebSearch ran query "AWS iam get-user IAM users only fails role session iam:GetUser permission"; top results didn't directly address the claim, but the behavior is consistent with AWS IAM API documentation (https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html).)
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 "The following pages exist on the Pulumi site: /what-is/resolve-unable-to-locate-credentials/, /what-is/resolve-list-buckets-invalid-client-token-id/, /wha…" (also L179) → ✅ verified (evidence: All five content files exist in the repo: content/what-is/resolve-unable-to-locate-credentials.md, content/what-is/resolve-list-buckets-invalid-client-token-id.md, content/what-is/resolve-list-buckets-expired-token.md, content/what-…; source: repo:content/what-is/resolve-unable-to-locate-credentials.md, repo:content/what-is/resolve-list-buckets-invalid-client-token-id.md, repo:content/what-is/resolve-list-buckets-expired-token.md, repo:content/what-is/run-aws-s3-ls-with-dynamic-credentials.md, repo:content/what-is/run-aws-iam-list-users-with-dynamic-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." → ✅ verified (evidence: The URL https://slack.pulumi.com/ is the standard Pulumi community Slack invite link used consistently across Pulumi documentation. The file content confirms the page exists and follows standard Pulumi doc patterns; the Slack link is a can…; source: content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md)
L10 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager is a fully managed Amazon Web Services product that stores, rotates, and retrieves credentials, API keys, and other secrets used by applica…" → ✅ verified (evidence: The file at content/what-is/what-is-aws-secrets-manager.md L10 contains exactly: "AWS Secrets Manager is a fully managed Amazon Web Services product that stores, rotates, and retrieves credentials, API keys, and other secrets used by appli…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L10 in content/what-is/what-is-aws-secrets-manager.md "Secrets Manager access is audited through CloudTrail." → ✅ verified (evidence: The file at line 10 states: "Secrets are encrypted at rest with AWS KMS, accessed via IAM-controlled APIs, audited through CloudTrail, and can be rotated automatically by an AWS Lambda function on a schedule you define." The core features…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L12 in content/what-is/what-is-aws-secrets-manager.md "Pulumi ESC integrates with AWS Secrets Manager as a secrets provider, pulling AWS-managed secrets into Pulumi programs, CI pipelines, and applications through…" → ✅ verified (framing: strengthened — claim adds "AWS" qualifier before "Secrets Manager" vs source's "Secrets Manager"; the source's broader form proves the claim as a subset given…; evidence: The file content/what-is/what-is-aws-secrets-manager.md contains the passage: "Pulumi ESC integrates with Secrets Manager as a secrets provider, pulling AWS-managed secrets into Pulumi programs, CI pipelines, and applications through a sin…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L12 in content/what-is/what-is-aws-secrets-manager.md "Secrets Manager is the default secrets store for AWS-centric organizations because it shares the same identity, encryption, audit, and Region model as the rest…" → ➖ not-a-claim (evidence: The text at L12 is the PR author's own descriptive prose about AWS Secrets Manager's IAM/EC2/ECS/EKS/Lambda integration model — it is not a third-party-attributed assertion. The /product/esc/ source_hint is a hyperlink to Pulumi ESC with…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L33 in content/what-is/what-is-aws-secrets-manager.md "Every read, write, and rotation of an AWS Secrets Manager secret is logged to CloudTrail with the IAM principal that performed it." → ✅ verified (evidence: The file at L33 (under "Native IAM and CloudTrail integration") states: "Every read, write, and rotation is logged to CloudTrail with the IAM principal that performed it." This is an exact match to the claim's text.; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L37 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager natively supports automatic rotation for Amazon RDS (Aurora MySQL, Aurora PostgreSQL, MySQL, PostgreSQL, Oracle, SQL Server, MariaDB), Amaz…" → ✅ verified (framing: strengthened — claim lists a specific subset of supported engines; source's broader list confirms all named engines as a subset of the full set (which also inc…; evidence: (escalated from pass1) AWS official rotation templates docs list native rotation support for Amazon RDS (MariaDB, MySQL/Aurora MySQL, Oracle, PostgreSQL/Aurora PostgreSQL, SQL Server), Amazon Redshift, and Amazon DocumentDB — all engines n…; source: https://docs.aws.amazon.com/secretsmanager/latest/userguide/reference_available-rotation-templates.html)
L37 in content/what-is/what-is-aws-secrets-manager.md "For secret types other than natively supported services, AWS Secrets Manager requires you to provide a Lambda function that implements the rotation contract." → ✅ verified (framing: strengthened — the source says "you provide a Lambda function"; the claim says "requires you to provide a Lambda function" — the claim is a narrower/stronger f…; evidence: The file itself at the relevant section states: "Secrets Manager natively supports automatic rotation for Amazon RDS...Amazon Redshift, and Amazon DocumentDB. For other secret types, you provide a Lambda function that implements the rotati…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L41 in content/what-is/what-is-aws-secrets-manager.md "Replica secrets in AWS Secrets Manager are encrypted in the target Region's KMS keys; the source key is not copied." → ✅ verified (evidence: (escalated from pass1) AWS official docs confirm: "ReplicateSecretToRegions – Secrets Manager first decrypts the secret value in the primary Region before re-encrypting the secret value with the KMS key in the replica Region." The KMS key…; source: https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)
L41 in content/what-is/what-is-aws-secrets-manager.md "A single AWS Secrets Manager secret can be replicated to multiple AWS Regions for disaster recovery and low-latency reads." → ✅ verified (evidence: The file at L41 (under "Replication across Regions") states: "A single secret can be replicated to multiple AWS Regions for disaster recovery and low-latency reads. Replica secrets are encrypted in the target Region's KMS keys; failover is…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L47 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager encrypts secrets at rest using AES-256 with a customer-managed or AWS-managed KMS key per secret." → ❌ contradicted (framing: shifted — claim says "a customer-managed or AWS-managed KMS key per secret"; source says a KMS key can be shared across secrets; only the data key (DEK) is uni…; evidence: (escalated from pass1) AWS docs confirm AES-256 envelope encryption via KMS, but the KMS key is not "per secret" — it is configurable per secret but can be shared: "You can use the same KMS key or different KMS keys for each secret in your…; source: https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)
L48 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager uses TLS for all API calls (encryption in transit)." → ✅ verified (evidence: The file's feature table explicitly states: "Encryption in transit | TLS for all API calls", which directly matches the claim that AWS Secrets Manager uses TLS for all API calls (encryption in transit).; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L50 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager supports multiple versions per secret with stage labels: AWSCURRENT, AWSPENDING, and AWSPREVIOUS." → ✅ verified (evidence: The file at L50 (features table) states: "Multiple versions per secret with stage labels (AWSCURRENT, AWSPENDING, AWSPREVIOUS)" — exactly matching the claim. The rotation section further confirms these three labels are used in the four-ste…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L51-55 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager has built-in automatic rotation support for RDS, Redshift, and DocumentDB, and supports custom rotation via Lambda." → ✅ verified (evidence: The file at content/what-is/what-is-aws-secrets-manager.md explicitly states in the features table: "Automatic rotation | Built-in support for RDS, Redshift, DocumentDB; custom rotation via Lambda" and in the prose: "Secrets Manager na…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L57 in content/what-is/what-is-aws-secrets-manager.md "A secret in AWS Secrets Manager is a versioned key/value document (typically JSON), encrypted with a KMS key, addressable by name or ARN." → ✅ verified (evidence: The file content/what-is/what-is-aws-secrets-manager.md contains the exact sentence at the end of the "core features" section: "A secret in Secrets Manager is a versioned key/value document (typically JSON), encrypted with a KMS key, add…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L61 in content/what-is/what-is-aws-secrets-manager.md "Rotation in AWS Secrets Manager follows a four-step state machine driven by an AWS Lambda function: (1) createSecret — Lambda generates a new credential and st…" (also L63-66) → ✅ verified (evidence: The file at content/what-is/what-is-aws-secrets-manager.md states: "Rotation in Secrets Manager follows a four-step state machine driven by an AWS Lambda function: 1. createSecret. The Lambda generates a new credential... and stores it a…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L61 in content/what-is/what-is-aws-secrets-manager.md "Rotation in AWS Secrets Manager follows a four-step state machine driven by an AWS Lambda function." → ✅ verified (evidence: The file at content/what-is/what-is-aws-secrets-manager.md line 61 states: "Rotation in Secrets Manager follows a four-step state machine driven by an AWS Lambda function" and enumerates the four steps: createSecret, setSecret, testSecret,…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L64 in content/what-is/what-is-aws-secrets-manager.md "1. setSecret. The Lambda updates the downstream service (e.g. runs ALTER USER against RDS) to accept the new credential." → ➖ not-a-claim (evidence: The line at L64 is part of the PR author's own documentation describing AWS Secrets Manager's four-step rotation state machine. It is a faithful description of the setSecret rotation step in the author's own design of the page, not a thi…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L65 in content/what-is/what-is-aws-secrets-manager.md "1. testSecret. The Lambda verifies the new credential works by connecting with it." → ➖ not-a-claim (evidence: The text at L65 is a faithful description of the AWS Secrets Manager rotation step "testSecret" in the file's own four-step state machine. The "1." prefix is a markdown ordered-list marker (all steps use 1. in markdown), not a falsifiabl…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L66 in content/what-is/what-is-aws-secrets-manager.md "1. finishSecret. The Lambda swaps the version labels: the new version becomes AWSCURRENT, the old one becomes AWSPREVIOUS." → ✅ verified (evidence: The file at L66 contains exactly: "finishSecret. The Lambda swaps the version labels: the new version becomes AWSCURRENT, the old one becomes AWSPREVIOUS." This accurately describes the AWS Secrets Manager rotation contract, where…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L68 in content/what-is/what-is-aws-secrets-manager.md "For RDS, Redshift, and DocumentDB, AWS supplies the rotation Lambda for AWS Secrets Manager." → ✅ verified (evidence: The file at L68 states exactly: "For RDS, Redshift, and DocumentDB, AWS supplies the rotation Lambda." This is also corroborated earlier in the same document: "Secrets Manager natively supports automatic rotation for Amazon RDS (Aurora MyS…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L68 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager rotation can be scheduled (every N days) or triggered on demand." → ✅ verified (evidence: The file at the rotation section explicitly states: "Rotation can be scheduled (every N days) or triggered on demand." This is a factually accurate description of AWS Secrets Manager's rotation capabilities, consistent with AWS documentati…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L70 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager supports multi-user rotation (alternating between two database users) for zero-downtime rotations." → ✅ verified (evidence: The file at content/what-is/what-is-aws-secrets-manager.md (around L70) states: "Multi-user rotation (alternating between two database users) is supported and recommended for zero-downtime rotations: while one user's password is rotated, t…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L79-84 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager pricing is per secret/month plus API calls; Systems Manager Parameter Store Standard parameters are free and Advanced parameters are charge…" → ✅ verified (evidence: AWS Secrets Manager charges per secret per month plus API calls ($0.40/secret/month + $0.05/10K API calls). For Parameter Store: "Standard parameters are available at no additional charge. When you create advanced parameters, you are charg…; source: https://aws.amazon.com/systems-manager/pricing/ and https://aws.amazon.com/secrets-manager/pricing/)
L91 in content/what-is/what-is-aws-secrets-manager.md "| Capability | AWS Secrets Manager | HashiCorp Vault | Azure Key Vault | [Google Clou…" → ✅ verified (evidence: The file content/what-is/what-is-hashicorp-vault.md exists in the repository with page_title: "What is HashiCorp Vault?", confirming the internal link /what-is/what-is-hashicorp-vault/ referenced in the comparison table is valid.; source: repo:content/what-is/what-is-hashicorp-vault.md)
L93-97 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager is AWS-native in cloud scope; HashiCorp Vault supports multi-cloud, hybrid, and on-prem; Azure Key Vault is Azure-native; Google Cloud Secr…" → ✅ verified (evidence: HashiCorp's own documentation confirms Vault supports multi-cloud, hybrid, and on-premises: "Centrally manage static and dynamic secrets across applications hosted in multi-cloud, hybrid, and on-premises environments." AWS Secrets Manager,…; source: https://www.hashicorp.com/en/products/vault/vault-enterprise)
L95 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager has built-in rotation for RDS, Redshift, and DocumentDB, and uses Lambda for other secret types." → ✅ verified (evidence: The file at L95 (features table) states "Built-in support for RDS, Redshift, DocumentDB; custom rotation via Lambda", and the rotation section elaborates: "For RDS, Redshift, and DocumentDB, AWS supplies the rotation Lambda. For other secr…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L97 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager is in scope for SOC 1, SOC 2, SOC 3, PCI DSS, HIPAA, FedRAMP High, and IRAP compliance programs." → ✅ verified (framing: strengthened — claim narrows the broader SOC listing to 'SOC 1, SOC 2, SOC 3' and specifies 'FedRAMP High'; both are confirmed as subsets of the broader source…; evidence: (escalated from pass1) AWS's official features page confirms Secrets Manager supports "FedRAMP, U.S. Health Insurance Portability and Accountability Act (HIPAA), Information Security Registered Assessors Program (IRAP)... Payment Card Indu…; source: https://aws.amazon.com/secrets-manager/features/)
L97 in content/what-is/what-is-aws-secrets-manager.md "Google Cloud Secret Manager supports FIPS 140-2 via Cloud HSM with CMEK." → ✅ verified (framing: strengthened — claim narrows the general Cloud HSM+CMEK FIPS 140-2 Level 3 capability to Secret Manager specifically; the official Secret Manager CMEK doc conf…; evidence: (escalated from pass1) Google Cloud Secret Manager supports CMEK via Cloud KMS (docs.cloud.google.com/secret-manager/docs/cmek), and Cloud HSM keys used in CMEK integrations are validated to FIPS 140-2 Level 3: "With Cloud HSM, you can gen…; source: https://docs.cloud.google.com/secret-manager/docs/cmek; https://docs.cloud.google.com/kms/docs/protection-levels)
L100 in content/what-is/what-is-aws-secrets-manager.md "For workloads that run mostly inside AWS, Secrets Manager is almost always the right default. For multi-cloud or hybrid deployments, organizations frequently p…" → ➖ not-a-claim (evidence: The text at L100 is the PR author's own editorial description of Pulumi ESC's design and a recommended usage pattern — it is a faithful description of the PR author's own product/pipeline, not a third-party-attributed assertion. The `/prod…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L106-107 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager pricing in most AWS Regions is around $0.40 per secret per month, plus a small per-API-call charge for retrievals and other operations." (also L156) → ✅ verified (framing: strengthened — claim says "around $0.40" and "most AWS Regions"; source confirms exactly $0.40 and the rate is uniform across all commercial AWS regions, so th…; evidence: The official AWS Secrets Manager pricing page uses $0.40/secret/month in its own examples ("the price per secret is calculated as $0.40 * 1 hour / (30 days * 24 hours)"), and multiple current sources confirm "$0.40 per secret per month and…; source: https://aws.amazon.com/secrets-manager/pricing/)
L109 in content/what-is/what-is-aws-secrets-manager.md "Replica secrets in AWS Secrets Manager are billed at the same per-secret rate in each Region they are replicated to." → ✅ verified (framing: strengthened — source says "billed as a separate secret" (per-secret rate applies); claim adds the "same rate in each Region" nuance, which is confirmed by uni…; evidence: The AWS Security blog states "Each replica secret is billed as a separate secret," and AWS Secrets Manager pricing is uniform across all regions at $0.40/secret/month with no regional variation, confirming replicas are billed at the same p…; source: https://aws.amazon.com/blogs/security/how-to-replicate-secrets-aws-secrets-manager-multiple-regions/)
L119 in content/what-is/what-is-aws-secrets-manager.md "Updates to the primary AWS Secrets Manager secret propagate to replicas within seconds under normal conditions." → 🤷 unverifiable (framing: narrowed — AWS sources say propagation happens "within seconds or minutes" with no SLA; the claim narrows this to "within seconds under normal conditions," whi…; evidence: (escalated from pass1) AWS official docs confirm updates propagate to replicas automatically, but provide no specific latency guarantee. An AWS re:Post answer (community/AI-generated) states propagation "happens relatively quickly - often…; source: https://docs.aws.amazon.com/secretsmanager/latest/userguide/replicate-secrets.html; https://repost.aws/questions/QUJEj9AP8YTUyd9ppHF8o2WQ/aws-secrets-manager-replication-lag (WebSearch dispatched but verification did not converge within the turn budget))
L128 in content/what-is/what-is-aws-secrets-manager.md "The maximum number of versions per secret in AWS Secrets Manager is 100." (also L134-135) → ✅ verified (framing: strengthened — the source describes a rolling cleanup threshold ("keeps 100 of the most recent versions"), which the claim frames as a hard maximum of 100; the…; evidence: The official AWS Secrets Manager API reference states: "Secrets Manager keeps 100 of the most recent versions, but it keeps all secret versions created in the last 24 hours." The quotas page confirms this is the enforced limit per secret.; source: https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_PutSecretValue.html)
L130 in content/what-is/what-is-aws-secrets-manager.md "The maximum secret value size in AWS Secrets Manager is 64 KB." → ✅ verified (evidence: AWS official docs state "You can store any text or binary in a Secrets Manager secret up to the maximum size of 65,536 Bytes" (= 64 KB). AWS's own What's New announcement confirms "larger secret size of up to 64 Kb."; source: https://docs.aws.amazon.com/secretsmanager/latest/userguide/reference_secret_json_structure.html; https://aws.amazon.com/about-aws/whats-new/2020/03/aws-secrets-manager-now-supports-larger-size-for-secrets-and-higher-request-rate-for-getsecretvalue-api/)
L131-132 in content/what-is/what-is-aws-secrets-manager.md "The default number of secrets per Region per account in AWS Secrets Manager is 500,000 (soft limit; can be raised)." → ❌ contradicted (framing: shifted — the 500,000 number is correct, but the claim frames it as a soft/adjustable limit when AWS documentation indicates it is a fixed (non-adjustable) quo…; evidence: The AWS announcement confirms "500,000 secrets per account per region," but a third-party quota tracker lists all 18 Secrets Manager quotas as non-adjustable (Fixed: 18, Adjustable: 0), contradicting the claim that 500,000 is a soft limit…; source: https://aws.amazon.com/about-aws/whats-new/2021/11/aws-secrets-manager-increases-secrets-limit-per-account/ ; https://awsfundamentals.com/limits/secretsmanager)
L134-135 in content/what-is/what-is-aws-secrets-manager.md "The rotation function timeout in AWS Secrets Manager inherits the Lambda timeout, with a maximum of 15 minutes." → ✅ verified (framing: strengthened — claim narrows the general Lambda 15-minute hard limit to the specific context of Secrets Manager rotation functions; source's broader form prove…; evidence: AWS Secrets Manager rotation uses a Lambda function, and AWS Lambda has a hard execution limit of 15 minutes — "Lambda functions have a hard execution limit of 15 minutes. AWS terminates any function exceeding this time." The rotation func…; source: https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_lambda.html; https://devin-rosario.medium.com/aws-lambda-limitations-complete-2025-resource-guide-6a52be865710)
L137 in content/what-is/what-is-aws-secrets-manager.md "The AWS Secrets Manager client-side caching libraries are available for Java, Python, Node.js, .NET, and Go." (also L180) → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
L141 in content/what-is/what-is-aws-secrets-manager.md "Pulumi ESC treats AWS Secrets Manager as one of many secret sources. The AWS Secrets provider…" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
L145 in content/what-is/what-is-aws-secrets-manager.md "* Dynamic AWS credentials via OIDC. ESC mints short-lived AWS credentials at the moment a consumer opens the environment, removing the need for long-lived…" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
L150 in content/what-is/what-is-aws-secrets-manager.md "The aws.secretsmanager Pulumi resource lets you define and manage AWS Secrets Manager resources as code in TypeScript, Python, Go, C#, Java, or YAML." (also L196) → ✅ verified (evidence: The pulumi/pulumi-aws repo contains sdk/nodejs/secretsmanager/secret.ts (TypeScript), plus sdk directories for python, go, dotnet (C#), java, and YAML — confirming the aws.secretsmanager Pulumi resource supports all six languages lis…; source: gh api repos/pulumi/pulumi-aws/contents/sdk/nodejs/secretsmanager — lists secret.ts; gh api repos/pulumi/pulumi-aws/contents/sdk — lists nodejs, python, go, dotnet, java directories)
L156 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager pricing in most Regions is roughly $0.40 per secret per month plus a small per-API-call fee, with a 30-day free trial for new secrets." → ✅ verified (framing: strengthened — claim says "most Regions" but pricing is uniform across all commercial AWS regions at $0.40; the "most Regions" qualifier is conservative and no…; evidence: The official AWS Secrets Manager pricing page confirms: "You can try AWS Secrets Manager at no additional charge with a 30-day free trial" and uses $0.40/secret/month in its pricing examples, with API calls at $0.05 per 10,000 calls.; source: https://aws.amazon.com/secrets-manager/pricing/)
L160 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager natively supports automatic rotation for Amazon RDS engines, Amazon Redshift, and Amazon DocumentDB using AWS-supplied rotation Lambdas." → ✅ verified (evidence: The file itself states: "Secrets Manager natively supports automatic rotation for Amazon RDS (Aurora MySQL, Aurora PostgreSQL, MySQL, PostgreSQL, Oracle, SQL Server, MariaDB), Amazon Redshift, and Amazon DocumentDB. For other secret types,…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L172 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager is a HIPAA-eligible service under the AWS Business Associate Addendum." → ✅ verified (evidence: (escalated from pass1) The official AWS Secrets Manager compliance docs confirm: "HIPAA – AWS has expanded its ... Manager as a HIPAA-eligible service. If you have an executed Business Associate Agreement (BAA) with AWS, you can use Secret…; source: https://docs.aws.amazon.com/secretsmanager/latest/userguide/secretsmanager-compliance.html)
L172 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager is in scope for SOC 1, SOC 2, SOC 3, PCI DSS, ISO 27001, FedRAMP High, and several other AWS compliance programs." → ❌ contradicted (framing: shifted — claim lists "ISO 27001" which does not appear in the source, and omits "HIPAA" and "IRAP" which do appear in the source; evidence: The file's compliance row (in the comparison table) reads "SOC 1/2/3, PCI DSS, HIPAA, FedRAMP High, IRAP, others" — ISO 27001 is not listed, while HIPAA and IRAP are present but omitted from the claim.; source: repo:content/what-is/what-is-aws-secrets-manager.md)
L176 in content/what-is/what-is-aws-secrets-manager.md "Attach a resource-based policy to the secret that grants access to the target account's IAM principals, and grant kms:Decrypt on the underlying KMS key. The…" → ✅ verified (evidence: The SecretPolicy resource exists in the Pulumi AWS provider, confirmed by sdk/go/aws/secretsmanager/secretPolicy.go in pulumi/pulumi-aws. The registry URL /registry/packages/aws/api-docs/secretsmanager/secretpolicy/ follows the sta…; source: gh api repos/pulumi/pulumi-aws/contents/sdk/go/aws/secretsmanager — lists secretPolicy.go at path sdk/go/aws/secretsmanager/secretPolicy.go)
L180 in content/what-is/what-is-aws-secrets-manager.md "AWS Secrets Manager client-side caching libraries are available for Java, Python, Node.js, .NET, and Go." → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
L188 in content/what-is/what-is-aws-secrets-manager.md "Yes, though it's a one-time export-and-import. List secrets via the AWS API, fetch each value, write into Vault's KV v2 engine, and update your applications to…" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
L192 in content/what-is/what-is-aws-secrets-manager.md "The AWS Secrets and Configuration Provider for the Kubernetes Secrets Store CSI Driver can be used to integrate AWS Secrets Manager with EKS, mounting secrets…" → ✅ verified (evidence: (escalated from pass1) AWS official docs confirm: "To show secrets from Secrets Manager and parameters from Parameter Store as files mounted in Amazon EKS Pods, you can use the AWS Secrets and Configuration Provider (ASCP) for the Kubernet…; source: https://docs.aws.amazon.com/eks/latest/userguide/manage-secrets.html)
L196 in content/what-is/what-is-aws-secrets-manager.md "The Pulumi AWS provider lets you declare every Secrets Manager resource as code in TypeScript, Python, Go, C#, Java, or YAML." → ✅ verified (evidence: The pulumi/pulumi-aws repo contains SDK directories for nodejs (TypeScript/JavaScript), python, go, dotnet (C#), and java. YAML is a first-class Pulumi language supported by the engine. All six languages listed in the claim (TypeScript, Py…; source: gh api repos/pulumi/pulumi-aws/contents/sdk — directories: dotnet, go, java, nodejs, python confirmed present)
L200-205 in content/what-is/what-is-aws-secrets-manager.md "* What is Google Cloud Secret Manager?" → ✅ verified (evidence: The file content/what-is/what-is-google-cloud-secret-manager.md exists in the repo with the matching title "What is Google Cloud Secret Manager?", confirming the linked URL /what-is/what-is-google-cloud-secret-manager/ is valid.; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)

🚨 Outstanding in this PR

These must be resolved or refuted before merging.

[L56] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — Comparison-table row | Typical p99 read latency | Single-digit milliseconds | Single-digit milliseconds |. AWS publishes DynamoDB's "single-digit millisecond" number as a general/average performance claim, not a p99 commitment; Google explicitly targets p99 single-digit-ms for Bigtable. Putting both under a "p99" header silently elevates DynamoDB's framing.
```
| Typical read latency | Single-digit milliseconds | Single-digit milliseconds (p99) |
```
Or label DynamoDB's column with the qualifier AWS actually uses ("average") so the contrast is faithful.
[L103] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Both services target single-digit-millisecond p99 latency for well-designed workloads…" (repeated at L214 inside the FAQ). Same framing problem as the table row: AWS doesn't quote DynamoDB at p99.
```
Both services target **single-digit-millisecond read latency** for well-designed workloads, but the operational profile differs. (AWS publishes DynamoDB's number as average performance; Google Cloud quotes Bigtable's at p99.)
```
Apply the same softening to the L214 FAQ sentence ("Both target single-digit-millisecond p99 latency…").
[L106] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Throughput scales linearly with nodes (roughly 10,000 ops/second/node on SSD)…". Google rebased Bigtable's SSD baseline to 17,000 point reads/sec/node in June 2025; the 10k figure is the older baseline.
```
* **Bigtable** delivers consistent low latency for reads and writes proportional to the number of nodes in a cluster. Throughput scales linearly with nodes (Google publishes a current baseline of ~17,000 point reads/second/node on SSD), and large sequential scans are particularly efficient because data is stored in row-key order.
```
See https://cloud.google.com/blog/products/databases/exploring-bigtable-read-throughput-performance-gains/ for the updated figure.
[L152] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — Comparison-table row | API compatibility | AWS SDKs, PartiQL | HBase 1.x API, plus native gRPC clients |. Bigtable ships HBase client libraries at both bigtable-hbase-1.x and bigtable-hbase-2.x, and supports cross-version HBase replication; pinning to 1.x reads as out of date.
```
| API compatibility | AWS SDKs, PartiQL | HBase API (1.x / 2.x), plus native gRPC clients |
```
[L154] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "…Dataflow is the standard way to land streaming data into Bigtable tables." Pub/Sub Bigtable subscriptions (Preview) are now a documented direct alternative. "The standard way" is fine if framed as common Production practice but reads stronger than the official docs do.
```
Bigtable plugs into Google's analytics stack — BigQuery can query Bigtable directly, and Dataflow is a common path for landing streaming data into Bigtable tables (Pub/Sub Bigtable subscriptions are also available in Preview).
```
[L238] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — "Bigtable supports GoogleSQL (in preview) and is also queryable from BigQuery via federation." GoogleSQL for Bigtable went GA in August 2024; the "(in preview)" parenthetical is stale. The L53 table row carries the same "(preview)" qualifier.
```
DynamoDB supports a subset of SQL through PartiQL. Bigtable supports GoogleSQL and is also queryable from BigQuery via federation. Neither replaces a relational database — both are NoSQL stores where the query model is shaped around the key design, not arbitrary SQL.
```
Also drop "(preview)" from the L53 comparison-table cell (HBase API, Bigtable client libraries, GoogleSQL).
[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." This sentence (and the L139 table row Backups and import/export to Cloud Storage) conflates two separate features: Bigtable native backups live on a cluster and explicitly cannot be exported to Cloud Storage; data import/export to Cloud Storage is a distinct Dataflow-based workflow.
```
Yes. DynamoDB supports point-in-time recovery (PITR) for 35 days and on-demand backups. Bigtable supports native backups stored on a Bigtable cluster (these cannot be exported to Cloud Storage). Bigtable data can also be exported to and imported from Cloud Storage via a separate Dataflow-based workflow.
```
Update the L139 table cell to match: Cluster-stored backups; data import/export 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." The HBase API layer is broadly compatible but Google's migration docs describe a multi-step path (client library swap, schema translation, data export/import, behavior-difference review). "Minor configuration changes" understates the data side of the migration.

No. The HBase API is specific to Bigtable. DynamoDB uses its own API (and PartiQL). Application code that uses the HBase API can often be repointed at Bigtable by swapping the client library and a handful of configuration values, but data migration is a separate workflow — review the [HBase to Bigtable migration guide](https://docs.cloud.google.com/bigtable/docs/migrate-hbase-data-to-bigtable) before estimating effort.

[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)." The mapping is reversed. AWS hard-caps role chaining at 1 hour regardless of MaxSessionDuration, while AssumeRoleWithWebIdentity (the OIDC path ESC uses) can request up to the role's MaxSessionDuration — which itself can be raised to 12 hours. This is the most reader-impacting fact in the PR and should not ship as written.
```
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 `AssumeRoleWithWebIdentity`, which is the OIDC path; role chaining is hard-capped at 1 hour).
```
See https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html (role-chaining cap) and the AssumeRoleWithWebIdentity reference for the 12-hour ceiling.
[L47] content/what-is/what-is-aws-secrets-manager.md — Feature-table row | **Encryption at rest** | AES-256 with a customer-managed or AWS-managed KMS key per secret |. "Per secret" reads as if each secret requires its own dedicated KMS key; AWS docs make clear a single KMS key can encrypt many secrets — the per-secret choice is which KMS key, not a separate key per secret.
```
| **Encryption at rest** | AES-256 via KMS envelope encryption; choose a customer-managed or AWS-managed KMS key per secret (keys can be shared across secrets) |
```
[L131-132] content/what-is/what-is-aws-secrets-manager.md — Limits table row | Default secrets per Region per account | 500,000 (soft limit; can be raised) |. The 500,000 figure is correct, but third-party quota trackers list the entire Secrets Manager quota set as non-adjustable. Please verify against the current AWS Service Quotas console (Secrets Manager → "Secrets per Region") whether it shows the "Adjustable: Yes" badge before keeping the (soft limit; can be raised) qualifier — drop the qualifier if not.
```
| Secrets per Region per account | 500,000 (see AWS Service Quotas for the current adjustable/fixed status) |
```
[L172] content/what-is/what-is-aws-secrets-manager.md — "AWS Secrets Manager is a HIPAA-eligible service… It's also in scope for SOC 1, SOC 2, SOC 3, PCI DSS, ISO 27001, FedRAMP High, and several other AWS compliance programs." The same file's L97 comparison table lists SOC 1/2/3, PCI DSS, HIPAA, FedRAMP High, IRAP, others — HIPAA and IRAP appear in the table but not in the FAQ list; ISO 27001 appears in the FAQ but not in the table. Align the two lists.
```
Yes. AWS Secrets Manager is a HIPAA-eligible service under the AWS Business Associate Addendum. It's also in scope for SOC 1, SOC 2, SOC 3, PCI DSS, ISO 27001, FedRAMP High, IRAP, and other AWS compliance programs.
```
Then add ISO 27001 to the L97 table's compliance cell, or strike the differing items from one side and reference the AWS compliance services in scope page for the authoritative list.

⚠️ 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 providers expose the full service surface, including IAM, replication, backups, and autoscaling." "Full service surface" is hard to substantiate categorically; the listed sub-features are individually correct. Consider softening to "broad coverage across…" so the line doesn't promise gap-free parity with the underlying SDK.
[L28] content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md — "…sessions expire after the duration configured in the ESC environment (default 1 hour)…" (also L136, L153). Pulumi ESC examples all set duration: 1h explicitly; what the aws-login provider does when duration is omitted isn't called out in public docs. Please confirm 1h is the actual provider default (not just the example value) — if it's only the example default, drop the parenthetical and let the explicit duration: 1h in the YAML carry the meaning.
[L38] content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md — "…see Configuring OIDC between Pulumi and AWS…" Internal link target wasn't verified within the turn budget. Spot-check that the docs path still resolves before merging — the same path appears on L54 and L173-174 (the "Learn more" section).
[L161] content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md — "Inside esc run, the value will be reported with Type=env…" This is straightforwardly reproducible by running esc run -- aws configure list against any working ESC environment, but the doc doesn't include a sample of that output. Consider pasting a 3-line capture so the reader can pattern-match against what they see.
[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." This is an implementation-detail claim about the aws-login provider's endpoint selection. Worth a code/source pointer (or softening to "typically uses the regional endpoint…") so the reader doesn't take it as a strict contract.
[L173-174] content/what-is/run-aws-sts-get-caller-identity-with-dynamic-credentials.md — "Learn more" links (/product/esc/, /docs/esc/environments/configuring-oidc/aws/). Internal-link verification did not converge within the turn budget; the same path appears at L38 and L54. Confirm both targets resolve in the rendered site preview before merging.
[L119] content/what-is/what-is-aws-secrets-manager.md — "Updates to the primary propagate to replicas within seconds under normal conditions." AWS doesn't publish a propagation SLA; community guidance says "seconds to minutes." Suggest softening to "within seconds to a few minutes — AWS doesn't publish an SLA" so DR-runbook readers don't assume sub-second handoff.
[L137] content/what-is/what-is-aws-secrets-manager.md — "the AWS Secrets Manager Java, Python, Node.js, .NET, and Go caching libraries…" (same claim at L180). The five languages are the documented set; verification didn't converge in the turn budget. Worth linking the AWS docs page that enumerates the available client-side caching libraries so the reader can confirm.
[L141] content/what-is/what-is-aws-secrets-manager.md — Pulumi ESC + AWS Secrets provider internal links (/product/esc/, /docs/pulumi-cloud/esc/providers/aws-secrets/, /docs/pulumi-cloud/esc/providers/aws-login/ at L145). Confirm the three target paths render in the site preview before merging — link verification did not converge in the turn budget.
[L145] content/what-is/what-is-aws-secrets-manager.md — "ESC mints short-lived AWS credentials at the moment a consumer opens the environment…" This matches ESC's documented OIDC + aws-login behavior elsewhere on the site; verification didn't converge in the turn budget. No copy change suggested — just flagged so reviewers can spot-check the framing against the linked aws-login provider page.
[L180] content/what-is/what-is-aws-secrets-manager.md — Duplicate of L137 above — same five-language claim, same suggestion (link the AWS client-side caching docs page).
[L188] content/what-is/what-is-aws-secrets-manager.md — "…it's a one-time export-and-import. List secrets via the AWS API, fetch each value, write into Vault's KV v2 engine…" This is a reasonable description of the canonical migration pattern; verification didn't converge in the turn budget because no single source documents the four-step recipe end-to-end. No copy change required — flagged so reviewers can confirm the recipe matches what your customer-engineering team recommends.

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-aws-secrets-manager.md (10 issues: 4 first person, 3 weasel word, 3 wordiness)

line 29: [style] weasel word — 'usually' is a weasel word!
line 100: [style] weasel word — 'mostly' is a weasel word!
line 130: [style] wordiness — 'Maximum' is too wordy.
line 134: [style] wordiness — 'Maximum' is too wordy.
line 166: [style] first person — Avoid first-person pronouns such as ' I '.
line 168: [style] wordiness — 'obtain' is too wordy.
line 172: [style] weasel word — 'several' is a weasel word!
line 174: [style] first person — Avoid first-person pronouns such as ' I '.
line 178: [style] first person — Avoid first-person pronouns such as ' I '.
line 186: [style] first person — Avoid first-person pronouns such as ' I '.

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

📋 Triaged verifier findings

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

[L149] content/what-is/amazon-dynamodb-vs-google-cloud-bigtable.md — Comparison-table cell | Caching | DAX in-memory cache | Built-in block cache; Memorystore for app-side cache |. Spurious: The cell already distinguishes "Built-in block cache" (a native Bigtable feature) from "Memorystore for app-side cache" (an external caching pattern in front of Bigtable); the verifier collapsed the two phrases into "Bigtable supports Memorystore as a built-in," which the source text does not say.

💡 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:54:20Z — 12 outstanding contradictions across 3 expanded what-is pages (incl. one inverted role-chaining vs OIDC duration mapping); 1 verifier finding triaged spurious. (b6686a2)

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 related /what-is/ pages and product docs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

alexleventer had a problem deploying to testing May 20, 2026 16:48 — 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/aws-secrets-manager-rewrite branch from b6686a2 to df1cba9 Compare May 20, 2026 18:02

alexleventer had a problem deploying to testing May 20, 2026 18:02 — 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 AWS Secrets Manager explainer#19271

content(what-is): expand the AWS Secrets Manager explainer#19271
alexleventer wants to merge 1 commit into
masterfrom
aleventer/aws-secrets-manager-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:54:20Z

🔍 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