Security practice questions

Use AWS Systems Manager Parameter Store with a SecureString parameter using an AWS managed key

Why wrong: AWS Systems Manager Parameter Store, while capable of securely storing sensitive data using SecureString parameters, does not offer built-in automatic rotation capabilities. Implementing a quarterly rotation for secrets stored here would require developing and managing custom automation scripts and scheduling mechanisms, which falls short of the requirement for an integrated, automatic solution.

Encrypt the environment variables using the Lambda service key

Why wrong: While AWS Lambda encrypts environment variables at rest using an AWS-managed service key, this key is not configurable for customer-scheduled rotation. Furthermore, environment variables are static configuration elements; frequently updating them quarterly would necessitate redeploying or reconfiguring the Lambda function, which is an operationally complex and inefficient method for managing dynamic secret rotation.

Use AWS KMS to encrypt the environment variables and set a manual rotation policy

Why wrong: Encrypting environment variables with AWS KMS provides strong encryption for data at rest, but the proposed manual rotation policy directly contradicts the requirement for *automatic* quarterly rotation. A manual process would require human intervention or external, unscheduled scripting to update the secret, failing to provide the necessary automation. Additionally, environment variables are not designed for the dynamic, frequent updates required for secret rotation.

Condition with aws:SourceArn

Why wrong: The aws:SourceArn condition key is used to restrict access based on the ARN of the AWS resource that is making the request, such as an AWS Lambda function or an EC2 instance. While it can enhance security by ensuring requests originate from expected services, it does not provide a unique identifier for a third-party vendor's specific assumption of a role. It cannot be used to enforce a secret shared between the two accounts for cross-account role assumption.

Condition with aws:SourceAccount

Why wrong: The aws:SourceAccount condition key restricts access to requests originating from a specific AWS account ID. While this can limit access to a known vendor's account, it does not provide a unique, secret identifier that the vendor must present with each role assumption. This means any principal within the vendor's account could potentially assume the role, and it doesn't protect against the "confused deputy" scenario where the vendor's account might be tricked into making an unauthorized request.

Principal element with the vendor's AWS account ID

Why wrong: Simply listing the vendor's AWS account ID in the Principal element of an IAM role's trust policy allows any IAM user or role within that vendor's account to assume the role. This approach lacks a mechanism to verify that the specific request is legitimate and intended by the vendor, as it doesn't require a unique, secret identifier. Without an additional condition like sts:ExternalId, it leaves the access vulnerable to misuse or the "confused deputy" problem within the vendor's own environment.

Create an IAM user with access keys and store the keys in AWS Secrets Manager. Have the application retrieve the keys at runtime.

Why wrong: This approach uses long-term IAM user credentials, which violates the requirement to not use IAM users and to have automatically rotated credentials. While Secrets Manager can rotate IAM user keys, it still involves IAM users.

Use an AWS Lambda function to generate a pre-signed URL that allows access to DynamoDB, and have the EC2 instance use that URL.

Why wrong: Pre-signed URLs are not applicable to DynamoDB. They are used for S3 operations. Even for S3, this approach would require the Lambda function to have credentials, and the EC2 instance would not have direct access to DynamoDB.

Generate a long-lived API token using AWS KMS and embed it in the application code.

Why wrong: Embedding a long-lived API token directly within application code is a severe security anti-pattern, as it creates a static credential that is difficult to rotate and highly susceptible to compromise if the code repository or instance is breached. AWS Key Management Service (KMS) is designed for cryptographic operations like encryption and decryption of data keys, not for generating or managing API access tokens for AWS services like DynamoDB. This approach fails to provide automatically rotated credentials and introduces significant operational and security risks, directly violating best practices for credential management.

The S3 bucket policy in Account A grants s3:GetObject to the IAM role in Account B, and the IAM role in Account B has a trust policy allowing the IAM user to assume it. No KMS key policy is needed because the role can use the key via IAM policies.

