CCNA Security Questions — Page 3 of 3

151

MCQmedium

A company stores sensitive documents in an Amazon S3 bucket. The security team requires that all objects uploaded must be encrypted at rest using a specific customer-managed AWS KMS key (key-id: 1234-5678). The developer must enforce this by denying any PutObject request that does not use the correct key. Which S3 bucket policy condition should be used?

A.s3:x-amz-server-side-encryption with value 'aws:kms'

B.s3:x-amz-server-side-encryption-aws-kms-key-id with value 'arn:aws:kms:us-east-1:123456789012:key/1234-5678'

C.s3:x-amz-acl with value 'bucket-owner-full-control'

D.aws:SourceArn with value the bucket ARN

AnswerB

The `s3:x-amz-server-side-encryption-aws-kms-key-id` condition directly enforces the use of a specific AWS KMS key by comparing its ARN against the value provided in the S3 PUT object request header. This precise condition ensures that only objects encrypted with the designated customer-managed key (CMK) are successfully uploaded to the bucket. It provides the granular control necessary to meet strict compliance requirements for sensitive data, ensuring data at rest is secured with an auditable, pre-approved key.

Why this answer

The condition key `s3:x-amz-server-side-encryption-aws-kms-key-id` allows you to enforce that a specific customer-managed AWS KMS key (identified by its full ARN) is used for server-side encryption. By denying PutObject requests that do not match this key ID, the security team ensures all uploaded objects are encrypted at rest with the required KMS key.

Exam trap

The trap here is that candidates often confuse `s3:x-amz-server-side-encryption` (which only checks if SSE-KMS is enabled) with `s3:x-amz-server-side-encryption-aws-kms-key-id` (which checks the specific key ID), leading them to pick Option A, which does not enforce the required customer-managed key.

How to eliminate wrong answers

Option A is wrong because `s3:x-amz-server-side-encryption` with value `aws:kms` only enforces that SSE-KMS is used, but does not restrict which KMS key is used; any KMS key (including default AWS-managed keys) would satisfy the condition. Option C is wrong because `s3:x-amz-acl` with value `bucket-owner-full-control` controls access permissions via ACLs, not encryption requirements, and is irrelevant to enforcing encryption key usage. Option D is wrong because `aws:SourceArn` is used to restrict requests based on the source ARN (e.g., to prevent cross-service confused deputy attacks), not to enforce encryption key selection.

Practice this question →

152

Multi-Selecteasy

Which TWO of the following are best practices for securing AWS account root user?

Select 2 answers

A.Delete the root user access keys.

B.Use the root user for daily administrative tasks.

C.Set a password policy that locks the root user after 10 failed attempts.

D.Share the root user password with senior developers for emergencies.

E.Enable multi-factor authentication (MFA) for the root user.

AnswersA, E

Root user access keys are permanent long-term credentials with unrestricted privileges across the account, including billing and even account closure. They cannot be constrained by IAM policies or permission boundaries, so if they are compromised, the attacker gains full control without any possibility of mitigating the scope. AWS best practice is to never create root access keys, and if they already exist, delete them immediately and rely on password plus MFA for the rare root sign-in.

Why this answer

Deleting root user access keys prevents unauthorized use via programmatic access. Option E is correct: Enabling MFA adds an extra layer of security. Option B is incorrect because the root user should not be used for daily tasks; use IAM users instead.

Option C is incorrect because AWS does not automatically lock the root user after failed attempts. Option D is incorrect because sharing the root user password is a security risk.

Practice this question →

153

MCQhard

