DVA-C02 Flashcards — Free AWS Certified Developer Associate DVA-C02 Study Cards

Increase the batch size to 100.

Increasing the batch size to 100 allows each Lambda invocation to process up to 100 messages from the SQS queue instead of the current 10. Since the function is idempotent and can handle 100 messages per invocation, this change maximizes the number of messages processed per invocation without altering the reserved concurrency of 5. With a batch size of 100, each of the 5 concurrent invocations can process up to 100 messages, yielding a potential throughput of 500 messages per invocation cycle, which directly reduces the backlog and throttling by consuming messages faster.

The Lambda function does not have kms:Decrypt permission on the KMS key used by the bucket.

When an S3 bucket uses SSE-KMS, the Lambda function must have explicit kms:Decrypt permission on the KMS key to decrypt the object after s3:GetObject retrieves the encrypted data. Even though the bucket policy and execution role allow s3:GetObject, the missing KMS permission causes an Access Denied error because S3 returns the encrypted object and the Lambda runtime cannot decrypt it without the key.

Modify the blue/green deployment configuration to use the same database endpoint for both task sets by updating the environment variables in the task definition before deployment.

Option A is correct because the issue stems from the green task set using a different database endpoint than the blue task set, which is configured via environment variables in the ECS task definition. By updating the task definition to use the same database endpoint before deployment, both task sets will connect to the same database, ensuring consistency during the traffic shift. This is the simplest fix as it requires no additional infrastructure or complex routing changes.

Increase the read and write capacity units on the DynamoDB table

The primary cause of the throttling is insufficient DynamoDB capacity to handle the request volume from the Lambda function. Increasing the read and write capacity units (RCUs/WCUs) directly addresses the throttle events by providing more throughput to match the function's concurrency of 100. This is the most effective solution because it resolves the bottleneck at the data store level without reducing the application's ability to process requests concurrently.

Increase the function's memory

Increasing the function's memory is the correct first step because Lambda allocates CPU proportionally to memory, and more CPU reduces processing time for CPU-bound tasks like decompressing or parsing large files. This directly addresses the timeout by making the function complete faster, without requiring code changes. The current 128 MB setting is the minimum, which provides the least CPU, so even a modest increase can significantly reduce execution time.

Temporary credentials from the instance profile role

Option D is correct because the AWS SDK on EC2 automatically retrieves temporary credentials from the instance metadata service (IMDS) at http://169.254.169.254/latest/meta-data/iam/security-credentials/. These credentials are provided by the IAM role attached to the EC2 instance (the instance profile role) and are rotated automatically, eliminating the need to store long-term credentials on the instance.

An IAM role with a trust policy that allows the external account's root user or specific IAM users/roles to assume the role

Option A is correct because cross-account IAM role access requires a trust policy attached to the role in the developer's account. This trust policy specifies the external AWS account ID (or specific IAM users/roles in that account) as the principal, allowing them to call sts:AssumeRole. Once the role is assumed, the developer's account grants the necessary S3 permissions via the role's permissions policy.

The bucket policy in Account A grants s3:GetObject to the role, the KMS key policy grants kms:Decrypt to the role, and the role in Account B has an IAM policy allowing s3:GetObject and kms:Decrypt

Option A is correct because cross-account access to an SSE-KMS encrypted S3 bucket requires three layers of permissions: the bucket policy in Account A must grant s3:GetObject to the IAM role in Account B, the KMS key policy must grant kms:Decrypt to the same role, and the role's IAM policy in Account B must allow both s3:GetObject and kms:Decrypt. Without any one of these, the request will fail due to either an S3 authorization error or a KMS decryption failure.

JWT authorizer configured for the issuer and audience

Option C is correct because an HTTP API Gateway with an external OIDC provider requires a JWT authorizer. The JWT authorizer validates the token's signature, issuer, and audience against the OIDC provider's configuration, ensuring only authenticated users gain access. This is the native AWS mechanism for integrating third-party OIDC identity providers like Auth0 or Okta.

Create an IAM role with the required permissions and attach it to the EC2 instance.

The best practice for granting an EC2 instance permissions to access DynamoDB is to create an IAM role with the required permissions and attach it to the instance. This eliminates the need to manage long-term credentials, as the instance automatically retrieves temporary security credentials from the instance metadata service (IMDS) via the AWS Security Token Service (STS). This approach follows the principle of least privilege and ensures credentials are rotated automatically.

Create an IAM execution role with an S3 access policy and attach it to the Lambda function.

Option A is the correct answer. The best practice for granting an AWS Lambda function access to an S3 bucket in the same account is to create an IAM execution role with a policy that allows the necessary S3 actions, and then attach that role to the Lambda function. This provides temporary credentials via STS, follows the principle of least privilege, and avoids hardcoding credentials. Option B is incorrect because storing AWS credentials in environment variables is insecure and can lead to accidental exposure. AWS recommends using IAM roles for temporary credentials. Option C is incorrect because Lambda functions do not support attaching IAM policies directly. Policies must be attached to an IAM role, and that role is assigned to the function. Option D is incorrect because while a bucket policy could grant access based on the function's ARN, it is not the best approach for same-account access. Using an execution role is more scalable, easier to manage, and follows the principle of least privilege.