Why wrong: For cross-account KMS operations, IAM policies alone are insufficient. The KMS key policy must explicitly grant access to principals from another account. IAM policies in Account A cannot grant access to principals in Account B.

The S3 bucket policy in Account A grants s3:GetObject to the IAM user in Account B, and the IAM user's IAM policy grants s3:GetObject.

Why wrong: This approach is fundamentally flawed because S3 bucket policies cannot directly grant permissions to an IAM user in another AWS account. Instead, cross-account access to S3 resources must be granted to an IAM role in the target account, which the user then assumes. Furthermore, this option neglects the critical requirement for a KMS key policy to grant `kms:Decrypt` permissions, which is necessary if the S3 objects are encrypted with SSE-KMS, making the proposed solution incomplete and insecure.

The S3 bucket uses SSE-C, so the developer must provide the encryption key in the request. No KMS key policy is needed.

Why wrong: This option incorrectly assumes the S3 bucket uses Server-Side Encryption with Customer-Provided Keys (SSE-C). While SSE-C does require the developer to provide the encryption key in the request headers and does not involve AWS KMS, the question context, particularly the presence of other options discussing KMS key policies, strongly implies SSE-KMS is the encryption method in use. If SSE-KMS is indeed used, then a KMS key policy granting `kms:Decrypt` is absolutely necessary for cross-account access, in addition to the S3 bucket policy.

"s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:123456789012:key/abc"

Why wrong: This condition key, "s3:x-amz-server-side-encryption-aws-kms-key-id", is specifically designed to enforce the use of a particular AWS KMS customer master key (CMK) by its Amazon Resource Name (ARN). When included in an S3 bucket policy with a `Deny` effect for `s3:PutObject` actions, it ensures that only objects encrypted with the specified KMS key ID are successfully uploaded. This precisely meets the requirement to mandate a *specific* KMS key for all application logs, providing granular control over encryption key usage.

"s3:x-amz-server-side-encryption": "AES256"

Why wrong: The condition "s3:x-amz-server-side-encryption" with the value "AES256" enforces Server-Side Encryption with S3-managed encryption keys (SSE-S3). While this ensures encryption at rest, it uses keys managed entirely by Amazon S3, not AWS KMS. The question explicitly requires the use of a *specific* AWS KMS key, making SSE-S3 an incorrect choice as it does not involve KMS at all and therefore cannot enforce a particular KMS key.

"kms:EncryptionContext": "service:s3"

Why wrong: The `kms:EncryptionContext` condition key is applicable within an AWS KMS key policy, not an Amazon S3 bucket policy. Its purpose is to control access to a KMS key based on the encryption context provided during encryption or decryption operations, ensuring that the key is only used under specific conditions. It cannot be used within an S3 bucket policy to enforce encryption settings or specific KMS key usage for objects being uploaded to the bucket, as S3 bucket policies utilize S3-specific condition keys.

Store the access key ID and secret access key in environment variables on the EC2 instance.

Why wrong: Storing long-term credentials in environment variables is insecure and violates best practices for credential management.

Use an S3 bucket policy that grants access to the EC2 instance's public IP address.

Why wrong: Bucket policies can grant access based on IP addresses, but this is not secure as IPs can change and it does not use temporary credentials. Additionally, the instance's role is still needed.

Store the credentials in AWS Secrets Manager and have the application retrieve them at startup.

Why wrong: Storing credentials in AWS Secrets Manager still requires the application to retrieve a long-term access key and secret key at startup, which violates the requirement to avoid storing long-term credentials on the instances. This approach is tempting because Secrets Manager is designed for securely rotating and managing secrets, and would be correct if the application needed to authenticate to an external service with a static API key rather than assume an IAM role for S3 access.

A principal of the root user of the other account with s3:GetObject.

Why wrong: This option is incorrect because specifying 'root user' directly as a principal in an S3 bucket policy is syntactically invalid. AWS IAM policies require the principal to be an ARN (Amazon Resource Name) that uniquely identifies the entity, such as 'arn:aws:iam::OTHER-ACCOUNT-ID:root' for the root user. Furthermore, granting only `s3:GetObject` is insufficient for comprehensive read-only access, as it does not allow listing the contents of the bucket.

