The policy shown in the image is:

path “secret/data/webapp1” { capabilities = [“create”, “read”, “update”, “delete”, “list”] }

path “secret/data/super-secret” { capabilities = [“deny”] }

This policy grants or denies access to the key/value v2 secrets engine mounted at secret/ according

to the following rules:

The path “secret/data/webapp1” has the capabilities of “create”, “read”, “update”, “delete”, and

“list”. This means that the policy allows performing any of these operations on the secrets stored

under this path. The data/ prefix is used to access the actual secret data in the key/value v2 secrets

engine5. Therefore, the policy permits the operation of vault kv get secret/webapp1, which reads the

secret data at secret/data/webapp16.

The path “secret/data/super-secret” has the capability of “deny”. This means that the policy denies

performing any operation on the secrets stored under this path. The policy overrides any other policy

that might grant access to this path. Therefore, the policy does not permit the operations of vault kv

delete secret/super-secret and vault kv list secret/super-secret, which delete and list the secret data

at secret/data/super-secret respectively6.

The policy does not explicitly define any rules for the path “secret/metadata”. The metadata/ prefix is

used to access the metadata of the secrets in the key/value v2 secrets engine, such as the number of

versions, the deletion status, the creation time, etc5. By default, if the policy grants any of the

capabilities of “create”, “read”, “update”, or “delete” on the data/ path, it also grants the same

capabilities on the corresponding metadata/ path7. Therefore, the policy permits the operation of

vault kv metadata get secret/webapp1, which reads the metadata of the secret at

secret/metadata/webapp18.

Reference: 5(https://developer.hashicorp.com/vault/docs/secrets/kv/kv-v2),

[6]6, 7(https://developer.hashicorp.com/vault/docs/secrets/kv/kv-v2), [8]8