Domain 4 of 4 · Chapter 3 of 5

Encryption and Masking

KMS and envelope encryption: the one model behind it all

When you turn on encryption for an S3 bucket, a Redshift cluster, an RDS instance, a DynamoDB table, or an EBS volume, the same thing happens under the hood, and learning it once makes every service obvious. The service asks AWS Key Management Service (AWS KMS) for a fresh data key, encrypts your bytes with that data key, then asks KMS to encrypt the data key itself under a long-lived KMS key (the key encryption key), and stores the resulting wrapped data key right next to the ciphertext. To read the data back, the service hands the wrapped data key to KMS, KMS unwraps it (this is the only step where the KMS key material is used, and it never leaves KMS), and the service decrypts. This pattern is envelope encryption[1], and the reason it exists is performance and blast radius: you encrypt gigabytes locally with a fast symmetric data key and only make a tiny KMS call to protect that one small key.

The three KMS key types

Every KMS key is exactly one of three ownership types, and the difference is entirely about who controls the policy, rotation, and visibility:

Key type Who owns the policy Rotation Cost Use it when
AWS owned AWS, shared across many accounts, invisible to you AWS-controlled Free A service encrypts by default and you expressed no preference
AWS managed (aws/<service>) AWS, one per service in your account Automatic, yearly, AWS-controlled Free to store, KMS request charges apply You want default encryption visible in your account but need no custom control
Customer managed (CMK) You write the key policy Optional automatic yearly, or on-demand, you choose $1 per key per month + per-request You need custom permissions, cross-account sharing, key-usage auditing, or your own rotation

AWS managed keys carry the alias aws/s3, aws/redshift, aws/rds, and so on, and you can see them in the console but cannot edit their policy or scope them. A customer managed key[1] is the one you reach for on the exam whenever the requirement names custom key policy, cross-account, audit who used the key, or control the rotation schedule.

Symmetric data keys, rotation, and deletion

KMS keys for data services are symmetric AES-256 keys; the same key wraps and unwraps the data key. Automatic rotation[2] on a customer managed key rotates the backing key material on a schedule (yearly by default) while keeping the same key ID and alias, so nothing you reference changes and old ciphertext stays readable under the retained older material. You never see the KMS HSMs directly: AWS KMS HSMs are validated at FIPS 140-3 Security Level 3[3] in all Regions where KMS is offered, so a bare "FIPS 140-2 Level 3" requirement no longer points specifically at CloudHSM. Deleting a KMS key is deliberately slow: KMS enforces a 7 to 30 day pending-deletion window[4] with no immediate delete, because once the key is gone every object it ever wrapped becomes permanently unreadable. Multi-Region keys are a related-but-distinct feature: a primary key and its replicas in other Regions share the same key ID and material, so ciphertext encrypted in one Region can be decrypted in another without a cross-Region KMS call, which matters for cross-Region S3 replication or DynamoDB global tables.

Data service (S3, Redshift, RDS...) AWS KMS holds the KMS key 1. request data key 2. plaintext + wrapped data key Stored at rest ciphertext + wrapped data key (plaintext data key discarded) 3. encrypt + store 4. unwrap to decrypt
Envelope encryption: the KMS key only wraps and unwraps the per-object data key; bulk encryption happens locally with the data key.

Encryption at rest and in transit across the data stack

Encryption at rest is configured on the store itself, and S3 is where the choices are richest. S3 offers four server-side options, and a question usually hinges on who holds the key. SSE-S3[5] uses S3-managed AES-256 keys and is the default for every new bucket since January 5, 2023, so unless someone changed it, objects are already encrypted at rest at no extra charge. SSE-KMS[5] wraps the data key under a KMS key, which adds CloudTrail auditing, custom key policies, cross-account sharing, and rotation control. DSSE-KMS[6] (dual-layer server-side encryption with KMS keys) applies two independent layers of AES-256: the first layer uses a KMS data key and the second uses a separate S3-managed key, so it is not two KMS layers, and you reach for it only when a rule explicitly names dual-layer at-rest encryption. SSE-C[7] (server-side encryption with customer-provided keys, not "customer-supplied") is the one where you send the key with every request and AWS uses it then forgets it, so AWS never stores your key; lose it and the object is gone.

Cutting KMS cost with S3 Bucket Keys