The user's IAM user policy does not explicitly allow the required S3 action

When granting cross-account access to an S3 bucket, both the bucket policy (resource-based policy) and the user's IAM policy (identity-based policy) must explicitly allow the action. The bucket policy alone is insufficient if the user's IAM policy does not include an explicit Allow for the S3 action, because IAM denies by default. Even though the bucket policy grants access, the user's own IAM policy must also permit the operation for the request to succeed.

Multi-factor authentication (MFA) was not used when assuming the role.

The CloudTrail log entry shows that the `sts:AssumeRole` API call was made without the `aws:MultiFactorAuthPresent` key set to `true`. This indicates that the role was assumed without MFA, which violates the security best practice of requiring MFA for privileged role assumptions. The absence of MFA increases the risk of unauthorized access if the user's credentials are compromised.

AWS Secrets Manager

Option A is correct because AWS Secrets Manager is specifically designed for secure storage and automatic rotation of database credentials. Option B (Systems Manager Parameter Store) can store secrets but lacks native automatic rotation capabilities, making it less suitable for this use case. Option C (S3 with server-side encryption) is not a dedicated secrets store and would require additional access control management. Option D (DynamoDB) is a NoSQL database, not a secret management service, and would require custom encryption and rotation logic.

The VPC endpoint policy does not allow the required S3 action for the principal

The correct answer is A because the VPC endpoint policy is an additional layer of access control that can explicitly deny actions even if the bucket policy allows them. If the endpoint policy does not grant the required S3 action (e.g., s3:GetObject) for the IAM principal (the EC2 instance's role), requests will be denied regardless of the bucket policy. This is a common misconfiguration where developers focus only on the bucket policy and overlook the endpoint policy.

Create an IAM policy that denies codecommit:GitPush unless the commit is signed.

Option C is correct because AWS CodeCommit does not natively support a 'require signed commits' toggle in the repository settings. Instead, you must use an IAM policy with a condition key like `codecommit:referencedRefName` and a custom condition (e.g., using the `git` protocol's signed commit metadata) to deny `codecommit:GitPush` actions when the commit is not signed. This is the only way to enforce GPG signing at the AWS service level.

The S3 bucket policy does not grant access to the IAM role

The most likely cause is that the S3 bucket policy in the second account does not explicitly grant the IAM role from the first account (or the second account's own IAM role) the necessary permissions. When an IAM role is used, both the role's trust policy and the resource-based policy (S3 bucket policy) must allow the action; if the bucket policy denies or omits the role's ARN, access will be denied even if the role itself has S3 permissions.

Increase the timeout setting of the Lambda function

The Lambda function is timing out because its default execution timeout (3 seconds) is too short for the HTTP requests to the external API. Increasing the timeout setting allows the function to wait longer for the API response, resolving the timeout without modifying the code. This is a configuration change in the Lambda function settings, not a code change.

AWSLambdaBasicExecutionRole

The AWSLambdaBasicExecutionRole managed policy grants permissions for Lambda to write logs to CloudWatch Logs, specifically allowing the logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents actions. This is the minimal set of permissions required for a Lambda function to send execution logs to CloudWatch, making it the correct choice for this use case.

Create a custom IAM policy with specific DynamoDB actions (e.g., GetItem, PutItem) on the specific table and attach it to the Lambda execution role.

Option D is correct because it adheres to the principle of least privilege by granting only the specific DynamoDB actions (e.g., GetItem, PutItem) required by the Lambda function, scoped to the exact table. The Lambda execution role is an IAM role that the Lambda service assumes, and attaching a custom policy with fine-grained permissions ensures minimal access. This approach avoids over-permissioning and follows AWS security best practices for serverless applications.

The role in Account B must have an IAM policy that allows the S3 actions.

Option B is correct because cross-account S3 access requires both a resource-based policy (the bucket policy in Account A) that grants access to the role ARN, and an identity-based policy (an IAM policy attached to the role in Account B) that explicitly allows the S3 actions. Without the IAM policy in Account B, the role lacks permission to perform the S3 operations, even though the bucket policy permits the access. This is a fundamental principle of AWS cross-account authorization: both the resource side and the principal side must grant the necessary permissions.

Use the default HTTPS endpoint provided by API Gateway.

Option C is correct because API Gateway REST APIs automatically provide an HTTPS endpoint using TLS for data in transit encryption. This default endpoint uses an Amazon-issued certificate, ensuring encryption between clients and API Gateway without any additional configuration. The developer only needs to use the default HTTPS URL provided by API Gateway to satisfy the requirement.