AWSAWS Certified Generative AI Developer - Professional2026-103.2 Implement data security and privacy controls
Separate data encryption from credential delivery
Completed by the knowledge check
Learning objective
Protect application data using AWS KMS, AWS Encryption SDK, and Secrets Manager for credentials.
Core idea
Choose separate controls for cryptographic authority, application payload protection, and credential lifecycle. AWS KMS controls use of KMS keys. The AWS Encryption SDK encrypts application data and protects its data keys with configured wrapping keys. AWS Secrets Manager stores credentials and supports retrieval and rotation.
These mechanisms do not make plaintext harmless after decryption. An application that retrieves a credential must keep it out of model context, tool descriptions, and logs. An application that decrypts a document must still enforce the reader’s entitlement. Encryption protects a representation of data; authorization determines who may obtain and use its plaintext.
How it works
Define who can use the key
Every KMS key has exactly one key policy. That resource policy is the primary access-control mechanism for the key. IAM policies and grants can also control access, but an IAM allow has no effect unless the key policy enables that use of IAM permissions. The default key policy enables IAM policies; do not assume a custom key policy does the same.
Separate key administration from data processing. A workload that needs decryption should not receive general authority to change the key’s access policy. Scope the required cryptographic operations and key resources to the workload’s job. Review both the key policy and the identity permission when diagnosing a denied decrypt; a storage-read allow is not a KMS-use allow.
For symmetric encryption KMS keys, an encryption context is an optional set of non-secret key-value pairs. AWS KMS uses it as additional authenticated data and binds it to the ciphertext. The same context is required to decrypt that data. A context can describe an application or data category and makes cryptographic operations easier to distinguish in audit evidence.
The context is not encrypted and appears in CloudTrail logs. Use non-sensitive identifiers rather than names, credentials, document excerpts, or other confidential fields. The key policy or identity policy can restrict key use through kms:EncryptionContext:CONTEXT_KEY and kms:EncryptionContextKeys. Grant constraints can use EncryptionContextEquals or EncryptionContextSubset to constrain permitted context values.
Context integrity is not an entitlement lookup. If a caller can choose any tenant value and use the key for that value, adding a tenant field alone does not create tenant isolation. Derive the expected value from trusted application state, enforce the corresponding authorization, and make the permitted key use consistent with that boundary. See 3.2.2 for the application decision.
Encrypt application payloads with a reviewed keyring
The AWS Encryption SDK implements authenticated encryption and manages envelope encryption. By default, it generates a unique data key for each object it encrypts. It encrypts that data key under one or more wrapping keys and stores the encrypted data keys with the encrypted payload in its formatted message.
Use this when application data must remain encrypted across a storage or transport boundary until an authorized application component decrypts it. Define the boundary explicitly: which component creates plaintext, which component encrypts it, where the encrypted message travels, and which component is allowed to decrypt. A model requiring the document’s contents still needs plaintext at its input boundary, so preserve the authorization check there.
A symmetric AWS KMS keyring has a generator key and can include additional wrapping keys. The generator creates the plaintext data key and its encrypted form. Additional keys encrypt that same data key; they do not create additional mandatory approvals for decryption.
For this symmetric keyring configuration, encryption requires kms:GenerateDataKey on the generator and kms:Encrypt on additional keys. Decryption requires kms:Decrypt on at least one appropriate key. Adding a recovery wrapping key can improve recoverability, but any authorized decryption path through that key can recover the same data key. Review it as an additional access path, not as a two-person authorization mechanism. Either wrapping key alone recovers the same data key, and with it the payload.
Use explicit key ARNs for decryption keyrings. The keyring documentation requires key ARNs for decryption and for keyrings used for both encryption and decryption. Avoid an unconstrained discovery choice when the application contract expects a fixed approved key set. Keep the encrypted-message format and configured key set in the data contract so a receiving component knows how to recover the payload.
The AWS Encryption SDK message is not raw AWS KMS ciphertext. KMS Decrypt cannot decrypt the complete message returned by the SDK, and the SDK cannot decrypt ciphertext returned directly by KMS Encrypt or ReEncrypt. Use the matching interface on each side instead of handing the whole stored payload to KMS and expecting interoperability.
Retrieve credentials without exposing them to the agent
Secrets Manager’s GetSecretValue returns a secret’s decrypted SecretString or SecretBinary. The request identifies SecretId and can select VersionId or VersionStage. When neither version selector is provided, Secrets Manager returns the version labeled AWSCURRENT.
The caller needs secretsmanager:GetSecretValue. If the secret uses a customer-managed KMS key rather than aws/secretsmanager, the caller also needs kms:Decrypt on that key. Scope the application permission to the intended secret and give the tool adapter responsibility for retrieving and using it. The agent should propose a business operation, not request an unrestricted secret by name.
GetSecretValue produces a CloudTrail event. AWS omits the sensitive secret value fields from those log entries, but your own logging must also omit them. Avoid dumping SDK responses, connection strings, or exception objects containing credentials. A tool result should report the business result without returning its authentication material.
The Secrets Manager Python caching client, aws-secretsmanager-caching, uses a least recently used (LRU) cache and refreshes secrets every hour by default. It requires secretsmanager:DescribeSecret and secretsmanager:GetSecretValue. Configure its refresh interval to match the rotation schedule and acceptable stale-credential window. The cache does not include cache invalidation, so verify refresh and failure behavior when the target credential changes. A successful historical retrieval does not prove the cached credential remains accepted.
Rotation updates both the stored secret and the corresponding database or service credential. Secrets Manager documents managed rotation, managed external-secret rotation for partner-held secrets, and Lambda-based rotation for other secret types. Select the supported mechanism for the target credential; not every rotation path uses Lambda. Verify that both the target system and the application’s retrieval or cache behavior work after rotation, rather than considering a changed secret value sufficient.
Key distinctions and trade-offs
KMS key versus data key: The keyring uses KMS keys to protect the data key. The data key encrypts the application payload. Review cryptographic authority at the wrapping-key boundary.
Authenticated context versus confidentiality: Encryption context binds metadata to cryptographic processing but does not hide that metadata. Keep sensitive content out of it.
Multiple wrapping keys versus multiple approvals: Additional wrapping keys provide alternative recovery paths. They do not require every key holder to approve decryption.
Encrypted payload versus credential lifecycle: The Encryption SDK protects application messages. Secrets Manager gives credentials a retrieval and rotation contract; encrypting a password in a payload is not equivalent to managing its lifecycle.
Architecture / decision scenario
A claims processor stores encrypted document packages and uses a vendor API credential to submit authorized cases. The team wants recoverable payload encryption without exposing the credential to the model.
It configures a symmetric KMS generator key in the Encryption SDK and grants the writer kms:GenerateDataKey. A reviewed recovery wrapping key requires kms:Encrypt; the team explicitly recognizes that either approved decryption path can recover the package. Readers use explicit decryption key ARNs and narrowly scoped kms:Decrypt. Non-sensitive encryption context identifies the application category, while trusted application checks establish case entitlement.
The submission adapter retrieves its specific secret with GetSecretValue, keeps SecretString out of model context and logs, and uses the credential inside the adapter. Rotation updates the vendor credential and stored secret through the supported rotation mechanism. Acceptance verifies payload recovery, a denied key-use path, an unauthorized case, and credential refresh after rotation.
Common exam traps
- Assuming an IAM allow alone always enables use of a KMS key.
- Putting confidential data in encryption context.
- Treating multiple wrapping keys as mandatory joint approval.
- Sending an Encryption SDK message directly to KMS
Decrypt. - Returning secret values in tool outputs or application logs.
- Rotating the stored value without updating the target credential and cache behavior.
What to remember
- Review key policies and workload cryptographic permissions together.
- Use envelope encryption for the intended application boundary.
- Keep encryption context non-sensitive and authorization independent.
- Retrieve credentials inside trusted adapters.
- Verify rotation across the secret, target system, and application.
Knowledge check
A claims processor encrypts each document package with a symmetric KMS key and wants the encryption context to make those operations easy to tell apart in audit evidence. Which context fits?
A security review requires that no single team can decrypt the claim packages alone. The team adds a second team’s KMS key as an additional wrapping key in the Encryption SDK keyring. Does that meet the requirement?
kms:Decrypt on every wrapping keykms:Decrypt on at least one key in the keyring. A second key adds a recovery path, which is also a second access path; it never makes two holders approve together.A reader role’s identity policy allows kms:Decrypt on a customer managed key, yet every decrypt is denied. The key was created with a custom key policy. What is the most likely cause?
s3:GetObject on the bucket that stores the ciphertextkms:GenerateDataKey to decryptAn agent’s tool must call a vendor API with a credential stored in Secrets Manager. Where should the credential be retrieved and used?
GetSecretValue , uses it, and reports only the outcome. Anything placed in a prompt, tool description, or tool result enters model context, and can then reach outputs and logs. The agent proposes the operation; it never needs the credential.After a scheduled rotation, the vendor API rejects the adapter’s calls for up to an hour, then recovers. The adapter reads the credential through the Python Secrets Manager caching client with its default settings. What explains the window?
secretsmanager:DescribeSecret until the cache expiresGetSecretValue keeps returning the previous version after rotationGetSecretValue returns AWSCURRENT .