SSE-KMS normally calls KMS once per object operation, and at high request volume those kms:GenerateDataKey and kms:Decrypt calls dominate the bill. S3 Bucket Keys[8] fix this: S3 asks KMS for a short-lived bucket-level key and derives per-object data keys from it locally, which can reduce KMS request traffic and cost by up to ~99%. It is a one-flag change on the bucket, it works only with SSE-KMS (not DSSE-KMS), and it is the default answer whenever a stem complains about KMS request charges or throttling on a high-volume bucket.

The same toggle on every other store

The analytics and database services expose encryption at rest as a create-time choice backed by KMS:

  • Amazon Redshift encrypts the cluster (and its snapshots) with KMS using a four-tier key hierarchy (root key, cluster encryption key, database encryption key, data keys), where the root key is your chosen KMS key. You can set it at cluster creation or modify an unencrypted cluster later, which migrates the data to a new encrypted cluster in the background.
  • Amazon RDS / Aurora encrypt storage, automated backups, snapshots, and read replicas with a KMS key chosen at instance creation; you cannot encrypt an existing unencrypted instance in place, you restore an encrypted copy from a snapshot.
  • Amazon DynamoDB is encrypted at rest always; you only choose AWS owned (default, free), AWS managed, or a customer managed key.
  • Amazon EBS encrypts the volume, its snapshots, and the I/O between volume and instance with a KMS key; an encrypted snapshot can only restore to an encrypted volume.
  • AWS Glue encrypts job bookmarks, the Data Catalog, CloudWatch logs, and S3 outputs through security configurations that name KMS keys.

Encryption in transit and before transit

Encryption in transit is TLS on the wire to every AWS endpoint, and many services let you require it (an S3 bucket policy with aws:SecureTransport=false denied, Redshift require_ssl, RDS rds.force_ssl). Going further, client-side encryption (also called before-transit encryption) encrypts the data inside your own code with a key you control before it ever travels, so the ciphertext, not plaintext, crosses the network and lands in the store; AWS never sees the plaintext at all. The AWS Encryption SDK[9] and the S3 client-side encryption clients implement this. The distinction the exam tests: TLS protects data in transit, at-rest encryption protects it in the store, and only client-side or SSE-C keep the plaintext (or the key) out of AWS's hands entirely.

AWS must never hold the key? SSE-C you send the key per request Yes Rule names dual-layer at rest? No DSSE-KMS two AES-256 layers Yes Need audit, custom policy, cross-account, or rotation? No SSE-KMS + Bucket Keys to cut cost Yes SSE-S3 (default) No
S3 server-side encryption choice: SSE-C when AWS must not hold the key, DSSE-KMS for dual-layer, SSE-KMS for control, else SSE-S3.

Cross-account keys, masking, and anonymization

Two encrypted data sets often need to be shared across an account boundary, and the rule is simple to state and easy to get wrong: a KMS key's own key policy is the root of trust, and an IAM policy in another account grants nothing on that key until the key policy first allows that account. So a cross-account flow is always two-sided. Account A (the key owner) adds a key-policy statement allowing account B's account principal arn:aws:iam::<B>:root (which means "account B as a whole," not the root user of account B, a syntax readers reliably misread). Then account B attaches an IAM policy letting its Glue or Redshift role call kms:Decrypt on account A's key. For temporary, tightly scoped, programmatic access, account A instead issues a grant[10]: a grant is purely additive (it can allow, never deny), targets exactly one key and one grantee principal, may point at a key in a different account, and is the natural fit when a service assumes a role per job. This is the machinery under a cross-account S3 read of SSE-KMS objects and a Redshift datashare across accounts.

Masking, redaction, tokenization, anonymization

Encryption stops at the key: anyone with the decrypt path sees plaintext. When the requirement is instead "this authorized analyst should not see the raw SSNs," you need a data-presentation control, and the differences are about reversibility and where the transform happens.

  • Redshift dynamic data masking (DDM) attaches masking policies to columns and applies them per role at query time, so the stored value is unchanged and one table serves full, partial, or fully-redacted views to different roles without copies. It is the answer when different viewers need different visibility of the same live table.
  • AWS Glue PII detection transforms scan columns during an ETL job and can redact, hash, or partially mask matched entities (names, emails, card numbers), writing a cleaned data set to the target. Use it to sanitize data in the pipeline before it lands in a shared zone. (AWS Glue DataBrew similarly offers masking, hashing, and redaction recipe steps for prep work.)
  • Tokenization replaces a sensitive value with a meaningless reversible token while the real value lives in a separate, tightly controlled vault; downstream systems keep referential behavior (joins, uniqueness) without holding the secret, and only the vault can detokenize.
  • Anonymization is deliberately one-way: generalization, suppression, or hashing without a recoverable mapping, used when downstream must never be able to recover the original.