A principal of any user with a condition for the account ID.

Why wrong: While it is technically possible to use a condition like `aws:PrincipalAccount` with a wildcard principal (`*`) to restrict access to users from a specific account, this approach is generally less direct and more complex for granting blanket cross-account access to an entire account. Specifying the target account's root ARN as the principal is the standard and most straightforward method to grant permissions to all identities within that account, simplifying policy management and clarity.

A principal of the other account's root ARN with s3:ListBucket and s3:GetObject.

Why wrong: This option correctly identifies the necessary permissions (`s3:ListBucket` and `s3:GetObject`) and the correct identifier for the principal (the other account's root ARN). However, the phrasing 'A principal of...' implies a description of the value rather than the complete policy structure. In a JSON policy, the `Principal` element is a key, and its value would be the ARN. This option is structurally incomplete as a policy statement component, missing the explicit `Principal` key.

AWS IAM authorization

Why wrong: AWS IAM authorization leverages AWS Identity and Access Management policies attached to IAM users or roles to control access to AWS resources. While powerful for managing permissions, it does not inherently understand or enforce user group membership defined within an Amazon Cognito User Pool. To achieve group-based access with IAM, one would need complex mappings and policies, making it an indirect and less efficient approach for this specific requirement.

Amazon Cognito User Pool authorizer

Why wrong: The Amazon Cognito User Pool authorizer is purpose-built for validating JSON Web Tokens (JWTs) issued by a Cognito User Pool. It automatically verifies the token's signature, expiration, and issuer, and can be configured directly on API Gateway methods to inspect claims within the JWT, such as the `cognito:groups` claim. This allows for direct and efficient enforcement of user group membership, providing a secure and scalable solution for fine-grained access control based on user groups.

API key

Why wrong: API keys are primarily used for identifying application clients and for metering API usage, often for throttling purposes to protect backend services. They are a simple string value passed in the request header and do not provide any mechanism for user authentication. API keys do not carry information about a user's identity or group membership, and therefore cannot be used to enforce access control based on specific user groups within an application.

aws:RequestedRegion

Why wrong: The aws:RequestedRegion condition key evaluates the specific AWS region where an API request is intended to be executed. While useful for restricting resource access geographically, it has no bearing on the authentication method used by the IAM user. Therefore, it cannot be employed to enforce or verify the presence of Multi-Factor Authentication during user login or subsequent API calls.

aws:SourceIp

Why wrong: The aws:SourceIp condition key evaluates the IP address from which an API request originates. This is valuable for restricting access to AWS resources from trusted networks or specific IP ranges, enhancing network-level security. However, it provides no information about the authentication factors used by the requesting principal, making it unsuitable for enforcing Multi-Factor Authentication.

aws:SecureTransport

Why wrong: The aws:SecureTransport condition key determines whether the request was made over an encrypted connection, specifically using SSL/TLS. While crucial for protecting data in transit from eavesdropping, this condition only addresses the communication channel's security, not the identity verification process of the user. It cannot be used to ascertain if a user has authenticated with Multi-Factor Authentication, as it's unrelated to the authentication mechanism itself.

Store the password in an encrypted Lambda environment variable using a customer-managed AWS KMS key

Why wrong: Storing the database password directly in a Lambda environment variable, encrypted with a customer-managed AWS KMS key, is a highly efficient and secure method. Lambda automatically decrypts these variables at runtime using the specified KMS key, making the secret available to the function code without requiring explicit API calls or additional code for decryption. This approach leverages AWS's built-in encryption capabilities and allows for granular control over the encryption key, including manual rotation, aligning with best practices for sensitive data.

Store the password in AWS Secrets Manager and configure automatic rotation

Why wrong: AWS Secrets Manager is designed for storing and rotating secrets like database passwords, encrypting them at rest with AWS KMS. However, this option fails because the requirement specifies manual rotation of the *customer-managed key*, whereas Secrets Manager's automatic rotation feature applies to the *secret value* itself, not the underlying KMS encryption key. It is tempting because Secrets Manager is the correct service for securely storing such secrets and offers robust secret rotation capabilities, which is ideal for reducing operational overhead in scenarios where automatic secret value rotation is desired.

Store the password in an Amazon S3 configuration file encrypted with server-side encryption

Why wrong: Storing a database password in an Amazon S3 configuration file, even with server-side encryption, is generally not recommended for secrets directly consumed by Lambda functions. This method introduces significant operational overhead and complexity: the Lambda function would need S3 read permissions, code to download the file, parse its contents, and potentially decrypt it if client-side encryption were used. This multi-step process is less secure and less efficient than dedicated secret management services or encrypted environment variables, which are designed for direct secret injection.

iam:CreateUser on the account

Why wrong: The iam:CreateUser permission allows an entity to create new IAM user identities within an AWS account. This action is entirely unrelated to the process of decrypting data using AWS Key Management Service (KMS). Granting this permission would not enable a Lambda function to perform decryption and introduces an unnecessary security privilege that does not address the core requirement.

s3:PutBucketAcl on every bucket

Why wrong: The s3:PutBucketAcl permission grants the ability to modify the Access Control List (ACL) of an Amazon S3 bucket, controlling who has access to the bucket and its objects. Decrypting data encrypted with AWS KMS is a cryptographic operation performed by the KMS service, not an S3 bucket permission. This permission has no bearing on the Lambda function's ability to decrypt data and is irrelevant to the decryption requirement.

Permission for the Lambda execution role to use the KMS key

Why wrong: For a Lambda function to interact with other AWS services like KMS, it assumes an IAM execution role. This role must be explicitly granted the necessary permissions, specifically the kms:Decrypt action, on the target KMS key. The Lambda function's code then operates under the security context of this role, allowing it to successfully call the KMS Decrypt API and retrieve the decrypted data.

Accept any JWT signed with none algorithm

Why wrong: Accepting a JWT signed with the 'none' algorithm is a severe security vulnerability. This algorithm indicates the token has no cryptographic signature, making it trivial for an attacker to tamper with or forge the token's payload without detection. Such a practice would completely undermine the integrity and authenticity guarantees of JWTs, allowing unauthorized access and bypassing all secure authentication mechanisms, which API Gateway's Cognito authorizer would inherently reject.

Trust only the username string sent in a header

Why wrong: Trusting only a username string sent in a header is an inherently insecure method for authentication and authorization. HTTP headers can be easily intercepted, modified, or spoofed by malicious actors, offering no cryptographic proof of the user's identity or the request's authenticity. This approach completely bypasses the robust security mechanisms provided by JWTs and Cognito's authentication flow, making it highly susceptible to impersonation and unauthorized access, and is fundamentally unsuitable for securing API endpoints.

Store production secrets in README files

Why wrong: Storing production secrets directly within README files is a severe security anti-pattern that fundamentally fails to prevent secrets from being committed to source control. README files are integral parts of a repository, meaning any secrets placed there become immediately visible to anyone with access to the codebase. This practice completely undermines the goal of secret management, making credentials highly susceptible to exposure and misuse, rather than protecting them.

Give all developers AdministratorAccess

Why wrong: Granting AdministratorAccess to all developers is a dangerous security practice that violates the principle of least privilege and does not directly address the problem of preventing secrets from being committed to source control. While developers might then have permissions to create or access secrets, this broad access does not inherently stop them from mistakenly embedding credentials in code. Instead, it significantly increases the potential blast radius if a developer's account is compromised, posing a much larger security risk.

Define task definition, then create ECS cluster, then register task definition, then create service

Why wrong: This sequence represents the most logical and standard deployment flow for a containerized application on Amazon ECS. First, the task definition specifies the container images, CPU, memory, and networking requirements, acting as the application's blueprint. Next, an ECS cluster provides the underlying compute capacity (EC2 instances or Fargate) where tasks will run. Registering the task definition makes this blueprint available to the ECS control plane, allowing it to be referenced. Finally, creating an an ECS service ensures that a desired number of tasks based on the registered task definition are continuously run and maintained within the cluster.

Define task definition, then register task definition, then create ECS cluster, then create service

Why wrong: This order is incorrect because although you can register a task definition before creating a cluster, the standard sequence in the AWS documentation often suggests creating the cluster before registering, and the question expects the order: define, create cluster, register, create service.

Define task definition, then create ECS cluster, then create service, then register task definition

Why wrong: This order is fundamentally incorrect because an ECS service requires a registered task definition to function. The service acts as an orchestrator, continuously launching and maintaining tasks based on a specified task definition. Attempting to create a service before the task definition has been formally registered with ECS would fail, as the service would have no valid blueprint to reference for launching containers. The registration step makes the task definition discoverable and usable by ECS services.

Enable versioning on both buckets, then create source and destination S3 buckets, then set up IAM permissions, then configure a replication rule.

Why wrong: Attempting to enable versioning on S3 buckets before they have been created is technically impossible. Versioning is a configuration setting applied to an existing bucket, not a standalone action that can precede resource creation. Therefore, the logical sequence dictates that the buckets must first be provisioned in AWS before any bucket-specific properties like versioning can be enabled or modified.

Configure a replication rule on the source bucket, then create source and destination S3 buckets, then enable versioning, then set up IAM permissions.

Why wrong: Configuring a replication rule as the initial step is incorrect because it has multiple critical dependencies that must be satisfied beforehand. The replication rule requires both the source and destination S3 buckets to already exist, versioning to be enabled on them, and the necessary IAM permissions to be in place. Without these foundational elements, the rule creation would immediately fail validation checks within the S3 service.

Create source and destination S3 buckets, then set up IAM permissions, then configure a replication rule, then enable versioning on both buckets.

Why wrong: While creating buckets and setting IAM permissions are correct initial steps, enabling versioning *after* attempting to configure the replication rule will cause the setup to fail. S3 replication critically depends on versioning being active on both the source and destination buckets to track object states and ensure data integrity during the replication process. Therefore, versioning must be enabled *before* the replication rule is defined and activated.

Create DynamoDB table, then Define scaling policies for read and write, then Create scaling target, then Apply scaling policies

Why wrong: While the DynamoDB table exists, defining scaling policies before creating the scaling target is incorrect. Scaling policies are rules *for* a specific scalable target. The PutScalingPolicy API call requires parameters like ResourceId, ScalableDimension, and ServiceNamespace, which are established and registered when the scaling target is created using RegisterScalableTarget. Therefore, the target must be registered with Application Auto Scaling before any policies can be successfully defined for it.

Define scaling policies, then Create scaling target, then Create DynamoDB table, then Apply scaling policies

Why wrong: This order is fundamentally incorrect because both defining scaling policies and creating a scaling target require an existing DynamoDB table to reference. Application Auto Scaling operations, such as PutScalingPolicy or RegisterScalableTarget, depend on a valid ResourceId (the table's ARN) and ScalableDimension (read/write capacity) which are not available until the table has been provisioned. Attempting these steps prematurely would result in immediate API errors.

Create DynamoDB table, then Create scaling target, then Apply scaling policies, then Define scaling policies

Why wrong: This sequence is illogical and technically invalid because scaling policies must be fully defined with their specific parameters, such as target utilization, minimum, and maximum capacity, before they can be applied or associated with a scaling target. Applying a policy implies referencing an existing, configured set of rules. Attempting to apply a non-existent or undefined policy would lead to an immediate error, as there would be no operational instructions for Application Auto Scaling to enforce.

AWS CodeDeploy: Monitors AWS resources and applications

Why wrong: AWS CodeDeploy's primary function is to orchestrate the deployment of application code, not to observe system performance or application health. While it provides deployment status and lifecycle hooks, it lacks the capabilities for collecting metrics, aggregating logs, or setting up alarms based on operational data. Monitoring resources and applications for performance, errors, and availability is the distinct domain of services like Amazon CloudWatch, which focuses on operational visibility.

Amazon CloudWatch: Automates code deployments to any instance

Why wrong: Amazon CloudWatch is specifically engineered for monitoring and observability, providing insights into the operational health and performance of AWS resources and applications. It does not possess the functionality to automate the deployment of code, manage application revisions, or execute deployment strategies like blue/green or in-place updates. Deployment tasks, such as pushing new code versions to instances or serverless functions, fall under the purview of specialized services like AWS CodeDeploy, which are built for software delivery.

aws iam create-user: launch an EC2 instance

Why wrong: The `aws iam create-user` command is specifically engineered to provision a new Identity and Access Management (IAM) user within an AWS account, establishing a distinct identity for individuals or applications. This user can then be assigned permissions to interact with various AWS services. It is exclusively for identity management and possesses no functionality for launching or managing compute resources like EC2 instances, which falls under the EC2 service API.

aws s3 ls: create an IAM user

Why wrong: The `aws s3 ls` command provides a listing of objects and common prefixes within an Amazon S3 bucket, functioning similarly to a directory listing in a local file system. It is used to enumerate the contents of S3 storage. This command is purely for object storage enumeration and does not have any capability to manage identity resources, such as creating new IAM users, which is handled by the IAM service.

aws ec2 run-instances: list S3 objects

Why wrong: The `aws ec2 run-instances` command is the primary method for initiating and launching new Amazon EC2 virtual machines based on a specified Amazon Machine Image (AMI). It allows for detailed configuration of the instance, including its type, security groups, key pair for SSH access, and user data for bootstrap scripts. This command is exclusively for provisioning compute capacity and does not interact with Amazon S3 for listing storage objects.

Item: A single attribute within a record.

Why wrong: An item in DynamoDB represents a complete, distinct record within a table, similar to a row in a relational database. It is composed of one or more attributes, which are the fundamental data elements. Therefore, stating an item is merely a single attribute is incorrect, as an item encapsulates a full set of attributes that collectively define a unique entity.

Partition Key: The attribute that defines the sort order of items in a table.

Why wrong: The partition key in DynamoDB is crucial for data distribution and retrieval, determining the logical and physical partition where an item is stored. Its primary function is to distribute data across multiple storage nodes to ensure scalability and performance. It does not define the sort order; that role is exclusively handled by the sort key within a composite primary key.

Amazon S3 with server-side encryption

Why wrong: Amazon S3, even when utilizing server-side encryption (SSE-S3, SSE-KMS, or SSE-C), is an object storage service designed for storing files and data objects, not for managing application secrets. While it can store encrypted secret files, it lacks inherent features for secret retrieval by applications, automatic rotation, or versioning specifically tailored for secrets. Access control is at the object level, which is less granular for individual secrets, and it would require extensive custom logic for secret consumption and lifecycle management.

AWS Key Management Service (KMS)

Why wrong: AWS Key Management Service (KMS) is a service primarily designed for creating and managing cryptographic keys (Customer Master Keys - CMKs) used to encrypt data. While KMS is fundamental for encrypting secrets, it does not store the actual secret values itself. A Lambda function would use KMS to encrypt or decrypt a secret, but the secret material would still need to reside in another storage service, and KMS offers no features for secret rotation or direct retrieval of secret values.

AWS Systems Manager Parameter Store

Why wrong: AWS Systems Manager Parameter Store provides secure, hierarchical storage for configuration data and secrets, supporting `SecureString` parameters encrypted by KMS. While it is a viable option for storing secrets, its key limitation for comprehensive secrets management is the absence of built-in automatic rotation capabilities. Implementing secret rotation would require custom automation using other AWS services, increasing operational complexity compared to a dedicated secrets management solution.