How do you stop the wrong people from getting into your cloud systems, and how do you protect the really sensitive things like database passwords and encryption keys? This is the problem of access control and secrets protection, and the DevOps Professional exam (DOP-C02) expects you to know exactly how to do it securely at scale. Without this knowledge, you'll leave your company's entire cloud infrastructure wide open to attackers.
Jump to a section
A simple way to picture IAM, Secrets Management, and Encryption
A busy professional kitchen during the dinner rush.
The head chef doesn't give every single cook a key to the walk-in fridge. Instead, she gives the sous-chef a key that only opens the pantry, the line cook a key that only opens the spice cabinet, and the dishwasher a key to the cleaning supply closet. This is IAM — Identity and Access Management. Each person (identity) gets exactly the key (permission) they need to do their job, and nothing more. The head chef also keeps a locked recipe box in her office. That box contains the secret sauce recipe and the supplier's credit card number. These are the secrets — the sensitive information that must stay hidden. Only the head chef and the owner know the combination to the lock. This is Secrets Management.
Now imagine the head chef writes down the secret sauce recipe on a piece of paper, seals it in a tamper-proof envelope, and locks it in a safe that only certain people can open. If someone wants to read the recipe, they must first unlock the safe (decryption key). If the safe is broken open, the envelope is crushed and the tampering is obvious. This is Encryption — scrambling the secret so it looks like gibberish to anyone without the right key, and if it's tampered with, you know it.
So, let's break down the three big ideas in this chapter: IAM, Secrets Management, and Encryption. They work together, but they are different things.
First, IAM stands for Identity and Access Management. In Amazon Web Services (AWS), this is the service that controls who can do what with your cloud resources. Think of it as the security guard at the front desk of a huge office building. The 'identity' is the person (or the computer program) trying to get in. The 'access' is the specific door they are allowed to walk through. IAM creates users (individual people), groups (collections of people, like 'Developers' or 'Admins'), and roles (identities you can give to a service, like a virtual machine, so it can talk to other services). For each of these, you attach policies. A policy is a document (written in a very specific language called JSON) that says 'Deny' or 'Allow' on certain actions. For example, a policy might say: 'Allow the Developer group to launch an Amazon Elastic Compute Cloud (Amazon EC2) instance, but Deny them from terminating it.' The most important rule in IAM is the Principle of Least Privilege: give someone only the exact permissions they need to do their job, nothing more. This limits the damage if their credentials are stolen.
Second, Secrets Management. Secrets are any piece of sensitive information you need to keep private, such as database passwords, API keys (a secret code used to authenticate to an application programming interface), and encryption keys. You should never, ever hard-code a secret into your application code. Why? Because code gets shared, stored in version control systems like Git, and read by many developers. If a secret is in the code, it's basically public. AWS has a service called AWS Secrets Manager that stores these secrets securely. You store the secret in Secrets Manager, and then your application asks Secrets Manager for the secret at runtime (when the application is actually running). Secrets Manager can also automatically rotate (change) secrets on a schedule, so even if someone steals a password, it will be useless after a few days. AWS also has AWS Systems Manager Parameter Store, which is a similar but simpler service for storing things like configuration settings. The key difference is that Secrets Manager is specifically designed for secrets and has automatic rotation.
Third, Encryption. Encryption is the process of scrambling readable data (plaintext) into an unreadable format (ciphertext) using a secret code called a key. Only someone with the matching key can unscramble it back to readable form. Imagine you have a diary. You write your thoughts in English (plaintext). You then run each page through a machine that turns the English into a language only you know (ciphertext). The machine requires a special key to work. That is encryption. In AWS, encryption happens in two main states: at rest (when data is stored on a disk, like in a database) and in transit (when data is moving between computers, like when you visit a website). For data at rest, AWS uses services like AWS Key Management Service (AWS KMS). KMS creates and manages the encryption keys. You tell KMS 'encrypt this file with this key', and KMS does it inside a hardware security module (HSM), which is a physical, tamper-resistant device. You never see the actual key. For data in transit, we use TLS (Transport Layer Security), which is the 'padlock' icon you see in your web browser. It encrypts the data moving from your computer to the server.
Why did these things replace older methods? Before modern Secrets Management, people stored passwords in config files or environment variables. Config files get accidentally shared. Environment variables can be read by anyone with access to the server. Before managed Key Management Services, teams had to build their own systems to generate and protect keys, which was very hard to do securely. IAM replaced the old model of 'root account with full access' — a single password that could do anything. Now, every action is logged, and every permission is granular.
On the DOP-C02 exam, you need to understand how these three services interact. For example, how does a server (EC2 instance) get permission to read a secret from Secrets Manager? It doesn't log in with a username and password. Instead, you give the EC2 instance an IAM role. That role has a policy that explicitly allows the action 'secretsmanager:GetSecretValue' on a specific secret. When the instance starts, it temporarily assumes that role and gets temporary credentials from AWS. The instance then uses those credentials to call the Secrets Manager API and retrieve the secret. The secret is then decrypted using a KMS key that the secret is encrypted with. So you see IAM + Secrets Manager + KMS all working together.
Another key concept is key rotation. Regularly changing your encryption keys reduces the amount of data an attacker can access if they steal an old key. KMS can automatically rotate your keys every year. Secrets Manager can automatically rotate your secrets (like database passwords) every few days. The exam will ask you when to use automatic rotation vs. manual rotation.
Finally, there is a difference between symmetric and asymmetric encryption. Symmetric uses one key to both encrypt and decrypt. Asymmetric uses a public key to encrypt and a private key to decrypt (like a mailbox where anyone can drop mail in, but only you have the key to open it). Both are used in AWS, but KMS primarily uses symmetric keys for most practical applications because they are faster for large amounts of data.
Create IAM Roles and Users
First, you define who needs access. Create IAM users for individual people (like developers) and IAM roles for AWS services (like EC2 instances). Attach policies that follow the Principle of Least Privilege. This ensures that every entity has only the permissions it needs.
Define and Store Secrets in Secrets Manager
Identify every password, API key, and certificate that your application needs. Store each one in AWS Secrets Manager, tagging it with metadata like the environment (production, staging). Configure automatic rotation for secrets that change frequently, like database credentials, to limit the lifespan of any leaked secret.
Create and Manage KMS Keys for Encryption
Create customer managed keys in AWS KMS for different classification levels of data (e.g., one key for customer data, one key for logs). Define key policies that specify which IAM roles and users can encrypt and decrypt with each key. Enable automatic yearly rotation for compliance.
Grant IAM Roles Permission to Access Secrets and Keys
Edit the IAM role's policy (e.g., 'WebServerRole') to allow actions like 'secretsmanager:GetSecretValue' on specific secrets and 'kms:Decrypt' on specific KMS keys. Also update the KMS key policy to include the role as a permitted user. No code changes are needed to use these permissions.
Configure Services for Server-Side Encryption
For services like S3, RDS, and EBS, navigate to their console settings and enable default encryption using the KMS key created in step 3. This ensures all new data is automatically encrypted at rest without any application logic for encryption.
Implement In-Transit Encryption with ACM and Load Balancers
Request a public SSL/TLS certificate from AWS Certificate Manager (ACM) for your domain. Attach it to your Application Load Balancer (ALB) or CloudFront distribution. This ensures all traffic between users and your application is encrypted using HTTPS.
Let's imagine you work at a company called 'CloudCart', an online shop. Your DevOps team has just migrated the entire application to AWS. Your job is to set up the security.
Step 1: Setting up IAM. You log into the AWS Management Console. The first thing you do is stop using the root user (the email and password you used to create the account) for everyday tasks. You create an IAM user for yourself with AdministratorAccess. Then you create an IAM group called 'Developers'. You create a policy that allows the developers to launch and manage EC2 instances, but not to delete them, and not to touch any databases. You attach that policy to the group. You create a user for each developer and add them to the 'Developers' group. You also create an IAM role called 'WebServerRole'. This role is what the EC2 instances that run your web server will use. The role has a policy that allows it to read from a specific S3 bucket (where the website files are stored) and to retrieve secrets from Secrets Manager.
Step 2: Storing Secrets. Your web application needs to connect to an Amazon RDS (Relational Database Service) database. The database has a username and password. You open AWS Secrets Manager. You click 'Store a new secret'. You select 'Credentials for RDS database'. You enter the username and password. You choose to automatically rotate this secret every 30 days. Secrets Manager then encrypts this secret using a key from KMS. You copy the 'Secret ARN' (Amazon Resource Name — a unique identifier for the secret) and paste it into the application's configuration file. But wait — you never put the actual password in the config file. You just put the ARN. When the application starts, it calls the Secrets Manager API with that ARN. Because the EC2 instance has the 'WebServerRole' IAM role, which has permission to call 'GetSecretValue', the request is allowed. Secrets Manager returns the decrypted secret to the application. The application uses it to connect to the database.
Step 3: Encrypting data at rest. You have an S3 bucket storing customer data. You enable 'Default encryption' on the bucket. You create a KMS key called 'CustomerDataKey'. You tell S3 to use this key to automatically encrypt any object that is uploaded to the bucket. You also ensure that only the 'WebServerRole' has permission to decrypt with this key. Now, if an attacker manages to get a copy of the S3 bucket's data, they cannot read it because it's all encrypted.
Step 4: Encrypting data in transit. You ensure your website is served over HTTPS. You obtain an SSL/TLS certificate (a digital certificate that enables encrypted communication) from AWS Certificate Manager (ACM) and attach it to your Application Load Balancer (ALB). This means all data moving between a customer's browser and your web server is encrypted.
Step 5: Monitoring. You set up AWS CloudTrail (a service that logs all API calls) to log every action taken by every user and role. If someone tries to access a secret they shouldn't, you can see exactly who, when, and how they tried. You also set up AWS Config rules to check that encryption is turned on for all your services.
This is what a real DevOps engineer does: they don't just code. They architect the security. They decide which IAM roles to create, which secrets to rotate, and which keys to use for encryption.
The DOP-C02 exam tests this topic heavily. You need to know the specific details that trip people up. Here's what they love to ask.
Firstly, the exam focuses heavily on the differences between AWS Secrets Manager and AWS Systems Manager Parameter Store. They will present a scenario where you need to store a database password. The correct answer will almost always be Secrets Manager because it supports automatic rotation, which Parameter Store does not (unless you use a custom Lambda, but the exam considers that a separate solution). If the scenario says 'store a configuration string that does not need rotation', then Parameter Store is appropriate because it's cheaper and simpler.
Secondly, IAM Roles vs. IAM Users. The exam loves to test when to use an IAM Role (for services, like an EC2 instance) versus when to use an IAM User (for a human). A common trap: they describe a scenario where an application running on an EC2 instance needs to access an S3 bucket. The wrong answer says 'create an IAM user, generate access keys, and store them on the instance'. That is the *old, bad* way. The correct answer is 'create an IAM role for EC2 and attach a policy to it'. The exam will also test that you can attach an IAM role to an EC2 instance *after* it is launched, and that the instance 'assumes' the role to get temporary credentials via the instance metadata service.
Thirdly, KMS Key Policies and IAM Policies. This is a classic area of confusion. KMS keys have their own resource-based policies (key policies) that control who can use the key. You must explicitly allow an IAM user or role in the key policy before they can use the key, even if they have an IAM policy that says 'Allow KMS:Decrypt on *'. The exam will present a scenario where a user has full admin rights but cannot decrypt a file. The trap is that the user has an IAM policy that allows it, but the KMS key policy explicitly denies the user. The correct answer is to update the KMS key policy to grant access.
Fourthly, the exam tests encryption at rest vs. in transit rigorously. They will ask: 'You have a requirement that all data must be encrypted at rest. Which service should you use?' The answer could be AWS KMS for S3 or EBS (Elastic Block Store). They might ask: 'You need to encrypt data in transit between two VPCs.' The answer could be TLS or a VPN (Virtual Private Network) connection.
Fifthly, they love the concept of 'envelope encryption' in KMS. KMS does not encrypt large files directly. Instead, it generates a Data Key. You use the Data Key to encrypt your large file, and then KMS (using a Customer Master Key) encrypts the Data Key. This is envelope encryption. The exam asks: 'Why does KMS use this approach?' The answer is performance and cost: encrypting large files with KMS directly would be slow and expensive.
List of exact concepts to memorise for the exam:
The definition and handling of 'IAM Role' vs 'IAM User' vs 'IAM Group'.
The AWS managed policies vs. customer managed policies vs. inline policies.
The concept of a 'trust policy' for an IAM role (who can assume the role).
The difference between a 'customer managed key' and 'AWS managed key' in KMS.
The requirement for a 'key policy' in KMS to grant access to a user.
The automatic rotation schedule for Secrets Manager (default 30 days) vs. KMS keys (yearly).
The use of 'AWS Certificate Manager (ACM)' for in-transit encryption with HTTPS.
Traps to watch out for:
They will try to make you choose 'IAM user with access keys' when an 'IAM role' is the correct answer.
They will say 'store the secret in the application code' — always wrong, the answer is Secrets Manager.
They will say 'use a single shared key for all teams' — wrong, you should use separate keys per team for least privilege.
They will say 'you cannot change the key policy after the key is created' — wrong, you can update it at any time.
Always use IAM roles for EC2 instances and AWS services, never embed long-term access keys in code or configuration files.
AWS Secrets Manager is the correct service for storing and automatically rotating database passwords, API keys, and other secrets.
KMS key policies are separate from IAM policies and must explicitly allow a user or role to use the key, even if the IAM policy allows it.
Envelope encryption in KMS uses a data key to encrypt data and the customer master key to encrypt the data key for performance and cost efficiency.
Encryption at rest is a server-side setting in AWS services like S3 and RDS; you do not need to modify your application code to enable it.
Use AWS Certificate Manager (ACM) and TLS to encrypt data in transit between clients and AWS resources such as load balancers.
The Principle of Least Privilege means granting IAM users and roles the minimum permissions needed to perform their tasks, reducing the blast radius of a security breach.
These come up on the exam all the time. Here's how to tell them apart.
IAM User
Permanent identity with long-term credentials (password or access keys).
Best for individual humans or applications with static access needs.
Credentials never change unless manually rotated.
IAM Role
Temporary identity that issues short-lived credentials (up to 12 hours).
Best for AWS services (EC2, Lambda) or federated users.
Credentials automatically rotate, reducing risk of leaked keys.
Secrets Manager
Designed for storing sensitive secrets like database passwords and API keys.
Supports automatic secret rotation (e.g., every 30 days).
Higher cost per secret stored.
Parameter Store
Designed for configuration data like URLs, feature flags, and AMI IDs.
No built-in automatic rotation (requires custom Lambda functions).
Lower cost, suitable for large numbers of non-secret parameters.
AWS KMS Customer Managed Key
Created and managed by you, with full control over key policies and rotation.
You can enable automatic yearly rotation and specify key administrators.
Billed separately based on key creation and usage.
AWS KMS AWS Managed Key
Created automatically by AWS for services like S3, EBS, and RDS.
You cannot view key policies or modify rotation settings.
No additional cost; usage is included in the service's pricing.
Mistake
IAM users and IAM roles are basically the same thing, you just use users for people and roles for services.
Correct
IAM users are long-term identities for people or applications that need static access keys. IAM roles are temporary identities that are assumed by trusted entities (services or users) to get temporary credentials. Roles are more secure because they have no permanent keys.
The names 'user' and 'role' sound similar, and beginners often think a 'role' is just a 'user for machines'. The lack of permanent credentials in a role is subtle but crucial.
Mistake
If I have an IAM policy that grants 'kms:Decrypt' on all keys, I can decrypt any KMS-encrypted object.
Correct
You also need the KMS key policy to grant you access. KMS uses both an IAM policy (which you attach to your user/role) and a resource-based key policy on the key itself. Both must allow the action. The resource policy can overrule the IAM policy.
People are used to IAM policies being the sole source of truth for permissions. KMS's dual-policy model is unique and confusing for beginners who haven't encountered resource-based policies before.
Mistake
Secrets Manager and Parameter Store are identical; I can use either for any secret.
Correct
Secrets Manager is designed specifically for secrets that need automatic rotation (e.g., database passwords). Parameter Store is for configuration data (e.g., URLs, feature flags) that does not need rotation. Parameter Store is cheaper and has a simpler feature set.
Both services store key-value pairs and look similar in the console. Beginners see 'store a password' and think either will do, missing the critical feature of automated rotation that Secrets Manager provides.
Mistake
Encryption at rest is handled by the application itself; I need to add encryption code to my app.
Correct
AWS services like S3, EBS, and RDS can be configured to automatically encrypt data at rest using KMS, with no changes to the application code. You just enable the setting at the service level.
Many beginners come from a background of manually encrypting data in code. They don't realise that AWS handles this transparently for managed services, reducing complexity and risk.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An IAM user is a permanent identity for a person or application with long-term credentials (password or access keys). An IAM role is a temporary identity that is assumed by a trusted entity (like an EC2 instance or a federated user) to receive temporary, automatically rotated credentials.
Use Secrets Manager when the stored value is a secret that needs automatic rotation, like a database password. Use Parameter Store for non-secret configuration data like URLs or tuning parameters, because it is simpler and cheaper.
Yes, you can enable default encryption on the bucket, but objects that were uploaded before the setting was enabled remain unencrypted. You must manually copy or rewrite those existing objects to have them encrypted.
Envelope encryption is the process where KMS generates a data key, uses it to encrypt your large data, and then encrypts the data key itself with a customer master key (CMK). This method is used because encrypting large amounts of data directly with the CMK would be slow and expensive.
Attach an IAM role to the EC2 instance. The role's policy must explicitly allow the 'secretsmanager:GetSecretValue' action on the specific secret's ARN. The instance will then retrieve temporary credentials from the instance metadata service to make the API call.
A key policy is a resource-based policy attached directly to a KMS key. It defines who can access the key and what actions they can perform (e.g., encrypt, decrypt). It works together with IAM policies; both must allow the action for it to succeed.
No. For most services (like S3, EBS, RDS), server-side encryption is optional and must be enabled by the user. Some services like EBS volumes have encryption by default in certain regions. You should always check and enable encryption at rest for all storage services.
You've finished IAM, Secrets Management, and Encryption. Continue through the DOP-C02 study guide to build a complete picture of the exam.
Done with this chapter?