> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Secret Manager

> Secret Manager APIs with Cloud Adapter.

This page describes how Secret Manager maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

## Supported environments

| Environment | Mapping |
| ----------- | ------- |
| AWS         | API     |
| Azure       | API     |

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

## How the targets compare

Each row compares a capability of Secret Manager with its adaptation on each target.
A dash means this profile does not state the capability for that target.

### Cloud Adapter

| Capability   | Secret Manager | AWS  | Azure |
| ------------ | -------------- | ---- | ----- |
| API coverage | full           | high | high  |

## On AWS

### Secrets Manager

| Operation               | Area     | Support   | Depth        | Notes                                                                                                                                                                                                                                                |
| ----------------------- | -------- | --------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Rotation notifications  | Rotation | Partial   | Full surface | The rotation topic becomes a target event rule. Subscribers must be redirected for the target's delivery format; the build identifies the change.                                                                                                    |
| secrets.create / delete | Secrets  | Supported | Common       | a secret becomes a secret on the target, with its labels rewritten as tags                                                                                                                                                                           |
| versions.add / access   | Versions | Supported | Common       | Version identifiers are translated so clients can add and read versions, including requests for a specific version.                                                                                                                                  |
| versions.destroy        | Versions | Partial   | Most usage   | AWS has no direct API to delete one version. Unlabelled versions can be removed in the background; scheduling deletion of a whole secret makes all versions inaccessible. The build requires acknowledgement of the different destruction semantics. |

Secrets and versions map to AWS Secrets Manager. The adapter translates version identifiers so clients requesting a specific version can continue adding and reading secrets.

### Names and version references

The adapter maps source secret names and version references to target values. A request for the latest version can change after a new value is published; a request pinned to a version must continue identifying that version. Copy required values and version references explicitly, because creating the target secret does not transfer its history.

### Access and deletion

Set permissions for secret reads separately from lifecycle administration. Check what remains recoverable after disabling or deleting a value, and how long the target reserves its name. Update rotation-event consumers where the target delivers a different event format.

### Compatibility differences

AWS has no API that directly deletes one secret version. Removing its staging labels makes it eligible for background deletion; deleting a whole secret instead affects every version. A secret scheduled for deletion cannot be read until restored. These semantics differ from destroying one Google Secret Manager version, and the build requires acknowledgement of the difference.

## On Azure

### Key Vault

| Operation                              | Area     | Support      | Depth        | Notes                                                                                                                                                                       |
| -------------------------------------- | -------- | ------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Customer-managed encryption per secret | Secrets  | Out of scope | Full surface | Encryption is configured at vault level, without an equivalent customer-managed key per secret.                                                                             |
| Multi-region replication               | Secrets  | Out of scope | Full surface | This mapping has no equivalent for a user-managed replication policy across regions; the vault belongs to one region.                                                       |
| secrets.create / delete                | Secrets  | Supported    | Common       | a secret becomes a vault secret, with its labels rewritten as tags                                                                                                          |
| versions.add / access                  | Versions | Supported    | Common       | the vault addresses secret versions individually, so adding and reading a version work directly                                                                             |
| versions.destroy                       | Versions | Partial      | Most usage   | Destroying a version disables it instead of erasing its contents. Deleted secrets retain their names until purged. The build requires acknowledgement of these differences. |

Secrets and versions map to Azure Key Vault, with individual versions available for adding and reading secrets.

### Names and version references

The adapter maps source secret names and version references to target values. A request for the latest version can change after a new value is published; a request pinned to a version must continue identifying that version. Copy required values and version references explicitly, because creating the target secret does not transfer its history.

### Access and deletion

Set permissions for secret reads separately from lifecycle administration. Check what remains recoverable after disabling or deleting a value, and how long the target reserves its name. Update rotation-event consumers where the target delivers a different event format.

### Compatibility differences

Destroying a version disables it instead of erasing its contents. Deleted secrets retain their names until purged. Encryption is configured for the vault, so a customer-managed key per secret is unsupported; a user-managed replication policy across regions is also unsupported by this mapping.

## Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application's endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

## Configure, tune and debug

Start with [setup](/cloud-adapter/getting-started/overview) and [configuration](/cloud-adapter/configuration/overview). Use [tuning](/cloud-adapter/tuning/overview) to understand supported request tags, [debugging](/cloud-adapter/debugging/overview) to investigate a request, and [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) to validate a bounded reproduction.