The decision axis is reversibility: masking and tokenization are reversible by a privileged path (a role, the vault), anonymization is not. Pick masking when the same store must show different fidelity per viewer, tokenization when downstream needs a stable surrogate, and anonymization when the original must be unrecoverable.

Account A (key owner) CMK key policy trusts Account B root Account B (consumer) Glue / Redshift role IAM allows kms:Decrypt 1. key policy trusts B Decrypt A's SSE-KMS data cross-account S3 read / datashare 2. role decrypts
Cross-account KMS: account A's key policy must trust account B before account B's IAM role can decrypt; a grant is the scoped alternative.

Exam-pattern recognition

Encryption-and-masking questions are usually a short scenario with one clean trigger phrase; map the phrase to the mechanism and the distractors fall away.

Which key type

"Audit who used the key," "rotate on our own schedule," "share with another account," or "custom key policy" all mean customer managed key, never AWS managed (you cannot edit its policy) and never AWS owned (invisible). "We just need it encrypted, lowest cost" points the other way to the default AWS owned / SSE-S3 answer. A stem that says "FIPS 140-3 Level 3" no longer differentiates CloudHSM from KMS; the CloudHSM trigger is now single-tenant / dedicated hardware / full key custody.

Which S3 option

"AWS must never have access to our keys" or "we supply the key on each request" is SSE-C. "Two independent layers of encryption at rest" is DSSE-KMS. "KMS request charges / throttling are too high on this bucket" is enable S3 Bucket Keys (with SSE-KMS), the single most common cost-tuning answer here. Plain "encrypt with a key we can audit and rotate" is SSE-KMS.

Encryption vs masking

If the stem describes protecting bytes from anyone without a key, it is encryption. If it describes an authorized user who should see only part of a value, it is masking: Redshift dynamic data masking for per-role visibility on the same live table, Glue PII transforms / DataBrew for redacting or hashing columns in a pipeline. "Replace the value with a reversible token kept elsewhere" is tokenization; "must never be recoverable" is anonymization. The classic distractor is choosing encryption when the requirement is masking, or anonymization when the business still needs to recover the value.

Cross-account

When account B fails to read account A's encrypted data, the missing piece is almost always account A's key policy, not account B's IAM policy; the key policy is the root of trust and an IAM grant alone is never enough. Watch the distractor that reads arn:aws:iam::<account>:root as the root user; it means the whole account.

S3 at-rest encryption options: who holds the key

PropertySSE-S3SSE-KMSDSSE-KMSSSE-C
Key encryption keyS3-managed (AES-256)AWS KMS keyKMS key (layer 1) + S3-managed (layer 2)Key you send per request
Who can audit key useNot in CloudTrailCloudTrail per requestCloudTrail per requestYou (AWS never stores the key)
Cross-account / custom policyNoYes, via key policyYes, via key policyManual (you distribute keys)
Cost driverFree (storage only)KMS per-request (cut with Bucket Keys)KMS per-request, no Bucket KeysNo KMS charge
When to chooseDefault, no special controlAudit, rotation, cross-accountRule names dual-layer at restAWS must never hold the key

Decision tree

Need custom policy, audit, or your own rotation? Customer managed key $1/key/mo + requests Yes Share encrypted data across an account? No Yes Want default encryption visible in your account? No AWS managed key aws/<service>, free to store Yes AWS owned key shared, invisible, free No Always: key deletion is irreversible after a 7 to 30 day window
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Every AWS service encrypts the same way: envelope encryption with a KMS key on top

A data service generates a one-time symmetric data key, encrypts your bytes locally with it, then asks AWS KMS to wrap that data key under a long-lived KMS key and stores the wrapped key beside the ciphertext. To read it back the service sends the wrapped data key to KMS, which unwraps it without the key material ever leaving KMS. This is why you almost never call KMS yourself for S3, Redshift, RDS, DynamoDB, or EBS; the service does it, and your only real choice is which KMS key wraps the data key.

