Reaches the tenant's effective key-material backend and reports whether it answers, so a misconfigured backend can be told apart from an unreachable one BEFORE a crypto operation fails. Required scope: admin.tenant.key-backend.byok.test.

A failed test is an HTTP 200. The question this operation asks is whether the backend works; "it does not" is an answer to that question, so it arrives as a 200 carrying a FAILED verdict. A non-2xx means something different and incompatible: the test could not be run at all. A client that renders both as "error" loses the distinction that makes this operation useful, because the two call for opposite operator actions.

The verdict's reason comes from a closed vocabulary (SelfTestReason) that can carry no credential, ARN, resource path, vault URL, region or account id, and no vendor exception text. A client MUST tolerate a reason it does not recognise and render it as an unknown verdict — never as a pass.

It changes nothing: no state advances, no key material is written, no KEK is provisioned on either the delegated BYOK path or the in-process managed-tier path, and the backend remains changeable afterwards. It is therefore admissible in EVERY backend state, including CHANGING — which is the state in which an operator most needs it — and it never answers 409.

Not every status below is reachable for every tenant. A tenant on an ANKA-managed tier is tested IN THIS SERVICE's own process rather than delegated, so the 502 and 504 — which describe a delegation — cannot occur for it. They apply to a tenant that brought its own backend, and to a tenant that inherits the deployment's.