If you store a database password in your application's source code or a plain text config file, you are one accidental commit to a public repository away from a data breach that could bankrupt your employer. Managing secrets and secure application configuration is the set of practices that keeps passwords, API keys, and sensitive settings out of your code and still available to the applications that need them. For the DVA-C02 exam, this topic is vital because AWS practically invented the cloud-native services (Secrets Manager and Parameter Store) that solve this exact problem, and the exam will test whether you know which tool to use for which job.
Jump to a section
Your desk in a busy office building. It has a shallow top drawer where you keep your pens, notepads, and the office stapler — things that aren't really secret, just convenient to have nearby.
But you also have a locked bottom drawer. That drawer holds the master key to the server room, the Wi-Fi password card, the payroll spreadsheet, and the login credentials for the company's bank account. If the wrong person gets into that bottom drawer, the whole company could be in serious trouble.
Now imagine your company grows from 5 people to 500. Every employee used to know the Wi-Fi password — it was written on a whiteboard. But now, the intern gives the Wi-Fi password to a friend who visits the office, and suddenly the network is being used by strangers. The payroll spreadsheet from your locked drawer gets emailed to the wrong person by mistake. Every time you update the server room lock code, you have to walk around and tell each senior employee the new code individually, and someone always forgets to update their copy. It is a security nightmare.
So the company hires a Key Keeper. The Key Keeper is a dedicated person whose only job is to manage secrets. You do not keep the server room code in your locked drawer anymore. Instead, when you need the code, you file a request with the Key Keeper. The Key Keeper checks that you have permission, then gives you the code for a limited time. When the code changes (because a security guard quit), you only tell the Key Keeper. The Key Keeper updates the code in one central place, and every employee who is allowed to see it gets the new code automatically the next time they ask. The Key Keeper also keeps an audit log — a list of every time someone requested a code, who they were, and when. If the password to the bank account is leaked, the Key Keeper can look at the audit log and see exactly who asked for it last.
AWS Secrets Manager and AWS Systems Manager Parameter Store are the Key Keeper for your cloud applications. They are a central, secure, and automated way to store, rotate, and audit access to your secrets like database passwords, API keys, and configuration settings.
Let's start with the problem. When you write a web application, it often needs to connect to a database. To do that, the application needs a database username and password. A beginner might just write those credentials right into the code: 'username = admin; password = P@ssw0rd123'. This is called hardcoding credentials. It is the single most common and most dangerous security mistake. If the code is shared on GitHub, the password is public. If an attacker gets a copy of the application file, they have the password. Even if the code is private, every person who has access to the code (developers, testers, operators) now also has access to the production database, which they probably should not have.
A slightly better approach is to put the credentials into a configuration file — a .env or config.json file — and then tell the application to read that file at startup. This is an improvement because the file can be listed in .gitignore so it is not committed to version control. But the problem remains: the file itself is sitting on the server's hard drive, often unencrypted. If an attacker gains access to the server, they can read the file. Also, when you change the database password (which you should do regularly), you have to manually update the file on every server, which is error-prone and slow.
AWS offers two managed services (a service that AWS runs for you so you do not have to manage the underlying infrastructure) that solve this: AWS Secrets Manager and AWS Systems Manager Parameter Store. Both are services that store sensitive information securely and make that information available to your applications on demand.
AWS Secrets Manager is designed specifically for 'secrets' — things that have high sensitivity and need to change frequently. A secret could be a database password, an API key for a third-party service, or an OAuth token (a type of access token used in modern authentication). Secrets Manager can automatically rotate (change) secrets on a schedule. This is a game-changer. Imagine a rule that says 'the database password must change every 30 days'. With Secrets Manager, you tell it to rotate the secret every 30 days, and it handles the complex process of generating a new password, updating it in the database, and making sure your application can still connect while the change happens. Secrets Manager also encrypts the secret at rest (when it is stored) using AWS Key Management Service (AWS KMS), which is a separate service that manages encryption keys. When your application needs the secret, it calls the Secrets Manager API (Application Programming Interface — a way for one piece of software to talk to another), and Secrets Manager checks if the application has the right IAM (Identity and Access Management) permissions before returning the secret value in plain text over a secure HTTPS (Hypertext Transfer Protocol Secure) connection. Secrets Manager also automatically replicates secrets to multiple AWS regions (geographic locations where AWS has data centres) if you enable it, which helps if your application is deployed globally and needs low-latency access to the same secret.
AWS Systems Manager Parameter Store is a broader service. It stores parameters — which are pieces of configuration data. A parameter might be a plain-text value like a database host name (e.g., 'mydb.c9akfj8.us-east-1.rds.amazonaws.com'), a fully secure secret like a password, or a hierarchical structure like a JSON string. Parameter Store has a tiering system: Standard and Advanced. Standard parameters are free, have a 4KB size limit, and are limited to 10,000 parameters per AWS account. Advanced parameters cost a small fee, allow sizes up to 8KB, and support policies like 'expiration' where a parameter automatically expires after a certain date (useful for temporary credentials). While Secrets Manager is purpose-built for secrets, Parameter Store is better suited for configuration data that is not extremely sensitive or does not need automatic rotation. For example, you might store the URL of your company's logo image, the default page size for search results, or the version number of your application in Parameter Store.
When should you use which? The official AWS guidance, and what the exam tests, is this:
Use Secrets Manager for secrets that need automatic rotation, especially database credentials.
Use Parameter Store for configuration data that does not require rotation or for secrets when you do not want to pay the extra cost of Secrets Manager (Parameter Store standard tier is free).
Both services integrate with AWS Lambda (a serverless compute service) and EC2 (Elastic Compute Cloud — virtual servers in the cloud). A common pattern is that your application, running on an EC2 instance or a Lambda function, has an IAM role attached to it. That IAM role grants permission to read a specific secret or parameter. When the application starts up, it asks the service for the value, and the service returns it. This means the secret never sits in a file on the server. It only exists in the application's memory while the application is running. If the server is compromised, the attacker cannot read a file to get the secret because there is no file. They would have to compromise the application's memory while it is running, which is far more difficult. This is a huge security improvement.
Another important concept is secret rotation in Secrets Manager. Secrets Manager can be configured to rotate a secret on a schedule. For a relational database like RDS (Amazon Relational Database Service), Secrets Manager can connect to the database directly and change the password for the user. It does this by creating a 'pending' version of the secret first, then testing that the application works with the new secret, and then retiring the old one. This process is called 'immediate rotation' and ensures zero downtime.
For the exam, remember that both services can be accessed via the AWS Management Console (the web interface), the AWS CLI (Command Line Interface — typing commands in a terminal), and SDKs (Software Development Kits — code libraries for languages like Python, Java, and JavaScript). The exam will often give you a scenario where an application needs a piece of configuration data, and you must decide between storing it in Secrets Manager, Parameter Store, or just hardcoding it (which is almost always wrong).
Finally, there is an important security concept: IAM policies. Both Secrets Manager and Parameter Store work with IAM to control access. You can write a policy that says 'only the application with this specific IAM role can read secrets with the tag 'Environment=Production'.' This gives you fine-grained control over who can access what. The exam loves to test whether you understand that you need to grant a Lambda function an IAM role with the correct permissions to read a secret — just creating the secret is not enough.
Identify the secret or configuration value
Determine what information your application needs. Is it a database password (a secret that should change regularly) or a database hostname (configuration data that rarely changes)? This distinction decides whether you use Secrets Manager or Parameter Store. For DVA-C02, understanding this choice is half the battle.
Create the secret in Secrets Manager or parameter in Parameter Store
Use the AWS Management Console, CLI, or SDK to create the resource. For Secrets Manager, choose the type of secret (e.g. 'Credentials for Amazon RDS database') and enter the values. Enable automatic rotation if appropriate. For Parameter Store, create a parameter and choose 'SecureString' if the value is sensitive. Use a hierarchical name like '/app/prod/db/password' for organisation.
Set up IAM permissions
Attach an IAM role to the compute resource (EC2 instance, Lambda function, ECS task) that needs to read the secret or parameter. Add a policy that grants 'secretsmanager:GetSecretValue' (or 'ssm:GetParameter') on the specific resource ARN. If using a SecureString or a customer-managed KMS key, also grant 'kms:Decrypt'. This is the most common point of failure in real-world applications.
Write application code to retrieve the value
Modify your application code to call the AWS SDK at startup. For example, in Python with boto3, you call `get_secret_value()` from the Secrets Manager client, or `get_parameter()` from the SSM client. Never copy the value into a local file — keep it only in memory. Handle the case where the call fails (e.g., the IAM role does not have permission) by logging a meaningful error and exiting gracefully.
Set up automatic rotation (Secrets Manager only)
If you created a secret in Secrets Manager and enabled automatic rotation, Secrets Manager will generate a new random password on the scheduled interval. For RDS databases, this works out of the box. For other types of secrets, you need to provide a custom Lambda function that performs the rotation logic. Monitor CloudTrail logs to confirm rotation is succeeding without errors.
Test and audit
Deploy your application to a non-production environment first. Test that it can start up, retrieve the secret, and connect to the database. Check CloudTrail to verify that the API call was made by the correct IAM role. Also test the failure case: revoke the IAM permission temporarily and confirm the application fails securely (does not crash with an unencrypted error message).
Implement version control for the secret
Secrets Manager keeps multiple versions of a secret (AWSPREVIOUS, AWSCURRENT, AWSPENDING). Parameter Store supports parameter labels. If you update a secret, your application can be coded to fall back to the previous version during a rotation window. This is advanced but tested on DVA-C02. In practice, using the high-level SDK (which automatically handles version tracking) is often enough.
An IT professional at a mid-sized e-commerce company is tasked with building a secure architecture for a new customer-facing online store. The store needs to connect to a PostgreSQL database that holds customer orders, inventory, and payment data. The database credentials must be secure, automatically rotated every 60 days, and the team wants to be alerted if someone tries to access the credentials without authorisation.
Here is how they would use Secrets Manager and Parameter Store to achieve this:
Creating the secret in Secrets Manager: The engineer logs into the AWS Management Console, navigates to Secrets Manager, and creates a new secret of type 'Credentials for Amazon RDS database'. They enter the database username and password. They choose the automatic rotation option and set it to 60 days. Secrets Manager immediately begins managing the secret.
Setting up rotation for the database: The engineer selects a Lambda function from a list of 'rotation templates' that AWS provides. This Lambda function contains the code that will connect to the database and change the password. The engineer configures the Lambda function with the correct network settings so it can reach the database. Secrets Manager will invoke this Lambda function every 60 days to perform the rotation.
Attaching the IAM role to the application: The application (a set of containers running on AWS ECS — Elastic Container Service) has an IAM role attached to it. The engineer adds an IAM policy to that role that looks like this:
Allow 'secretsmanager:GetSecretValue' on the ARN (Amazon Resource Name — the unique ID of the AWS resource) of the specific secret.
Allow 'kms:Decrypt' on the KMS key used to encrypt the secret (because Secrets Manager uses KMS for encryption).
Using Parameter Store for non-sensitive config: The engineer also needs to store the database hostname and port number. These are not secrets, but they need to be available to the application. The engineer creates two parameters in Parameter Store: one for the hostname and one for the port. They tag these parameters with 'Environment=Production' and 'App=OnlineStore'. This helps organise them. They add an IAM policy to the application's role that allows 'ssm:GetParameter' and 'ssm:GetParametersByPath' on the relevant path.
Configuring the application: The development team writes the application code to use the AWS SDK. At startup, the application makes a call to boto3.client('ssm').get_parameter(Name='/app/store/db_host') to get the database host, and a separate call to boto3.client('secretsmanager').get_secret_value(SecretId='prod/online-store/db-cred') to get the database password. The secret value is returned as a JSON string, which the application parses to extract the username and password.
Auditing access: CloudTrail (the AWS service for logging all API activity) automatically records every call to Secrets Manager and Parameter Store. The engineer creates a CloudWatch alarm (a notification rule) that triggers if someone from a different IAM role (like a junior developer) tries to access the production database secret. This gives them immediate visibility of a potential security breach.
Monitoring for compliance: Once a month, the engineer runs a script that checks the 'LastAccessedDate' information on the secret to see which applications are still using the old version of the secret after a rotation. If an application is stuck using an old version, the engineer can investigate why it has not updated.
The result is that the company meets its compliance requirements (PCI DSS for payment card data), its application can be deployed to production without any secrets in the code, and the database passwords change automatically without any human intervention.
The DVA-C02 exam tests your understanding of when to use Secrets Manager versus Parameter Store versus doing something else entirely. It also tests how IAM permissions interact with these services. Here is exactly what you need to know and the traps they set.
Key exam concepts: - Secrets Manager: designed for secrets (passwords, API keys, OAuth tokens) that need automatic rotation. It charges $0.40 per secret per month (plus API call costs). It integrates directly with Amazon RDS, Amazon Redshift, and Amazon DocumentDB for automatic database credential rotation. - Parameter Store: stores any configuration data (strings, strings lists, secure strings). It is cheaper (standard tier is free). It does not have built-in rotation — you must build your own rotation with Lambda if needed. It supports a hierarchical path structure like '/app/prod/db/host' which Secrets Manager does not. - SecureString parameter type: In Parameter Store, you can store a value as SecureString, which means it is encrypted with KMS. The exam expects you to know that SecureString is the appropriate choice for storing a database password in Parameter Store if you are not using Secrets Manager. - IAM permissions: You need the 'secretsmanager:GetSecretValue' and 'kms:Decrypt' permissions for Secrets Manager (if using a customer-managed KMS key). For Parameter Store, you need 'ssm:GetParameter' or 'ssm:GetParametersByPath' and 'kms:Decrypt' for SecureStrings. The exam often shows an error where a developer forgets the 'kms:Decrypt' permission, and the application fails with an access denied error. - Cross-account access: Both services support cross-account access. You can create a resource-based policy on a secret in Account A that allows an IAM role in Account B to read it. This is a common exam scenario for organisations that use multiple AWS accounts.
Common exam traps: - They will describe a scenario where an application needs a configuration value like a database hostname. Many students choose Secrets Manager because it feels 'more secure'. The correct answer is Parameter Store because hostnames are not secrets, and Parameter Store is free and simpler. - They will describe a scenario where the database password is stored in a config file on the EC2 instance, and ask how to make it more secure. A wrong answer might say 'store it in an environment variable'. The correct answer is to use Secrets Manager with an IAM role and remove the config file. - They will give a scenario where the team manually updates a database password and then has to restart all application servers. The correct solution is to use Secrets Manager with automatic rotation, which updates the secret and makes the new value available instantly without restarts. - They will ask about the maximum size of a Parameter Store parameter. The answer is 4KB for standard and 8KB for advanced (4096 and 8192 bytes, respectively). For Secrets Manager, the limit is 65,536 bytes (64KB) — which is much larger. - They will test whether you know that Secrets Manager can create a CloudFormation custom resource to generate a random password. This is a 'secretsmanager:CreateSecret' with a 'GenerateSecretString' parameter.
Key definitions to memorise: - Rotation: The process of automatically replacing a secret with a new one on a scheduled basis. - KMS encryption: Encryption at rest using AWS Key Management Service. Both services encrypt secrets with KMS automatically. - Resource-based policy: A JSON policy attached directly to a secret that defines who can access it (used for cross-account access). - Parameter hierarchy: Using a slash-to separate path segments (like '/app/prod/db/password') to organise parameter store values.
Question patterns: - 'A developer stores a database password in Parameter Store as a String (not SecureString). What happens?' The answer is: the value is stored in plaintext, which is insecure. - 'An application fails to start because it cannot read the database password from Secrets Manager. What is the most likely cause?' The answer: the IAM role attached to the application does not have the 'secretsmanager:GetSecretValue' permission. - 'Which service should you use to store an API key for a third-party service that changes every 90 days?' The answer: Secrets Manager, because it supports automatic rotation.
The exam will also occasionally test the fact that Secrets Manager can be configured to automatically attach a Lambda function for rotation. They will not ask you to write the Lambda function code, but they will expect you to know that a Lambda function is required for custom rotation (non-RDS databases).
Store all database passwords, API keys, and OAuth tokens in AWS Secrets Manager, not in code or config files.
Use AWS Systems Manager Parameter Store for non-secret configuration data like hostnames, ports, and application settings.
Secrets Manager supports automatic rotation of credentials for Amazon RDS, Redshift, and DocumentDB out of the box.
Parameter Store uses a hierarchical path structure (e.g., '/app/prod/db/host') for organising configuration values.
You must grant explicit IAM permissions (secretsmanager:GetSecretValue or ssm:GetParameter) for an application to read a secret or parameter.
For secrets in Parameter Store, always use the SecureString parameter type, which encrypts the value using KMS.
Secrets Manager costs $0.40 per secret per month plus API call charges; Parameter Store standard tier is free.
Both services can be accessed via the AWS Management Console, CLI, and SDKs from any language.
CloudTrail logs every access to Secrets Manager and Parameter Store, enabling full auditing.
Never hardcode secrets in source code — one accidental commit to a public repository can expose your entire infrastructure.
These come up on the exam all the time. Here's how to tell them apart.
Secrets Manager
Built-in automatic rotation for RDS, Redshift, DocumentDB
Cost: $0.40 per secret per month plus API calls
Maximum secret size: 64KB (65,536 bytes)
Parameter Store (SecureString)
No built-in rotation – must build custom Lambda
Cost: Standard tier is free
Maximum parameter size: 4KB (standard) / 8KB (advanced)
Hardcoding Secrets in Code
Secret is visible in source code and version control
Every developer who sees the code has access to the secret
Changing the secret requires a code deployment and restart
Using AWS Secrets Manager
Secret never touches source code
Access is controlled by IAM roles, not code visibility
Secret can be changed instantly without redeploying code
Environment Variables for Secrets
Visible via 'env' command to any user on the server
Often logged in CI/CD pipelines and debug outputs
No audit trail — impossible to see who accessed the value
AWS Secrets Manager
Only accessible to processes with the correct IAM role
Never logged or exposed in plain text
Full CloudTrail audit trail of every access request
IAM Role for Secrets Manager
Temporary credentials rotated automatically by AWS
No long-lived secret to leak or steal
Recommended best practice for applications
IAM User with Long-Term Credentials
Access keys and secret keys are long-lived
If leaked, the user's credentials are compromised until revoked
Should only be used for humans, not applications
Mistake
I can store API keys in environment variables, and that is secure enough because environment variables are not stored in files.
Correct
Environment variables are still stored in the process memory and can be read by other processes running on the same server if the server is compromised. They are also often visible in container images and CI/CD logs. AWS Secrets Manager and Parameter Store store secrets encrypted at rest and only return them over a secure connection to authorised IAM roles.
Environment variables feel invisible in the code, so beginners assume they are hidden. But any user with access to the server can run 'env' or 'printenv' to see them.
Mistake
If I use Parameter Store with a SecureString, I get automatic rotation of my database passwords just like Secrets Manager.
Correct
Parameter Store does not have built-in automatic rotation. You would have to write your own Lambda function to rotate the value, and that Lambda function would need to update the database password and the Parameter Store value. Secrets Manager has built-in rotation for RDS, Redshift, and DocumentDB out of the box.
The word 'SecureString' sounds like it does the same thing as Secrets Manager, but it only encrypts storage, not manage lifecycle.
Mistake
If I store a secret in Secrets Manager, I can access it from any IAM role in my AWS account without any extra configuration.
Correct
Secrets Manager enforces IAM permissions. You must explicitly grant the 'secretsmanager:GetSecretValue' permission to an IAM role before it can read the secret. By default, no one (except the AWS account root user) can access a secret.
Users assume that because a secret exists in their account, they are automatically allowed to read it. They forget that IAM is the gatekeeper.
Mistake
Secrets Manager and Parameter Store are interchangeable — I can use them for the same things interchangeably.
Correct
They are designed for different use cases. Secrets Manager is for secrets that need rotation and are highly sensitive. Parameter Store is for configuration data that does not need rotation or is less sensitive. Using Secrets Manager for a simple configuration value like a hostname is overkill and costs money. Using Parameter Store for a database password without rotation is possible but less secure.
Both are AWS services that store key-value pairs, so beginners think they are the same. The pricing and feature differences are not obvious at first glance.
Mistake
If I hardcode a database password in my configuration file and then just encrypt the file with KMS, it is just as secure as using Secrets Manager.
Correct
Encrypting the file with KMS is better than plaintext, but it still requires the application to have the ability to decrypt the file, which usually means storing the decryption key somewhere. Any process running on the server could potentially read the decrypted file if it is held in memory. Secrets Manager keeps the secret out of the server's file system entirely — a critical security architecture improvement known as 'least privilege'.
Beginners think encryption is a magic bullet. But if the decryption key is on the same server as the encrypted file, an attacker who gains access to the server has both the encrypted file and the key to decrypt it.
Mistake
AWS Secrets Manager can automatically rotate any kind of secret without any additional setup.
Correct
Secrets Manager can automatically rotate database credentials for Amazon RDS, Amazon Redshift, and Amazon DocumentDB out of the box. For any other type of secret (like an API key for a third-party service), you must provide a custom Lambda function that defines how to perform the rotation — for example, calling the third-party API to generate a new key.
The name 'Secrets Manager' implies it manages everything automatically, but the automatic rotation only works with AWS database services. Beginners assume it works for all secrets.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Secrets Manager is for high-sensitivity secrets (passwords, API keys) that need automatic rotation. It costs $0.40 per secret per month. Parameter Store is for configuration data (hostnames, ports) and can also store secrets as SecureString. Parameter Store standard tier is free but does not have built-in rotation.
Yes, but you should store it as a SecureString (encrypted) and you will not get automatic rotation. For a database password that changes frequently, Secrets Manager is the better choice because it handles rotation automatically for RDS databases.
No. Secrets Manager automatically encrypts all secrets at rest using AWS KMS. You can optionally provide your own KMS key (customer-managed key) to have full control over the encryption key, but the default AWS-managed key is free and secure.
The application runs with an IAM role attached. That role has a policy that grants permission to call secretsmanager:GetSecretValue on a specific secret. The application makes an HTTPS API call to Secrets Manager, AWS authenticates the request using the IAM role, and returns the secret value. No long-lived credentials ever touch the server's file system.
You will not be able to decrypt the parameter value. The parameter still exists, but any attempt to read it will fail with a 'kms:Decrypt' access denied error. You would need to create a new parameter with a new value encrypted with a usable KMS key, or restore the KMS key from backup if it was deleted.
Yes. You can attach a resource-based policy to the secret in Secrets Manager that grants access to an IAM role in another account. The application in the other account then assumes that role (or uses a direct cross-account trust) to read the secret. This is common in organisations that separate development, test, and production accounts.
Yes, it is a very common pattern. You create an IAM role for the Lambda function that includes the secretsmanager:GetSecretValue permission. At runtime, the Lambda function calls the Secrets Manager API to retrieve the secret. This means the secret is never in the Lambda deployment package (the zip file you upload).
You've just covered Managing Secrets and Secure Application Configuration — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?