Pick the KMS key type by how much control and auditing you need

An AWS owned key is shared across accounts, invisible to you, and free, used when a service encrypts by default. An AWS managed key (aws/s3, aws/redshift) lives in your account, is free to store, but its policy and rotation are fixed and it cannot be scoped or shared. A customer managed key (CMK) is yours: you write the key policy, share cross-account, control rotation, and every use is logged in CloudTrail. Reach for a CMK whenever the requirement names custom permissions, cross-account, auditing, or your own rotation schedule.

Trap Choosing an AWS managed key when the requirement is a custom key policy or cross-account sharing; its policy is fixed and AWS-controlled, so it cannot do either.

3 questions test this
Only a customer managed key gives you key-usage auditing and your own rotation schedule

AWS managed keys rotate automatically once a year on an AWS-controlled schedule and you cannot change it; a customer managed key lets you enable automatic yearly rotation, trigger on-demand rotation, or turn rotation off. CloudTrail records every kms:Decrypt and kms:GenerateDataKey against your CMK, which is what "audit who used the key" requires. An AWS owned key produces no per-key visibility at all.

6 questions test this
Automatic key rotation keeps the same key ID, so nothing you reference breaks

When KMS rotates a customer managed key it generates new backing material but keeps the same key ID, ARN, and alias, and retains the older material so ciphertext encrypted before rotation still decrypts. That means you do not re-encrypt existing data or update any reference when rotation happens. Rotation protects against long-term key-material exposure, not against a compromised key policy.

5 questions test this
KMS key deletion is irreversible and enforces a 7 to 30 day waiting window

You cannot immediately delete a KMS key; you schedule deletion with a waiting period of 7 to 30 days (default 30), and you can cancel during the window. The window exists because once the key is gone every object it ever wrapped is permanently unreadable. Disable a key instead of deleting it when you only need to stop its use temporarily.

Trap Scheduling a key for deletion to quickly cut off access; the data wrapped by it becomes unrecoverable, so disable the key instead when the block is temporary.

FIPS 140-3 Level 3 no longer distinguishes CloudHSM from KMS

AWS KMS HSMs are validated at FIPS 140-3 Security Level 3 in all Regions where KMS is offered, so a bare "needs FIPS 140-3 Level 3" requirement is satisfied by KMS alone. The CloudHSM trigger has shifted to single-tenant dedicated hardware or full customer custody of key material, not the FIPS level by itself.

Trap Selecting CloudHSM purely because a stem says "FIPS 140-3 Level 3"; KMS already meets that level, so the differentiator must be single-tenancy or full key custody.

Use multi-Region KMS keys so ciphertext decrypts in another Region without a cross-Region call

A multi-Region key is a primary key plus replicas in other Regions that share the same key ID and key material, so data encrypted in one Region can be decrypted in another with the local replica. This is what cross-Region S3 replication of SSE-KMS objects or a DynamoDB global table needs; an ordinary single-Region key cannot decrypt material in a different Region. It is a deliberate choice at key creation, not the default.

Trap Assuming a normal customer managed key works for cross-Region replication; only a multi-Region key shares material across Regions, so a standard key blocks decryption at the destination.

SSE-S3 has been the default for every new S3 bucket since January 5, 2023

All new S3 buckets encrypt objects at rest with S3-managed AES-256 keys (SSE-S3) by default, at no extra charge and with no per-bucket action. So "is this data encrypted at rest" is yes unless someone changed it. SSE-S3 gives no CloudTrail key auditing and no custom key policy; step up to SSE-KMS when you need those.

Choose the S3 encryption option by who holds and audits the key

SSE-KMS wraps the data key under a KMS key, adding CloudTrail auditing, custom key policies, cross-account access, and rotation control. SSE-C (server-side encryption with customer-provided keys) means you send the key on every request and AWS uses then forgets it, so AWS never stores your key and losing it loses the object. DSSE-KMS applies dual-layer at-rest encryption. Match the stem: "audit and rotate" is SSE-KMS, "AWS must never hold the key" is SSE-C.

DSSE-KMS is dual-layer, but only the first layer is KMS-backed