A developer is troubleshooting an IAM policy that is supposed to allow a Lambda function to read objects from an S3 bucket. The Lambda function role has the following policy attached: {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:GetObject","s3:ListBucket"],"Resource":["arn:aws:s3:::example-bucket/*","arn:aws:s3:::example-bucket"]}]}. Despite this, the Lambda function receives an AccessDenied error when trying to read objects. What is the most likely cause?

A.The S3 bucket has a bucket policy that explicitly denies the Lambda function's access.

B.The IAM policy does not include the s3:GetObjectVersion action.

C.The Lambda function is in a different AWS account than the S3 bucket.

D.The IAM policy uses an incorrect resource ARN format.

AnswerA

AWS IAM policy evaluation logic dictates that an explicit deny in any applicable policy always overrides an explicit allow. Even if the Lambda function's execution role has an IAM policy granting s3:GetObject access, a bucket policy on the target S3 bucket that explicitly denies access to that specific Lambda role will prevent the action. This creates an effective deny, regardless of the identity-based policy, making it the most probable cause for troubleshooting.

Why this answer

The IAM policy attached to the Lambda function role correctly grants s3:GetObject and s3:ListBucket permissions on the bucket and its objects. However, if the S3 bucket itself has a bucket policy that explicitly denies access to the Lambda function's role, that explicit deny overrides any allow from IAM policies, resulting in an AccessDenied error. This is because AWS evaluates all policies (identity-based and resource-based) and an explicit deny always takes precedence.

Exam trap

The trap here is that candidates often assume the IAM policy alone is sufficient and overlook the possibility of a bucket policy that explicitly denies access, which overrides any IAM allow.

How to eliminate wrong answers

Option B is wrong because the s3:GetObjectVersion action is only needed when accessing a specific version of an object using version ID; the error occurs on a standard read, which only requires s3:GetObject. Option C is wrong because cross-account access would still work if the bucket policy grants access to the Lambda function's role; the error is not inherently caused by being in a different account. Option D is wrong because the resource ARN format is correct: 'arn:aws:s3:::example-bucket/*' for objects and 'arn:aws:s3:::example-bucket' for the bucket itself, which is the standard format for S3 ARNs.

Practice this question →

154

Multi-Selecteasy

Which TWO actions are required to enable server-side encryption for an Amazon RDS instance? (Choose 2)

Select 2 answers

A.Enable encryption on the database after creation

B.Use client-side encryption in the application

C.Configure the DB instance to use a VPC

D.Use AWS KMS to manage the encryption key

E.Specify encryption at rest when creating the DB instance

AnswersD, E

Amazon RDS server-side encryption is built on AWS KMS; you must select a customer master key (CMK) when enabling encryption at rest. The KMS key encrypts the database storage, automated snapshots, and read replicas through envelope encryption, and RDS uses the key to encrypt the data key that protects the volume. Without specifying a KMS key, the encryption option cannot be applied, making KMS key management an essential part of the required configuration.

Why this answer

To enable server-side encryption for an Amazon RDS instance, you must specify encryption at rest when creating the DB instance (Option E) and use AWS KMS to manage the encryption key (Option D). Encryption cannot be enabled after the instance is created (Option A is incorrect). Client-side encryption (Option B) is a separate approach that encrypts data before sending to RDS, not server-side encryption.

Configuring a VPC (Option C) is unrelated to enabling encryption.

Practice this question →

155

MCQmedium

A developer needs to prevent accidental public access to all S3 buckets in an account. Which account-level control should be enabled?

A.S3 Transfer Acceleration

B.S3 Block Public Access

C.S3 Inventory

D.S3 Object Lambda

AnswerB

S3 Block Public Access is the correct and most effective service for preventing accidental public access to S3 buckets and objects across an entire AWS account or specific buckets. It offers four distinct settings that can be applied at the account or bucket level: blocking new public ACLs, ignoring existing public ACLs, blocking new public bucket policies, and blocking public and cross-account access to buckets with public policies. These controls override other access configurations, ensuring strong protection against unintended public exposure.

Why this answer

S3 Block Public Access is an account-level control that provides a centralized way to enforce that no S3 buckets or objects in the account can be made publicly accessible, regardless of individual bucket policies or ACLs. This setting overrides any bucket-level public access settings, effectively preventing accidental exposure of data to the internet.

Exam trap

The trap here is that candidates may confuse bucket-level controls (like bucket policies or ACLs) with account-level controls, or mistakenly think features like Transfer Acceleration or Inventory provide security, when only S3 Block Public Access offers a centralized, account-wide safeguard against public exposure.

How to eliminate wrong answers

Option A is wrong because S3 Transfer Acceleration is a feature that speeds up uploads over long distances using AWS edge locations, not a security control for preventing public access. Option C is wrong because S3 Inventory is used to generate reports on object metadata and replication status for auditing and compliance, not to block public access. Option D is wrong because S3 Object Lambda allows you to add custom code to process data during S3 GET, HEAD, and LIST requests, but it does not provide any access control or public access blocking functionality.

Practice this question →

156

MCQhard

A company uses AWS Secrets Manager to rotate database credentials for an RDS MySQL instance. The rotation Lambda function fails with the error: 'Secret is scheduled for deletion.' What is the MOST likely cause?

A.The secret has been marked for deletion and is in the waiting period.

B.The secret's rotation schedule has been disabled.

C.The Lambda function does not have permission to access the secret.

D.The RDS instance is not in the same VPC as the Lambda function.

AnswerA

When a secret in AWS Secrets Manager is marked for deletion, it enters a configurable waiting period (3 to 30 days) before permanent removal. During this period, the secret is effectively read-only and cannot be modified, including initiating a rotation. Any attempt to rotate a secret in this state will fail, as Secrets Manager prevents operations that would alter a secret designated for deletion, ensuring data integrity before its final removal. This specific state directly causes rotation failures.

Why this answer

The error 'Secret is scheduled for deletion' indicates that the secret has been marked for deletion and is currently in the mandatory waiting period (default 7 to 30 days). During this period, AWS Secrets Manager prevents any operations on the secret, including rotation, to ensure the deletion is intentional. The rotation Lambda function fails because it cannot access or modify a secret that is pending deletion.

Exam trap

The trap here is that candidates may confuse the 'scheduled for deletion' error with a permissions or network issue, but the error message directly points to the secret's lifecycle state, which is a distinct concept in AWS Secrets Manager.

How to eliminate wrong answers

Option B is wrong because disabling the rotation schedule would prevent the Lambda function from being triggered, but it would not cause a 'Secret is scheduled for deletion' error; the secret would still be accessible. Option C is wrong because a permissions issue would result in an 'AccessDeniedException' or similar authorization error, not a deletion-specific error message. Option D is wrong because VPC mismatch would cause a network timeout or connectivity error, not a deletion-related error; the Lambda function would still be able to call the Secrets Manager API if network access is configured.

Practice this question →

157

MCQhard

A company has a multi-account AWS environment using AWS Organizations. The security team wants to enforce that all S3 buckets across all accounts are encrypted using SSE-KMS with a specific KMS key from the central security account. They also want to prevent any unencrypted bucket creation. A developer in the development account creates a new S3 bucket and enables default encryption using SSE-S3. The bucket creation succeeds, but the security team wants to prevent this. The developer argues that the bucket still encrypts data at rest. Compliance requires SSE-KMS only. What should the security team do to enforce this policy across all accounts?

A.Create an IAM policy in the central security account that denies s3:PutBucketEncryption if the encryption is not SSE-KMS.

B.Use AWS Config to detect non-compliant buckets and automatically apply default encryption with SSE-KMS.

C.Enable CloudTrail to log all S3 API calls and manually review for non-compliant buckets.

D.Create a service control policy (SCP) that denies s3:PutObject and s3:PutBucketEncryption unless the encryption is SSE-KMS with the specific KMS key.

AnswerD

Service Control Policies (SCPs) are a feature of AWS Organizations that allow central management of permissions across all accounts in the organization. An SCP can explicitly deny actions like `s3:PutObject` and `s3:PutBucketEncryption` unless specific conditions, such as the use of SSE-KMS with a designated KMS key, are met. This provides proactive, preventative enforcement at the organizational level, ensuring compliance before resources are created or modified.

Why this answer

A service control policy (SCP) applied at the AWS Organizations root or OU level can centrally deny S3 bucket creation and encryption configuration unless SSE-KMS with the specific KMS key is used. SCPs affect all accounts in the organization, preventing developers from bypassing the policy by creating buckets with SSE-S3, as the SCP condition key `s3:x-amz-server-side-encryption` and `s3:x-amz-server-side-encryption-aws-kms-key-id` enforce the required encryption at the API level before the bucket is created.

Exam trap

The trap here is that candidates often confuse IAM policies (which are account-scoped) with SCPs (which are organization-wide), and assume that AWS Config remediation or CloudTrail can proactively enforce encryption, when in fact only SCPs can deny the API call at the point of creation across all accounts.

How to eliminate wrong answers

Option A is wrong because an IAM policy in the central security account only applies to principals in that account, not to developers in other accounts, and cannot prevent bucket creation across the organization. Option B is wrong because AWS Config can detect non-compliant buckets and trigger remediation (e.g., via Lambda), but it is reactive—it does not prevent the initial creation of an unencrypted bucket, which the security team explicitly wants to block. Option C is wrong because CloudTrail logging only provides auditing after the fact, not proactive enforcement; manual review is impractical and does not prevent non-compliant bucket creation.

Practice this question →

158

MCQmedium

A developer is building a serverless application that processes personally identifiable information (PII). The application uses API Gateway, Lambda, and DynamoDB. The developer needs to ensure that the PII is encrypted at rest in DynamoDB. The company already uses AWS KMS with a customer-managed key for other services. The developer wants to reuse the same KMS key for DynamoDB. After enabling encryption with the KMS key, the Lambda function fails to write to the table with an AccessDenied error. The Lambda execution role has dynamodb:PutItem permission. What is the most likely cause?

A.The Lambda execution role lacks kms:Encrypt and kms:Decrypt permissions on the customer-managed KMS key.

B.The Lambda execution role does not have DynamoDB write permissions.

C.The DynamoDB table has a resource-based policy that denies access.

D.The Lambda function is not in a VPC, so it cannot access the KMS key.

AnswerA

The Lambda execution role requires kms:Encrypt and kms:Decrypt permissions on the customer-managed KMS key (CMK) when interacting with a DynamoDB table encrypted with that CMK. Although DynamoDB handles the actual encryption and decryption at rest, it performs these KMS operations on behalf of the calling principal, which is the Lambda function in this scenario. Without these specific KMS permissions granted to its execution role, the Lambda function cannot authorize DynamoDB to use the CMK for data operations, leading to access denied errors when attempting to write or read items.

Why this answer

When a DynamoDB table is encrypted with a customer-managed KMS key, any operation that reads or writes data to the table requires the caller to have permissions to use that KMS key. Even though the Lambda execution role has dynamodb:PutItem permission, the PutItem operation internally triggers KMS Encrypt and Decrypt calls to manage the encryption of the item. Without kms:Encrypt and kms:Decrypt permissions on the specific KMS key, the request fails with an AccessDenied error.

Exam trap

The trap here is that candidates assume DynamoDB's built-in encryption with a KMS key is transparent and does not require additional IAM permissions beyond the DynamoDB actions, but in reality, the caller must have explicit KMS permissions on the key for any read or write operation.

How to eliminate wrong answers

Option B is wrong because the question explicitly states that the Lambda execution role has dynamodb:PutItem permission, so the failure is not due to missing DynamoDB write permissions. Option C is wrong because there is no mention of a resource-based policy on the DynamoDB table, and the error is specifically related to KMS permissions, not a table policy denying access. Option D is wrong because Lambda functions do not need to be in a VPC to access KMS; KMS is a regional service accessible over the public AWS network, and VPC configuration is irrelevant to KMS key access permissions.

Practice this question →

159

MCQeasy

A developer is designing a web application that will run on EC2 instances behind an Application Load Balancer. The application needs to authenticate users. Which service should the developer use to manage user identities and provide single sign-on?

A.AWS IAM

B.Amazon Cognito

C.AWS Directory Service

D.AWS Security Token Service (STS)

AnswerB

Amazon Cognito is the ideal service for managing user identities and authentication for web and mobile applications, offering highly scalable user directories through its User Pools feature. It handles user registration, sign-in, and account recovery, and can integrate with social identity providers or enterprise directories. Cognito provides robust authentication flows and token management, specifically designed for application end-users.

Why this answer

Amazon Cognito is the correct choice because it is a fully managed identity service designed for web and mobile applications. It provides user sign-up, sign-in, and access control, and supports single sign-on (SSO) through federation with social identity providers (e.g., Google, Facebook) and enterprise identity providers via SAML 2.0 or OIDC. This makes it ideal for authenticating users in an application running behind an Application Load Balancer.

Exam trap

The trap here is confusing AWS IAM (for AWS resource access) with a customer-facing identity service, leading candidates to choose IAM for user authentication instead of Cognito.

How to eliminate wrong answers

Option A is wrong because AWS IAM is designed for managing permissions for AWS services and resources, not for authenticating end users of a web application; it lacks built-in user registration, sign-in UI, and SSO federation for external identities. Option C is wrong because AWS Directory Service is primarily for integrating with Microsoft Active Directory or creating managed directories for enterprise workloads, not for providing a simple, scalable user identity store with social login or SSO for web applications. Option D is wrong because AWS Security Token Service (STS) is used to issue temporary security credentials for AWS API requests, not for managing user identities or providing authentication and SSO for application users.

Practice this question →

160

MCQmedium

A developer is creating a web application that uses Amazon Cognito for user authentication. The application needs to verify the identity of users before allowing access to the API. Which Cognito feature should the developer use?

A.User Pools

B.Identity Pools

C.Cognito Sync

D.Cognito Events

AnswerA

Amazon Cognito User Pools serve as a secure, scalable user directory that handles user registration, authentication, and account recovery for web and mobile applications. They manage user identities, issue JSON Web Tokens (JWTs) upon successful authentication, including ID, access, and refresh tokens, which are then used to authorize access to application APIs. This service is the primary component for directly authenticating users into your application, making it the correct choice for managing user sign-in.

Why this answer

Amazon Cognito User Pools provide a fully managed identity and access management service specifically designed for user authentication and authorization in web and mobile applications. They handle user sign-up, sign-in, and identity verification through features like multi-factor authentication (MFA) and JSON Web Token (JWT) issuance, making them the correct choice for verifying user identity before granting API access.

Exam trap

The trap here is confusing Identity Pools (which grant AWS credentials) with User Pools (which authenticate users), leading candidates to select Identity Pools when the question explicitly asks about verifying user identity, not granting AWS resource access.

How to eliminate wrong answers

Option B (Identity Pools) is wrong because Identity Pools are used to exchange user tokens (from a User Pool or other identity provider) for temporary AWS credentials to access AWS services like DynamoDB or S3, not for authenticating users directly. Option C (Cognito Sync) is wrong because Cognito Sync is a deprecated service for synchronizing user profile data across devices, not for identity verification. Option D (Cognito Events) is wrong because Cognito Events are AWS Lambda triggers that run during User Pool operations (e.g., pre-sign-up), but they do not perform user authentication themselves.

Practice this question →

161

MCQeasy

A developer wants to securely store database credentials used by a Lambda function. The credentials should be automatically rotated every 90 days. Which service should be used?

A.AWS Secrets Manager

B.AWS Key Management Service (KMS)

C.AWS Identity and Access Management (IAM)

D.AWS Systems Manager Parameter Store

AnswerA

Secrets Manager is designed for storing secrets with automatic rotation.

Why this answer

AWS Secrets Manager is the correct choice because it is purpose-built for securely storing, retrieving, and automatically rotating database credentials and other secrets. It supports native rotation with built-in integration for Amazon RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB) and Amazon DocumentDB, allowing you to configure automatic rotation every 90 days without custom code. The service encrypts secrets at rest using AWS KMS and enforces fine-grained access control via IAM policies.

Exam trap

The trap here is that candidates often confuse AWS Systems Manager Parameter Store with Secrets Manager because both can store secrets, but Parameter Store lacks native automatic rotation, which is explicitly required by the 90-day rotation requirement in the question.

How to eliminate wrong answers

Option B (AWS KMS) is wrong because it is a key management service for creating and controlling encryption keys, not a secret storage service; it cannot store or rotate database credentials. Option C (IAM) is wrong because it manages users, groups, roles, and permissions for AWS API access, not database credentials; it has no mechanism to store or rotate secrets. Option D (AWS Systems Manager Parameter Store) is wrong because while it can store secrets as SecureString parameters, it does not natively support automatic rotation of credentials; you would need to build a custom rotation solution using Lambda, whereas Secrets Manager provides built-in rotation.

Practice this question →

162

MCQhard

A developer needs to ensure that every cryptographic operation performed on an AWS KMS customer master key (CMK) used for server-side encryption in Amazon S3 is recorded in AWS CloudTrail for auditing. The developer has already enabled CloudTrail and is logging management events. However, the security team wants to see all calls to the KMS Decrypt and Encrypt APIs for this specific key. What must the developer do?

A.Enable CloudTrail data events for the S3 bucket containing the encrypted objects.

B.Create an additional CloudTrail trail that logs all management events for the KMS key.

C.Enable CloudTrail data events for the specific KMS key ARN.

D.Enable CloudTrail Insights events on the existing trail.

AnswerC

CloudTrail data events for KMS record every call to Decrypt, Encrypt, GenerateDataKey, etc. By specifying the key ARN in the data event selector, only operations on that key are logged, meeting the audit requirement without excessive logging.

Why this answer

CloudTrail data events can be configured to log individual API operations (such as Decrypt and Encrypt) on specific KMS keys. By default, CloudTrail management events do not include these data-plane operations; enabling data events for the specific KMS key ARN ensures every cryptographic call is recorded for auditing.

Exam trap

The trap here is that candidates confuse S3 server-side encryption with KMS data events, assuming that logging S3 bucket data events will capture KMS calls, when in fact KMS data-plane operations require explicit data event logging on the KMS key itself.

How to eliminate wrong answers

Option A is wrong because enabling CloudTrail data events for the S3 bucket captures S3 object-level operations (e.g., GetObject, PutObject), not the KMS Decrypt and Encrypt API calls themselves. Option B is wrong because management events already include KMS key management actions (e.g., CreateKey, DisableKey) but not data-plane cryptographic operations; creating another trail with management events does not capture Decrypt/Encrypt. Option D is wrong because CloudTrail Insights events detect unusual API activity patterns but do not log individual Decrypt/Encrypt calls; they are an analysis feature, not a logging configuration for specific API operations.

Practice this question →

163

MCQhard

A company wants to encrypt data at rest in Amazon S3 using server-side encryption with KMS (SSE-KMS). They want to ensure that only certain IAM roles can decrypt objects. What must be configured?

A.IAM role policy to allow kms:Decrypt

B.S3 bucket policy to allow decrypt

C.KMS key policy to allow the IAM roles to decrypt

D.KMS key policy to allow s3.amazonaws.com to decrypt

AnswerC

For an IAM role to successfully decrypt data encrypted with an AWS KMS Customer Managed Key (CMK), the KMS key policy associated with that specific CMK must explicitly allow the IAM role to perform the `kms:Decrypt` action. This is a critical requirement because the key policy is the definitive access control mechanism for the KMS key, dictating which principals are authorized to use it. Without this explicit permission in the key policy, decryption attempts by the IAM role will fail, even if the role's IAM policy permits `kms:Decrypt`.

Why this answer

SSE-KMS uses a customer master key (CMK) to encrypt and decrypt S3 objects. The KMS key policy is the primary access control mechanism for a CMK; it must explicitly grant the IAM roles the kms:Decrypt permission. Without this policy statement, even if the IAM roles have a policy allowing kms:Decrypt, they will be denied access because KMS key policies can override IAM permissions when the key policy does not grant access to the account's IAM principals.

Exam trap

The trap here is that candidates assume an IAM role policy granting kms:Decrypt is sufficient, forgetting that KMS key policies act as an independent access control layer that can explicitly deny or allow access, and without the key policy granting the role, the IAM policy is ineffective.

How to eliminate wrong answers

Option A is wrong because an IAM role policy allowing kms:Decrypt is necessary but not sufficient; the KMS key policy must also grant the role permission to use the key, and if the key policy does not include the role, the IAM policy alone will not allow decryption. Option B is wrong because S3 bucket policies control access to S3 actions (like s3:GetObject) but cannot grant KMS decryption permissions; KMS actions are governed solely by KMS key policies and IAM policies. Option D is wrong because allowing the service principal s3.amazonaws.com to decrypt would grant decryption to any S3 request that uses the key, bypassing the IAM role restriction and violating the requirement that only certain IAM roles can decrypt.

Practice this question →

164

MCQeasy

A company runs an application on Amazon EC2 instances that need to read data from an Amazon DynamoDB table. The developer must grant access to DynamoDB without storing any long-term credentials on the instance. Which approach should the developer use?

A.Store the AWS access key and secret key in a configuration file.

B.Use an IAM role and attach it to the EC2 instance profile.

C.Use an IAM user and store credentials in AWS Secrets Manager.

D.Use the DynamoDB table's resource-based policy to allow the EC2 instance.

AnswerB

Attaching an IAM role to an EC2 instance profile is the recommended and most secure method for granting AWS service access to applications running on EC2 instances. This mechanism provides temporary, automatically rotated credentials to the instance via the EC2 instance metadata service, eliminating the need to store any long-term static credentials on the instance itself. This approach adheres to the principle of least privilege, significantly reducing the attack surface and improving overall security posture by ensuring credentials are short-lived and not directly exposed.

Why this answer

Attaching an IAM role to an EC2 instance profile allows the instance to obtain temporary security credentials from the AWS Security Token Service (STS) via the instance metadata service. This eliminates the need to store long-term credentials on the instance, adhering to the principle of least privilege and improving security posture.

Exam trap

The trap here is that candidates may think resource-based policies (Option D) can grant access to EC2 instances, but DynamoDB resource-based policies only support principals like AWS accounts, IAM users, or IAM roles—not EC2 instances directly—and the correct mechanism for EC2 is always an IAM role attached to the instance profile.

How to eliminate wrong answers

Option A is wrong because storing AWS access keys and secret keys in a configuration file on the EC2 instance introduces long-term static credentials, which violates the requirement to avoid storing long-term credentials and increases the risk of credential leakage. Option C is wrong because using an IAM user and storing credentials in AWS Secrets Manager still requires the EC2 instance to retrieve and use long-term credentials (the IAM user's access keys) at some point, and the instance would need to authenticate to Secrets Manager, typically with another set of credentials, creating a circular dependency; the recommended approach for EC2 is always an IAM role. Option D is wrong because DynamoDB does not support resource-based policies that grant access to EC2 instances directly; resource-based policies in DynamoDB are used for cross-account access or service-to-service authorization, not for granting permissions to compute resources like EC2 instances.

Practice this question →

165

MCQmedium

A developer is creating an IAM policy to allow a Lambda function to write logs to CloudWatch. Which policy should be attached to the Lambda execution role?

A.AWSLambdaBasicExecutionRole

B.AdministratorAccess

C.AmazonDynamoDBFullAccess

D.AmazonS3FullAccess

AnswerA

The AWSLambdaBasicExecutionRole is an AWS managed policy specifically designed to grant a Lambda function the essential permissions required for its operation. This includes the ability to create log groups and log streams in Amazon CloudWatch Logs, and to put log events into those streams. These permissions are fundamental for monitoring function execution, debugging, and ensuring operational visibility, making it the correct and least-privileged choice for basic Lambda functionality.

Why this answer

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.

Exam trap

The trap here is that candidates may mistakenly choose a broad policy like AdministratorAccess or a service-specific policy like AmazonDynamoDBFullAccess, thinking they need to grant 'full' permissions or that the Lambda function might need access to other services, when the question specifically asks only for CloudWatch logging permissions.

How to eliminate wrong answers

Option B (AdministratorAccess) is wrong because it grants full administrative permissions to all AWS services, which violates the principle of least privilege and is overly permissive for a Lambda function that only needs to write logs. Option C (AmazonDynamoDBFullAccess) is wrong because it provides full access to DynamoDB operations but does not include any CloudWatch Logs permissions, so the Lambda function would fail to write logs. Option D (AmazonS3FullAccess) is wrong because it grants full access to S3 buckets and objects but lacks the necessary CloudWatch Logs actions, making it irrelevant for logging purposes.

Practice this question →

166

MCQeasy

A company wants to give a third-party auditor read-only access to their AWS account for compliance purposes. What is the most appropriate way to grant this access?

A.Attach the AdministratorAccess managed policy to an IAM user.

B.Create an IAM role with the SecurityAudit managed policy and allow the auditor to assume it.

C.Create an IAM user with a custom policy that allows all actions.

D.Share the root account credentials with the auditor.

AnswerB

Creating an IAM role with the SecurityAudit managed policy and allowing the auditor to assume it is the correct approach because SecurityAudit grants only read-only access to security-related services and many other AWS services, aligning with the auditor's need to review configurations and logs without making changes. The role uses temporary credentials through AWS STS, so no long-term keys are issued or shared, and access can be scoped with a trust policy that specifies the auditor's AWS account or external identity provider. This follows least privilege and provides a secure, auditable mechanism for third-party access.

Why this answer

An IAM role with the SecurityAudit managed policy provides read-only access to security-related services, allowing the third-party auditor to assume the role and obtain temporary credentials. This follows the principle of least privilege and avoids sharing long-term access keys or root credentials. Option A is wrong because AdministratorAccess grants full administrative privileges, not read-only.

Option C is wrong because a policy allowing all actions also provides full access, not read-only. Option D is wrong because sharing root account credentials is a severe security risk and violates AWS best practices.

Practice this question →

167

MCQeasy

A company has a DynamoDB table that stores personally identifiable information (PII). A developer needs to allow a Lambda function to read and write to this table. What is the MOST secure way to grant the Lambda function access?

A.Create an IAM role with a policy that allows DynamoDB read/write access and attach it to the Lambda function.

B.Use a resource-based policy on the DynamoDB table to allow the Lambda function's IAM role.

C.Create an IAM user with programmatic access and embed the credentials in the Lambda environment variables.

D.Have the Lambda function assume a role using AWS STS each time it runs.

AnswerA

IAM roles are the correct way to grant permissions to Lambda.

Why this answer

An IAM role with an attached policy granting the necessary permissions is the most secure and best practice. Option B is wrong because resource-based policies on DynamoDB are not supported. Option C is wrong because IAM users should not be used for applications.

Option D is wrong because temporary credentials from STS are not needed when using a role.

Practice this question →

168

MCQmedium

A company has an S3 bucket that stores sensitive customer data. The security team requires that all data be encrypted at rest using server-side encryption with AWS KMS. Additionally, they want to enforce that objects are not uploaded without encryption. Which bucket policy should be used?

A.Deny s3:PutObject if the request includes x-amz-server-side-encryption

B.Deny s3:PutObject unless the request includes x-amz-server-side-encryption with value aws:kms

C.Allow s3:PutObject only if the request uses a specific KMS key

D.Deny s3:PutObject unless the request includes x-amz-server-side-encryption with value AES256

AnswerB

This bucket policy statement correctly enforces Server-Side Encryption with AWS KMS (SSE-KMS) for all objects uploaded to the S3 bucket. By using a `Deny` effect with a `StringNotEquals` condition on the `s3:x-amz-server-side-encryption` header, it ensures that any `PutObject` request that does not explicitly specify `aws:kms` for server-side encryption will be rejected. This guarantees that all sensitive customer data at rest is protected by customer-managed or AWS-managed KMS keys.

Why this answer

It uses a Deny effect with a condition that checks for the presence and value of the `x-amz-server-side-encryption` header. This policy explicitly denies any `s3:PutObject` request that does NOT include `x-amz-server-side-encryption` with the value `aws:kms`, thereby enforcing server-side encryption with AWS KMS (SSE-KMS) on all uploads.

Exam trap

The trap here is that candidates often confuse the encryption header values (`aws:kms` vs `AES256`) or mistakenly think that an Allow statement alone can enforce encryption, when in fact a Deny statement with a condition is required to block non-compliant requests.

How to eliminate wrong answers

Option A is wrong because it denies `s3:PutObject` if the request includes the `x-amz-server-side-encryption` header, which would block all encrypted uploads, not enforce them. Option C is wrong because it only allows `s3:PutObject` if a specific KMS key is used, but it does not enforce that encryption is present at all; a request without encryption could still be allowed if no explicit Deny is present. Option D is wrong because it enforces SSE-S3 (AES256) rather than SSE-KMS (aws:kms), which does not meet the requirement for server-side encryption with AWS KMS.

Practice this question →

169

MCQhard

A company uses AWS CloudFormation to deploy resources. The templates are stored in an S3 bucket. A developer wants to ensure that only authorized users can create stacks from these templates. What should be implemented?

A.Use IAM policies to control who can call CreateStack and add S3 bucket policies to restrict template access.

B.Use a stack policy to restrict updates.

C.Enable CloudTrail to log template access.

D.Set the S3 bucket to private and rely on bucket policies.

AnswerA

IAM policies are crucial for controlling which users or roles can invoke the `CreateStack` API action within CloudFormation, directly preventing unauthorized stack deployments. Concurrently, S3 bucket policies restrict access to the CloudFormation template file itself, ensuring only authorized entities can read or download it. This dual-layer approach provides robust preventative security by controlling both the action and the asset, embodying a defense-in-depth strategy.

Why this answer

It combines two layers of access control: IAM policies restrict the ability to call the CreateStack API action, and S3 bucket policies restrict access to the template objects stored in S3. This ensures that even if a user has IAM permissions to create stacks, they cannot retrieve or use the template unless the S3 bucket policy also grants them access. Without both controls, an unauthorized user could bypass IAM by directly accessing the template URL or using a different AWS account.

Exam trap

The trap here is that candidates often assume S3 bucket policies alone are sufficient for access control, forgetting that IAM policies are required to authorize the CreateStack API call itself.

How to eliminate wrong answers

Option B is wrong because stack policies control updates to stack resources after creation, not who can create stacks from templates. Option C is wrong because CloudTrail logs API calls for auditing but does not enforce any access control or authorization. Option D is wrong because setting the S3 bucket to private and relying solely on bucket policies does not prevent an authorized S3 user from creating a stack with the template; it also fails to control the CreateStack API call itself, which is governed by IAM.

Practice this question →

170

MCQhard

A company uses AWS Secrets Manager to store database credentials. The credentials must be automatically rotated every 30 days. The developer needs to configure rotation without exposing the secret to any IAM user directly. Which configuration steps should the developer take?

A.Enable automatic rotation and choose a rotation interval of 30 days. Secrets Manager will automatically rotate the secret using a built-in Lambda function.

B.Create a Lambda function with rotation logic, attach an IAM role with permissions to read and update the secret, and configure Secrets Manager to invoke the function every 30 days.

C.Use AWS Certificate Manager (ACM) to rotate the secret automatically every 30 days.

D.Store the secret in AWS Systems Manager Parameter Store and set a schedule to rotate it using a CloudWatch Events rule.

AnswerB

This is the correct approach for implementing secret rotation with AWS Secrets Manager. To enable automatic rotation, a dedicated AWS Lambda function must be created, containing the specific logic to generate a new secret, update it in the target service (e.g., a database), and then update Secrets Manager. This Lambda function requires an IAM role with precise permissions, including `secretsmanager:GetSecretValue` to retrieve the current secret and `secretsmanager:PutSecretValue` to store the new one, along with permissions to interact with the target resource. Secrets Manager is then configured to invoke this Lambda function on the specified schedule, such as every 30 days.

Why this answer

AWS Secrets Manager does not provide a built-in Lambda function for rotating database credentials; you must create your own Lambda function that contains the rotation logic (e.g., querying the database, creating a new credential, and updating the secret). The Lambda function must be attached to an IAM role with permissions to read and update the secret, and Secrets Manager invokes this function based on the rotation schedule (every 30 days). This ensures the secret is never exposed directly to any IAM user, as only the Lambda function interacts with the secret programmatically.

Exam trap

The trap here is that candidates assume Secrets Manager provides a built-in Lambda function for all secret types, but in reality, you must create your own Lambda function for database credentials, while only AWS-managed secrets (like RDS) have pre-built rotation templates.

How to eliminate wrong answers

Option A is wrong because Secrets Manager does not include a built-in Lambda function for rotating secrets; you must provide your own custom Lambda function with the rotation logic. Option C is wrong because AWS Certificate Manager (ACM) is used for managing SSL/TLS certificates, not for rotating database credentials stored in Secrets Manager. Option D is wrong because AWS Systems Manager Parameter Store does not support automatic rotation of secrets; it is a simple key-value store without built-in rotation capabilities, and using a CloudWatch Events rule would require custom scripting and does not integrate with Secrets Manager's native rotation features.

Practice this question →

171

MCQmedium

A developer is creating a Lambda function that requires access to a DynamoDB table. The function will be invoked by an Amazon API Gateway REST API. What is the BEST way to secure this architecture?

A.Create an IAM role for the Lambda function with a policy granting access to the DynamoDB table.

B.Attach a resource-based policy to the DynamoDB table allowing Lambda access.

C.Use API Gateway to pass a shared secret to Lambda for DynamoDB access.

D.Store the DynamoDB access keys in the Lambda environment variables.

AnswerA

Creating an IAM role for the Lambda function is the standard and most secure method for granting AWS service permissions. This role provides temporary, automatically rotated credentials to the Lambda execution environment, allowing it to assume the specified permissions. By attaching an identity-based policy that grants specific `dynamodb:` actions on the target table, the Lambda function adheres to the principle of least privilege, accessing only what it needs.

Why this answer

The Lambda function needs an execution role—an IAM role that Lambda assumes at runtime—with a policy that grants the specific DynamoDB actions (e.g., GetItem, PutItem) on the target table. This follows the principle of least privilege and is the standard AWS pattern for granting Lambda access to AWS resources. API Gateway invokes the Lambda function via a resource-based policy on the function itself, but that does not affect DynamoDB access; the Lambda execution role handles all downstream permissions.

Exam trap

The trap here is that candidates confuse resource-based policies (used for granting invocation permissions to other AWS accounts or services) with execution roles (used for granting the Lambda function permissions to access other AWS resources), leading them to incorrectly choose Option B or think Option C is a valid authentication method.

How to eliminate wrong answers

Option B is wrong because resource-based policies on DynamoDB tables are not supported; DynamoDB uses IAM policies attached to users, roles, or the table's own resource policy (only for cross-account access via VPC endpoints or AWS Organizations), not for granting access to a Lambda function in the same account. Option C is wrong because passing a shared secret via API Gateway to Lambda for DynamoDB access is insecure and unnecessary; secrets should never be passed through API Gateway payloads, and AWS recommends using IAM roles for service-to-service authentication. Option D is wrong because storing DynamoDB access keys (long-term credentials) in Lambda environment variables violates security best practices—they can be exposed in logs, console, or version history—and AWS strongly recommends using IAM roles with temporary credentials instead.

Practice this question →

172

MCQmedium

A developer is configuring an S3 bucket to host a static website. The bucket policy allows public read access. However, users receive a 403 Forbidden error when accessing the website. What is the most likely cause?

A.The bucket is located in a different AWS region than the website endpoint.

B.The bucket name does not match the domain name.

C.The bucket has 'Block all public access' settings enabled.

D.The bucket is not configured with CloudFront as a content delivery network.

AnswerC

The S3 Block Public Access settings are a powerful security control that overrides any bucket policies or access control lists (ACLs) that might otherwise grant public read access. When 'Block all public access' is enabled, it explicitly prevents anonymous users from accessing objects within the bucket, including static website content. For a static website to be publicly accessible, these settings must be disabled, specifically the 'Block public and cross-account access to buckets and objects' option, allowing the bucket policy to grant public read permissions.

Why this answer

The 'Block all public access' settings in the S3 bucket's Permissions tab override any bucket policy that grants public read access. Even if the bucket policy explicitly allows s3:GetObject for Principal "*", enabling any of the four block public access settings (especially 'Block public access to buckets and objects granted through new public bucket policies' or 'Block public and cross-account access to buckets and objects through any public bucket policies') will cause S3 to reject all anonymous requests, resulting in a 403 Forbidden error when accessing the static website endpoint.

Exam trap

The trap here is that candidates assume a bucket policy granting public read access is sufficient for static website hosting, overlooking that S3's Block Public Access settings act as a separate, overriding permission layer that can silently deny all public access even when the bucket policy is correctly configured.

How to eliminate wrong answers

Option A is wrong because S3 static website hosting endpoints are region-specific (e.g., http://bucket-name.s3-website-us-east-1.amazonaws.com), but the bucket's region does not affect access permissions; a 403 Forbidden error is an authorization issue, not a routing issue. Option B is wrong because while a bucket name must match the domain name for custom domain mapping (e.g., via Route 53), the 403 Forbidden error occurs regardless of domain name mismatch; a mismatch would cause a DNS resolution failure or a different error (e.g., 404 NoSuchBucket), not a 403. Option D is wrong because CloudFront is not required for S3 static website hosting; S3 can serve content directly via its website endpoint, and the absence of CloudFront does not cause a 403 Forbidden error—it would only affect performance, caching, or HTTPS support if not configured.

Practice this question →

173

Multi-Selectmedium

Which TWO actions are recommended to secure an S3 bucket? (Choose 2)

Select 2 answers

A.Block public access at the bucket level

B.Disable versioning to reduce complexity

C.Use HTTP instead of HTTPS for faster access

D.Enable default encryption

E.Grant public read access via ACLs

AnswersA, D

Blocking public access at the bucket level is a key security control that prevents all public access, even if a bucket policy or ACL explicitly grants it. This setting overrides any permissive configuration and acts as a safety net against accidental data leaks, making it a mandatory part of AWS S3 security best practices. By enforcing this at the bucket level, you eliminate the risk of objects being inadvertently exposed to the internet.

Why this answer

Options A and D are correct. A: Block public access is a key security measure. D: Enable default encryption ensures data at rest is encrypted.

B: Disabling versioning reduces data protection and is not recommended for security. C: Using HTTP instead of HTTPS is insecure. E: Granting public read access via ACLs is insecure and should be avoided.

Practice this question →

174

MCQeasy

Refer to the exhibit. A developer attached this bucket policy to an S3 bucket. Users from the 192.0.2.0/24 network can access objects, but users from a different network (203.0.113.0/24) get access denied. What change should be made to allow both networks?

A.Add a new statement with a different Principal.

B.Change the Condition to aws:SourceIp: "203.0.113.0/24".

C.Remove the Condition block entirely.

D.Change the Condition to use a list of IP ranges: ["192.0.2.0/24", "203.0.113.0/24"].

AnswerD

AWS IAM policies support specifying multiple values for a single condition key by using a JSON array. When aws:SourceIp is assigned a list like ["192.0.2.0/24", "203.0.113.0/24"], the condition evaluates to true if the request originates from *any* of the IP ranges within that list. This correctly allows access from both the 192.0.2.0/24 and 203.0.113.0/24 networks, fulfilling the requirement in a single, concise policy statement.

Why this answer

The `aws:SourceIp` condition key accepts a list of IP ranges in an array format. By specifying both `192.0.2.0/24` and `203.0.113.0/24` in the condition, the bucket policy will grant access to requests originating from either network, resolving the access denied error for the second network.

Exam trap

The trap here is that candidates mistakenly think the `aws:SourceIp` condition key can only hold a single value, leading them to choose Option B, when in fact it accepts a list of IP ranges to allow multiple networks.

How to eliminate wrong answers

Option A is wrong because the `Principal` element in an S3 bucket policy specifies the AWS account or IAM entity allowed to access the bucket, not the network IP range; adding a different Principal would not fix the IP-based restriction. Option B is wrong because changing the condition to only `203.0.113.0/24` would deny access to the original `192.0.2.0/24` network, simply swapping which network is blocked. Option C is wrong because removing the `Condition` block entirely would allow all IP addresses to access the bucket, which is overly permissive and violates the principle of least privilege.

Practice this question →

175

MCQmedium

An application running on EC2 needs to access an S3 bucket. The security team wants to avoid using long-term access keys. What is the most secure approach?

A.Generate an access key and secret key for an IAM user and store them on the instance.

B.Create a new IAM user and store the credentials in S3 with bucket policies.

C.Use AWS Systems Manager Parameter Store to store the credentials and retrieve them at runtime.

D.Launch the EC2 instance with an IAM role that grants S3 access.

AnswerD

Launching an EC2 instance with an attached IAM role is the most secure and recommended method for granting AWS resource access. This approach leverages the instance metadata service to provide temporary, frequently rotated credentials to applications running on the instance. These credentials are never stored directly on the instance, eliminating the risk associated with static access keys and simplifying credential management and rotation.

Why this answer

Assigning an IAM role to an EC2 instance allows the instance to obtain temporary security credentials from the AWS Security Token Service (STS) automatically via the instance metadata service. This eliminates the need to store, rotate, or manage long-term access keys, adhering to the security team's requirement for a credential-less approach. The IAM role's permissions policy grants the EC2 instance access to the S3 bucket, and the credentials are automatically rotated by AWS before they expire.

Exam trap

The trap here is that candidates often confuse 'secure storage' (like Parameter Store or Secrets Manager) with 'no long-term credentials at all,' failing to recognize that an IAM role provides temporary credentials that are inherently more secure and require no key management on the instance.

How to eliminate wrong answers

Option A is wrong because storing an access key and secret key on the EC2 instance introduces long-term static credentials that can be compromised if the instance is breached, violating the security team's requirement to avoid long-term access keys. Option B is wrong because storing IAM user credentials in S3 with bucket policies still relies on long-term access keys and adds unnecessary complexity; bucket policies cannot securely protect the credentials themselves from unauthorized access. Option C is wrong because while Systems Manager Parameter Store can securely store secrets, the EC2 instance still needs a mechanism (such as an IAM role) to retrieve them at runtime, and using Parameter Store with long-term credentials stored as parameters does not eliminate the underlying risk of managing static keys.

Practice this question →

176

Multi-Selecthard

A developer is designing a system that stores sensitive user data in DynamoDB. The data must be encrypted at rest and in transit. Which THREE actions should the developer take?

Select 3 answers

A.Enable DynamoDB encryption at rest using an AWS KMS managed key (SSE-KMS).

B.Enable DynamoDB encryption at rest using an AWS KMS customer managed key.

C.Use HTTPS for all API calls to DynamoDB.

D.Use TLS 1.2 for all connections.

E.Implement client-side encryption before writing items to DynamoDB.

AnswersA, B, C

DynamoDB encryption at rest with an AWS managed KMS key (aws/dynamodb) is enabled by default for all new tables, so specifying SSE-KMS with that key provides transparent AES-256 server-side encryption. Because the key is managed by AWS, you cannot control rotation or permissions, but it fully satisfies the at-rest encryption requirement without extra operational overhead.

Why this answer

Options A, B, and C are correct. DynamoDB supports encryption at rest using AWS KMS; both SSE-KMS (A) and customer managed keys (B) provide encrypted storage. Using HTTPS (C) ensures encryption in transit.

Option D is incorrect because DynamoDB already uses TLS 1.2 by default for all connections, so no explicit action is needed. Option E is unnecessary as server-side encryption and HTTPS provide the required protections.

Practice this question →

177

MCQmedium

A company runs an application on Amazon EC2 that needs to securely store database credentials. The security team requires that credentials be automatically rotated every 30 days to reduce the risk of compromise. The application must be able to retrieve the credentials at startup without storing them in code or configuration files. Which AWS service should the developer use?

A.AWS Secrets Manager

B.AWS Systems Manager Parameter Store (SecureString)

C.AWS Key Management Service (KMS)

D.AWS Identity and Access Management (IAM) roles

AnswerA

AWS Secrets Manager is purpose-built for securely storing, managing, and automatically rotating sensitive application secrets, such as database credentials. It integrates directly with services like Amazon RDS to facilitate seamless, scheduled password rotation without requiring manual intervention, significantly enhancing security posture and reducing operational overhead. This capability directly addresses the requirement for automatic rotation.

Why this answer

AWS Secrets Manager is the correct choice because it is specifically designed to securely store, retrieve, and automatically rotate database credentials on a schedule (e.g., every 30 days) without requiring custom code. The application can retrieve credentials at startup via the Secrets Manager API using IAM permissions, eliminating the need to store secrets in code or configuration files. Secrets Manager natively supports automatic rotation for Amazon RDS, Redshift, and DocumentDB, and can be extended to other services via custom Lambda functions.

Exam trap

The trap here is that candidates often confuse AWS Systems Manager Parameter Store (SecureString) with Secrets Manager, overlooking that Parameter Store lacks native automatic rotation, which is a key requirement in the question.

How to eliminate wrong answers

Option B is wrong because AWS Systems Manager Parameter Store (SecureString) can store encrypted secrets but does not natively support automatic rotation of credentials; rotation would require custom automation via AWS Lambda or other services. Option C is wrong because AWS Key Management Service (KMS) is a key management and encryption service that does not store or rotate secrets; it only provides encryption keys for protecting data. Option D is wrong because AWS Identity and Access Management (IAM) roles provide temporary credentials for AWS service access, not for storing or rotating database credentials; they cannot be used to retrieve static secrets like database passwords.

Practice this question →

178

MCQhard

A company has multiple AWS accounts managed under AWS Organizations. The security team requires that all Amazon S3 buckets with bucket names containing 'logs' must be encrypted with a specific KMS key (key ID: alias/logs-key) at rest. A developer must enforce this using an SCP (Service Control Policy). Which SCP effect and condition key should be used to deny any PutObject request that does not use the required KMS key?

A.Deny effect with a Condition: StringNotEquals on s3:x-amz-server-side-encryption-aws-kms-key-id

B.Deny effect with a Condition: StringEquals on s3:x-amz-server-side-encryption

C.Allow effect with a Condition: StringEquals on kms:RequestTag/key-id

D.Deny effect with a Condition: IpAddress on aws:SourceIp

AnswerA

This SCP will deny any PutObject request that specifies a KMS key that is not the required key. The StringNotEquals condition ensures that if the request does not use the specific key ID, the request is denied. This is the standard way to enforce encryption with a specific KMS key using SCPs.

Why this answer

SCPs use a Deny effect to block non-compliant requests. The condition key `s3:x-amz-server-side-encryption-aws-kms-key-id` with `StringNotEquals` ensures that any PutObject request that does not specify the exact KMS key alias/logs-key is denied. This enforces encryption with the required key for all S3 buckets containing 'logs' in their name.

Exam trap

The trap here is that candidates confuse `s3:x-amz-server-side-encryption` (which only checks encryption type) with `s3:x-amz-server-side-encryption-aws-kms-key-id` (which checks the specific KMS key), leading them to choose Option B instead of A.

How to eliminate wrong answers

Option B is wrong because `s3:x-amz-server-side-encryption` only checks whether server-side encryption is enabled (e.g., AES256 or aws:kms), but does not verify the specific KMS key ID, so it cannot enforce the required key. Option C is wrong because Allow effects in SCPs are permissive and cannot deny non-compliant requests; also `kms:RequestTag/key-id` is not a valid condition key for S3 PutObject operations. Option D is wrong because `aws:SourceIp` restricts requests based on IP address, which is unrelated to encryption key enforcement.

Practice this question →

179

MCQmedium

Refer to the exhibit. A developer deploys this CloudFormation template. The Lambda function needs to write objects to an S3 bucket named 'my-app-bucket'. What must the developer add to the template?

A.Add an S3 bucket policy allowing the Lambda function's ARN to write objects.

B.Add a policy statement to LambdaExecutionRole allowing 's3:*' on 'arn:aws:s3:::my-app-bucket'.

C.Add a KMS key policy to allow the Lambda function to use a customer managed key.

D.Add a new policy statement to LambdaExecutionRole allowing 's3:PutObject' on 'arn:aws:s3:::my-app-bucket/*'.

AnswerD

This is the correct solution as it precisely grants the necessary permissions while adhering to the principle of least privilege. Attaching a policy statement to the 'LambdaExecutionRole' is the standard method for providing a Lambda function with permissions to interact with other AWS services. The 's3:PutObject' action is the specific permission required to write objects, and 'arn:aws:s3:::my-app-bucket/*' correctly scopes this permission to all objects within the specified S3 bucket.

Why this answer

The Lambda function requires an IAM policy attached to its execution role to grant permissions for specific S3 actions. The `s3:PutObject` action on the `arn:aws:s3:::my-app-bucket/*` resource ARN precisely allows writing objects to the bucket, following the principle of least privilege. Without this policy statement, the Lambda function will receive an access denied error when trying to write to S3.

Exam trap

The trap here is that candidates often confuse bucket-level ARNs with object-level ARNs, selecting overly permissive options like `s3:*` on the bucket ARN instead of scoping the exact action and resource, or incorrectly assuming an S3 bucket policy is needed for same-account Lambda access.

How to eliminate wrong answers

Option A is wrong because an S3 bucket policy is used to grant cross-account access or public access, not to grant permissions to a Lambda function within the same account; the Lambda function's execution role is the correct mechanism. Option B is wrong because it uses a wildcard `s3:*` action and the bucket-level ARN `arn:aws:s3:::my-app-bucket` instead of the object-level ARN `arn:aws:s3:::my-app-bucket/*`, which is overly permissive and does not correctly scope the `s3:PutObject` permission to objects within the bucket. Option C is wrong because there is no indication that the S3 bucket uses a customer managed KMS key; the question only states the Lambda function needs to write objects, and KMS key policy is only relevant if server-side encryption with KMS is enabled, which is not mentioned.

Practice this question →

180

MCQmedium

A developer is using CloudFront to serve content from an S3 bucket. The bucket contains sensitive data and should only be accessible through CloudFront. How can the developer enforce this?

A.Set the bucket policy to allow access only from CloudFront IP addresses.

B.Set the bucket policy to allow access only from AWS services.

C.Set the bucket policy to allow public read access and use CloudFront signed URLs.

D.Create an origin access identity (OAI) and grant it read access in the bucket policy.

AnswerD

Creating an Origin Access Identity (OAI) and granting it read access in the S3 bucket policy is the recommended and most secure method. The OAI acts as a virtual user for your CloudFront distribution, allowing only that specific distribution to retrieve content from the S3 bucket. This prevents direct public access to the S3 bucket while enabling CloudFront to serve the content securely to end-users.

Why this answer

An Origin Access Identity (OAI) is a special CloudFront user that you can associate with your distribution. By configuring the S3 bucket policy to grant read access only to that OAI, you ensure that content can only be retrieved via CloudFront, not directly from the S3 endpoint. This enforces the requirement that the bucket is accessible exclusively through CloudFront.

Exam trap

The trap here is that candidates often assume restricting by CloudFront IP addresses (Option A) is a valid approach, but AWS explicitly warns that CloudFront IP ranges are not static and should not be used for access control in bucket policies.

How to eliminate wrong answers

Option A is wrong because CloudFront IP addresses are not static and can change over time; using them in a bucket policy would require constant updates and is not a supported or reliable method for restricting access. Option B is wrong because there is no generic 'AWS services' principal in S3 bucket policies; you must specify a specific service principal or user, and this approach would not restrict access to CloudFront only. Option C is wrong because allowing public read access defeats the purpose of restricting access to CloudFront; signed URLs can control who accesses content via CloudFront, but the bucket itself would remain publicly accessible, violating the requirement.

Practice this question →

181

MCQhard

A Lambda function needs to write logs to CloudWatch Logs. The developer attaches an IAM role with a policy that allows logs:CreateLogGroup and logs:PutLogEvents. However, logs are not appearing. What is the most likely cause?

A.The Lambda function is not configured to use a VPC.

B.The IAM role does not have a trust policy that allows Lambda to assume it.

C.The IAM policy does not include logs:CreateLogStream.

D.The CloudWatch Logs log group does not exist.

AnswerC

For a Lambda function to successfully write logs to CloudWatch Logs, its execution role requires specific permissions. While `logs:PutLogEvents` is necessary to transmit the actual log data, the function also crucially needs `logs:CreateLogStream` to establish a new log stream within the designated log group if one does not already exist for that particular invocation or execution environment. Without this `CreateLogStream` permission, the function cannot initialize the required logging infrastructure, leading to a failure in log delivery, even if it possesses the permission to put events.

Why this answer

Lambda requires the `logs:CreateLogStream` permission to create a log stream within a log group before it can write log events. Without this permission, the function can create the log group but cannot create the individual log stream needed to store log entries, causing logs to silently fail to appear.

Exam trap

The trap here is that candidates assume `logs:CreateLogGroup` and `logs:PutLogEvents` are sufficient, overlooking the mandatory `logs:CreateLogStream` permission required for the log stream creation step between group creation and event writing.

How to eliminate wrong answers

Option A is wrong because Lambda functions can write logs to CloudWatch Logs without being in a VPC; VPC configuration affects network access but not log delivery. Option B is wrong because the Lambda function already has an IAM role attached, meaning the trust policy (which allows Lambda to assume the role) was already validated when the role was assigned to the function. Option D is wrong because CloudWatch Logs automatically creates the log group if it does not exist when the Lambda function first invokes, provided the IAM policy includes `logs:CreateLogGroup`.

Practice this question →

182

MCQmedium

A company stores sensitive data in an S3 bucket that must be encrypted at rest. The security team requires that the encryption keys be rotated every 90 days and that access to the keys be auditable. Which solution meets these requirements with the LEAST operational overhead?

A.Use SSE-S3 with default encryption enabled.

B.Use client-side encryption with the AWS Encryption SDK.

C.Use SSE-C with keys stored in AWS Secrets Manager.

D.Use SSE-KMS with a customer managed key and enable automatic key rotation.

AnswerD

KMS automatic rotation meets the 90-day requirement and provides auditing.

Why this answer

SSE-KMS with a customer managed key and automatic key rotation meets the requirements with the least operational overhead. SSE-KMS provides auditable access to keys via AWS CloudTrail, and automatic key rotation satisfies the 90-day rotation requirement without manual intervention. Option A (SSE-S3) is incorrect because S3-managed keys cannot be rotated on a schedule.

Option B (client-side encryption) adds significant operational overhead for key management and rotation. Option C (SSE-C) requires the company to manage and rotate its own encryption keys, increasing complexity.

Practice this question →

183

MCQhard

An S3 bucket policy allows GetObject from another account, but objects encrypted with SSE-KMS still return AccessDenied. Which additional authorization is required?

A.The caller must be allowed to use the KMS key for decrypt operations

B.The caller must own the destination VPC

C.The bucket must enable static website hosting

D.The object key must end with .kms

AnswerA

When an S3 object is encrypted using Server-Side Encryption with AWS KMS (SSE-KMS), the requesting principal requires explicit kms:Decrypt permissions on the associated KMS key. Even if the S3 bucket policy grants s3:GetObject to another account, the cross-account caller cannot retrieve the object's plaintext data without the necessary KMS key usage permissions. This dual authorization ensures robust data protection by separating storage access from encryption key access.

Why this answer

When an S3 object is encrypted with SSE-KMS, the S3 bucket policy granting GetObject access is not sufficient because S3 must also decrypt the object before returning it. The AWS KMS key policy must grant the caller kms:Decrypt permission, and the caller's IAM policy must also allow kms:Decrypt on the specific KMS key. Without this additional KMS authorization, S3 returns AccessDenied even if the bucket policy allows GetObject.

Exam trap

The trap here is that candidates assume a bucket policy granting s3:GetObject is sufficient for all objects, forgetting that SSE-KMS adds a separate authorization layer via KMS key policies that must explicitly allow the decrypt operation.

How to eliminate wrong answers

Option B is wrong because VPC ownership is irrelevant to S3 object access; S3 bucket policies and KMS permissions control cross-account access, not network ownership. Option C is wrong because static website hosting is a feature for serving public content and has no bearing on KMS-encrypted object access or cross-account authorization. Option D is wrong because the object key suffix has no effect on KMS authorization; SSE-KMS encryption is determined by the object's encryption settings, not its filename.

Practice this question →

184

Multi-Selecteasy

Which TWO are features of AWS Identity and Access Management (IAM)? (Choose 2)

Select 2 answers

A.Encrypt S3 objects automatically

B.Monitor network traffic

C.Define fine-grained permissions with policies

D.Manage EC2 instance lifecycle

E.Create and manage IAM users and groups

AnswersC, E

IAM policies are the core mechanism for defining fine-grained permissions. You can craft JSON-based identity policies that specify exactly which actions are allowed or denied on which resources, under what conditions (e.g., source IP, MFA presence, time of day). This allows least-privilege access control at the resource and API-action level, central to IAM's purpose.

Why this answer

Options C and E are correct. IAM allows you to define fine-grained permissions using policies (C) and create and manage users and groups (E). Option A is incorrect because encrypting S3 objects is a feature of S3, not IAM.

Option B is incorrect because monitoring network traffic is typically done by VPC flow logs or CloudTrail, not IAM. Option D is incorrect because managing EC2 instance lifecycle is an EC2 function, not IAM.

Practice this question →

185

Multi-Selectmedium

Which THREE components are required to enable encryption in transit for an Application Load Balancer? (Choose THREE.)

Select 3 answers

A.A security group rule allowing inbound traffic on port 443

B.An SSL/TLS certificate from ACM or uploaded to IAM

C.A listener configured on port 443 with the certificate

D.Server Name Indication (SNI) support

E.An HTTP to HTTPS redirect rule

AnswersA, B, C

To enable encryption, the Application Load Balancer (ALB) must be able to receive incoming encrypted traffic from clients. A security group rule allowing inbound traffic on port 443 (HTTPS) is fundamental, as it acts as a virtual firewall, explicitly permitting the necessary TLS communication to reach the ALB. Without this rule, client connections attempting to establish an encrypted session would be blocked at the network layer, preventing any encryption from occurring.

Why this answer

A security group rule allowing inbound traffic on port 443 is required because the Application Load Balancer (ALB) must accept HTTPS traffic from clients. Without this rule, the ALB's network interface will drop encrypted connections, preventing any TLS handshake from completing. This ensures that traffic between clients and the ALB is encrypted in transit.

Exam trap

The trap here is that candidates often confuse optional features like SNI or redirect rules as mandatory requirements, when in fact only the security group rule, the certificate, and the listener on port 443 are strictly necessary for encryption in transit.

Practice this question →

186

MCQeasy

A developer is using the AWS CLI to upload a file to an S3 bucket with server-side encryption. The bucket is configured with default encryption (SSE-S3). The developer wants to ensure the object is encrypted with SSE-KMS instead. What should the developer do?

A.Use the --kms-key-id parameter with a KMS key ARN

B.Use the --sse aws:kms parameter when uploading

C.No action needed; the bucket default encryption will apply

D.Change the bucket policy to require SSE-KMS

AnswerB

This is the correct action. To ensure a file is encrypted with Server-Side Encryption with AWS KMS (SSE-KMS) during an AWS CLI upload, the --sse aws:kms parameter must be explicitly specified. This parameter instructs S3 to use KMS for encryption. If a specific KMS key is desired, it can be combined with the --kms-key-id parameter; otherwise, S3 will use the default AWS managed key for S3 in the account.

Why this answer

The developer must explicitly specify the server-side encryption method at the time of upload using the `--sse aws:kms` parameter in the AWS CLI. This overrides the bucket's default SSE-S3 encryption, ensuring the object is encrypted with SSE-KMS. Without this parameter, the object inherits the bucket's default encryption (SSE-S3), regardless of any other settings.

Exam trap

The trap here is that candidates assume bucket default encryption always applies to all objects, but in reality, request-level encryption parameters take precedence over bucket defaults, and the developer must explicitly specify SSE-KMS to override SSE-S3.

How to eliminate wrong answers

Option A is wrong because the `--kms-key-id` parameter is used to specify a specific KMS key ARN when SSE-KMS is already selected, but it does not enable SSE-KMS by itself; the `--sse aws:kms` parameter must also be provided. Option C is wrong because the bucket's default encryption (SSE-S3) will apply automatically, which does not meet the developer's requirement for SSE-KMS; the default is not overridden without explicit request-level parameters. Option D is wrong because changing the bucket policy to require SSE-KMS only enforces that objects must be encrypted with SSE-KMS at the bucket level, but the developer still needs to specify `--sse aws:kms` in the upload command to comply with that policy and achieve the desired encryption.

Practice this question →