Rate the evidence like an assessor
The three-way honesty rating — full, partial, narrative — and a drill: three real recipes, commands visible and verdicts hidden, rated against the same bar this site's own corpus is held to.
Every recipe on this site carries a three-way honesty rating, and the bar is strict on purpose. Fullmeans the command’s output alonedecides pass or fail — not “is relevant to”, decides — and if you cannot write the check down as an assertion over a named field, it is not full. Partial means the output is probative but a human must still read something else. Narrative means the evidence is a document a human writes; any commands merely frame it. No recipe in the corpus rates full today: the twelve that did were re-rated on 26 August 2026 when an independent reading showed each one decided a neighbour of the control it named, or one Region of one account. The bar did not move; the corpus did, and the full column is the bar rather than a population.
Two more clauses of the bar, because the drill will test both. Related subject matter is not a join — a command about the same topic as a control is not evidence for it unless the output is part of what the control names. And FedRAMP’s own instruction to assessors is the mirror of this rubric: automation is not proof by itself; the assessor must understand it well enough to test it.
Now rate three real recipes. The commands and the claim are visible; the corpus’s verdict is hidden until you commit.
Recipe 1 of 3
Account-wide credential report proving MFA is active per principal and that passwords/access keys are rotated within policy
$ aws iam generate-credential-report$ aws iam get-credential-report --query GeneratedTime --output text$ aws iam get-credential-report --query Content --output text | base64 --decodeExpected output: CSV, one row per IAM principal with columns including password_enabled, mfa_active, password_last_changed, access_key_1_active, access_key_1_last_rotated, access_key_2_last_rotated
Recipe 2 of 3
Restore jobs that actually ran — the schedule they ran on, whether each one completed, how long it took, and what it produced — plus the point-in-time recovery window that makes transaction-level recovery possible
$ aws backup list-restore-testing-plans --query 'RestoreTestingPlans[].{Plan:RestoreTestingPlanName,Schedule:ScheduleExpression,LastRun:LastExecutionTime,StartWindowHours:StartWindowHours}'$ aws backup list-restore-jobs --by-created-after 2026-04-01T00:00:00Z --query 'RestoreJobs[].{Id:RestoreJobId,Type:ResourceType,Status:Status,Message:StatusMessage,Created:CreationDate,Completed:CompletionDate,Validation:ValidationStatus,Restored:CreatedResourceArn}'$ aws backup list-protected-resources --query 'Results[].{Arn:ResourceArn,Type:ResourceType,LastBackup:LastBackupTime,LastRecoveryPoint:LastRecoveryPointArn}'$ aws configservice get-compliance-details-by-config-rule --config-rule-name aurora-resources-protected-by-backup-plan --compliance-types NON_COMPLIANT$ aws configservice get-compliance-details-by-config-rule --config-rule-name rds-in-backup-plan --compliance-types NON_COMPLIANT$ aws rds describe-db-instances --query 'DBInstances[].{Db:DBInstanceIdentifier,RetentionDays:BackupRetentionPeriod,LatestRestorable:LatestRestorableTime}'$ aws configservice get-compliance-details-by-config-rule --config-rule-name dynamodb-pitr-enabled --compliance-types NON_COMPLIANTExpected output: A RestoreTestingPlans list whose ScheduleExpression is the cron your recovery policy claims and whose LastExecutionTime proves the schedule is actually firing; a RestoreJobs list in which each job carries a Status of COMPLETED (the other states are PENDING, RUNNING, ABORTED and FAILED, with StatusMessage explaining a failure), a CreationDate and CompletionDate whose difference is the measured restore time, a CreatedResourceArn naming what was rebuilt, and a ValidationStatus of SUCCESSFUL, FAILED, TIMED_OUT or VALIDATING only where you wired validation; a Results list of protected resources each stamped with LastBackupTime; two empty NON_COMPLIANT sets; and a DB instance list whose LatestRestorableTime — the most recent point a PITR restore can target — sits within minutes of now, bounded by BackupRetentionPeriod days of history. Managed rule identifiers: AURORA_RESOURCES_PROTECTED_BY_BACKUP_PLAN, RDS_IN_BACKUP_PLAN, DYNAMODB_PITR_ENABLED
Recipe 3 of 3
Documented just-in-time / break-glass privilege-elevation process backed by IAM Identity Center permission sets and account assignments, showing privileged access is role/attribute-based, time-bound, and approval-gated rather than standing
$ aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text$ aws sso-admin list-permission-sets --instance-arn <INSTANCE_ARN>$ aws sso-admin describe-permission-set --instance-arn <INSTANCE_ARN> --permission-set-arn <PERMISSION_SET_ARN> --query 'PermissionSet.{Name:Name,SessionDuration:SessionDuration}'$ aws sso-admin list-account-assignments --instance-arn <INSTANCE_ARN> --account-id <ACCOUNT_ID> --permission-set-arn <PERMISSION_SET_ARN>Expected output: Permission set names with bounded SessionDuration (e.g. PT1H) and current account assignments; combined with the written approval-workflow runbook and ticket/approval records for each elevation