DSSE-KMS (dual-layer server-side encryption with KMS keys) applies two independent layers of AES-256: the first uses a KMS data key, the second uses a separate S3-managed key. It is not two KMS layers. Reach for it only when a requirement explicitly names dual-layer at-rest encryption; otherwise SSE-KMS is sufficient and cheaper, and DSSE-KMS does not support S3 Bucket Keys.

Trap Treating DSSE-KMS as two KMS layers or as the default for sensitive data; only its first layer is KMS-backed and plain SSE-KMS covers ordinary needs at lower cost.

Turn on S3 Bucket Keys to cut SSE-KMS request cost on high-volume buckets

Plain SSE-KMS calls KMS once per object operation, so a high-request bucket racks up kms:GenerateDataKey and kms:Decrypt charges and can hit throttling. S3 Bucket Keys derives a short-lived bucket-level key from KMS and generates per-object data keys locally, reducing KMS request traffic and cost by up to roughly 99%. It is a one-flag change, works with SSE-KMS only (not DSSE-KMS), and is the go-to answer when a stem complains about KMS request charges.

Trap Switching from SSE-KMS to SSE-S3 just to cut KMS request cost and losing the audit and policy control; S3 Bucket Keys keeps SSE-KMS while removing most of the per-object KMS calls.

5 questions test this
Encrypt RDS and Aurora at creation; you cannot encrypt an existing instance in place

RDS and Aurora encryption of storage, automated backups, snapshots, and read replicas is a KMS-backed choice made at instance creation. To encrypt an existing unencrypted instance you snapshot it, copy the snapshot with encryption enabled, and restore from that encrypted copy. A read replica inherits the source's encryption state.

Trap Assuming you can toggle encryption on a running unencrypted RDS instance; you must restore an encrypted copy from a snapshot instead.

2 questions test this
DynamoDB is always encrypted at rest; you only choose the key type

DynamoDB encrypts every table at rest by default and you cannot turn it off; the only decision is AWS owned (default, free), AWS managed, or a customer managed key. Pick a customer managed key when you need CloudTrail auditing of key use or a custom key policy on the table's data.

EBS encryption covers the volume, its snapshots, and the data path

An encrypted EBS volume encrypts data at rest, all of its snapshots, and the I/O between the volume and the instance, all with a KMS key. An encrypted snapshot can only be restored to an encrypted volume, and copies of encrypted snapshots stay encrypted. Account-level "encryption by default" forces every new volume to be encrypted.

TLS protects data in transit; client-side encryption keeps plaintext out of AWS entirely

Encryption in transit is TLS on the wire to every endpoint, and you can require it (an S3 policy denying aws:SecureTransport=false, Redshift require_ssl, RDS rds.force_ssl). Client-side, or before-transit, encryption goes further: your code encrypts the data with a key you control before it travels, so only ciphertext crosses the network and lands in the store and AWS never sees plaintext. When a stem says AWS must never see the data, that is client-side encryption or SSE-C, not ordinary at-rest encryption.

Trap Answering server-side SSE-KMS for "AWS must never see our plaintext"; the service still decrypts server-side, so only client-side encryption or SSE-C keeps plaintext or the key out of AWS.

A KMS key's own key policy is the root of trust for cross-account access

An IAM policy in another account grants nothing on a KMS key until that key's own key policy first allows the other account. So sharing encrypted data across accounts is two-sided: account A's key policy trusts account B's account principal, then account B's IAM role is allowed kms:Decrypt. When account B cannot read account A's SSE-KMS data, the missing piece is almost always account A's key policy, not B's IAM policy.

Trap Granting only an IAM policy in the consumer account and expecting cross-account decrypt to work; without an allow in the key's own policy KMS denies it.

4 questions test this
In a key ARN, :root means the whole account, not the root user

A key-policy principal like arn:aws:iam::<account>:root trusts that entire account as a delegation target, letting the account's administrators in turn grant access to their principals. It does not mean the account's root user. Reading it as the root user is a classic distractor on cross-account encryption questions.

Trap Reading arn:aws:iam::<account>:root in a key policy as the root user; it designates the whole account as a trusted principal.

Use a KMS grant for temporary, scoped, programmatic key access

A grant is purely additive (it can allow, never deny), targets exactly one KMS key and one grantee principal, and may point at a key in another account, which fits a service that assumes a role per job. Grant changes are eventually consistent, so use the returned grant token to exercise a new grant immediately. The limit is 50,000 grants per KMS key.

Trap Expecting a grant to deny or restrict access; a grant only adds permissions, so you cannot use it to carve back what a key policy already allows.

Use Redshift dynamic data masking to show different fidelity per role without copies

Redshift dynamic data masking attaches masking policies to columns and applies them per role at query time, so the stored value never changes and one table serves full, partial, or fully-redacted views to different roles. It is the answer when authorized but lower-privilege users must see only part of a sensitive column on the same live table. Encryption cannot do this, because anyone with the decrypt path sees the raw value.

Trap Reaching for encryption to hide values from an authorized analyst; they hold the decrypt path, so use dynamic data masking to control what each role sees.

Use Glue PII transforms to detect and redact sensitive columns inside the pipeline

AWS Glue PII detection transforms scan columns during an ETL job and can redact, hash, or partially mask matched entities such as names, emails, and card numbers, writing a cleaned data set to the target. Use it to sanitize data before it lands in a shared zone. Glue DataBrew offers similar masking, hashing, and redaction steps for data-prep recipes.

2 questions test this
Choose masking, tokenization, or anonymization by whether the value must be recoverable

Masking and tokenization are reversible through a privileged path: masking shows different fidelity per role on the same stored value, and tokenization swaps the value for a reversible token while the real value sits in a separate vault, preserving joins and uniqueness downstream. Anonymization is deliberately one-way, with no recoverable mapping, used when the original must never be recovered. Decide by reversibility before picking the technique.

Trap Anonymizing data the business still needs to re-identify later; anonymization is one-way, so use tokenization when downstream must recover the original through the vault.

Customer managed keys carry a monthly fee plus per-request charges; AWS managed and owned keys are free to store

A customer managed KMS key costs about $1 per key per month plus per-request charges (roughly $0.03 per 10,000 requests), while AWS managed and AWS owned keys have no storage fee. That cost is the trade for custom policy, auditing, and rotation control, so do not create a CMK when default encryption with a free key meets the requirement. On a high-request SSE-KMS bucket, S3 Bucket Keys is what keeps the per-request side of that bill down.

Encrypting needs kms:GenerateDataKey; decrypting needs kms:Decrypt on the customer managed key

With SSE-KMS and a customer managed key, the side that writes data (a Kinesis producer, a Glue job uploading objects) needs kms:GenerateDataKey on the key, and the side that reads (a Kinesis consumer, a Glue job downloading objects) needs kms:Decrypt. Granting these only in the identity policy is not enough: the KMS key policy must also allow the role to use the key. The same kms:Decrypt requirement applies to a Secrets Manager secret encrypted with a customer managed key.

Trap Giving a producer kms:Decrypt and expecting writes to work, when the encrypt path actually requires kms:GenerateDataKey.

7 questions test this
Glue Detect PII applies fine-grained actions like PARTIAL_REDACT per entity and column

The Glue Detect PII transform takes a per-entity action, so one job can SHA256-hash emails for consistent joins while REDACT-ing names. PARTIAL_REDACT with numRightCharsToExclude keeps the last N characters (e.g. last four digits) and redactChar sets the mask. Cell-level detection scans each value, sourceColumns scopes actions to chosen columns, and outputColumnName writes detection metadata to a new column for audit.

Trap Using full REDACT when the requirement is to keep the last four digits, which needs PARTIAL_REDACT with numRightCharsToExclude.

6 questions test this

Also tested in

References

  1. AWS KMS concepts: envelope encryption
  2. Rotate AWS KMS keys
  3. AWS KMS FAQs (FIPS 140-3 Security Level 3) FAQ
  4. Deleting AWS KMS keys (7 to 30 day pending-deletion window)
  5. Amazon S3 server-side encryption with KMS keys (SSE-S3 / SSE-KMS)
  6. Amazon S3 server-side encryption (DSSE-KMS dual-layer)
  7. Amazon S3 SSE-C: server-side encryption with customer-provided keys
  8. Reducing the cost of SSE-KMS with Amazon S3 Bucket Keys
  9. AWS Encryption SDK (client-side encryption)
  10. AWS KMS grants