Security practice questions

Answer: A) The rule allows traffic from whatever instances are associated with the referenced group, so it stays valid when their private IP addresses change.

When a rule names a security group as the source, it allows traffic from the private IPs of whatever instances belong to that group right now. The rule keeps working as instances scale in, scale out, or get replaced.

• ACorrect. When a security group is the source, the rule applies to all instances associated with that group and allows traffic from their private IP addresses. You don't need to edit the rule when instances are replaced or get new IPs.
• BIncorrect. AWS docs state that no rules from the referenced security group are added to the security group that references it.
• CIncorrect. Security group referencing works with the private IP addresses of the associated instances' network interfaces, not their public or Elastic IP addresses.
• DIncorrect. Security groups support only allow rules, whatever the source type. You can't write deny rules in a security group.

Answer: A) Write the new value to the primary secret in us-east-1, because the replica can't be updated independently of its primary and receives the change through replication

A Secrets Manager replica can't be updated independently of its primary, except for its encryption key, so normal updates go to the primary and propagate to the replicas. Only promoting the replica with StopReplicationToReplica, called from the replica Region, makes it an independent standalone secret.

• ACorrect. A replica secret has the same value and metadata as its primary and can't be updated independently, except for its KMS encryption key. Changes made to the primary secret, including rotated values, propagate to the replicas.
• BIncorrect. Replication only goes from the primary to its replicas. A replica can't be updated independently, so there is no write path that syncs a change back to the primary.
• CIncorrect. When rotation is turned on for the primary, Secrets Manager rotates the secret in the primary Region and the new value propagates to the replicas. To turn on rotation for a replica itself, you must first promote it to a standalone secret, which disconnects it from the primary.
• DIncorrect. StopReplicationToReplica must be called from the replica's Region, and it promotes the replica to a standalone secret. After that, changes to the primary no longer replicate to it, and the secrets are not relinked automatically. Promotion is meant for scenarios such as disaster recovery, not routine updates.

Answer: A) Deactivate the exposed key, issue a new key to legitimate workloads, and review CloudTrail for calls made with the old key

A leaked long-term access key stays usable by anyone until it is revoked. The right response is to deactivate and replace the key and then use CloudTrail to investigate what the key was used for. Editing or hiding the repository doesn't remove the exposure.

• AAnyone who has the key has the same access as the IAM user, and long-term keys stay valid until they are manually revoked. Deactivating the key stops misuse right away. A replacement key keeps legitimate workloads running, and CloudTrail shows what was done with the key while it was exposed. Delete the old key after confirming it is no longer needed.
• BGit history and any existing clones or forks still contain the key, which may already have been copied. The key stays valid until it is revoked, so hiding the file doesn't remove the exposure.
• CProgrammatic requests signed with the access key don't need the console password. Enabling MFA doesn't block access-key calls unless policies specifically require MFA. The exposed key would remain usable.
• DThe plaintext key is still in the commit history and still valid. Encrypting a future copy does nothing about the credential that was already exposed, so it must be deactivated and replaced.

Answer: A) Set the user pool's MFA enforcement to Required and enable the SMS message and authenticator app (TOTP) methods

Setting user pool MFA to Required, with the SMS and TOTP methods enabled, makes every user present a second factor after the password. Threat protection, identity pools, and token lifetimes don't enforce this on every sign-in.

• AWith MFA set to Required, every user must complete an additional SMS, email, or TOTP code on each sign-in. Enabling the SMS and authenticator app methods matches the factors in the requirement.
• BAudit-only mode just monitors activity, assigns risk levels, and publishes logs and metrics. Even in full-function mode, adaptive authentication requires MFA only for risky sign-ins, not for every sign-in.
• CAn identity pool exchanges user pool tokens for temporary AWS credentials. It doesn't add another authentication factor to the user pool sign-in.
• DA shorter token lifetime only makes users sign in more often with the same single factor. It never asks for a code from an authenticator app or SMS message.

Answer: A) Any principal allowed to read the function's configuration can see the key in clear text, and the value can also show up in deployment templates or tooling output.

Lambda environment variables are encrypted at rest, but with the default key anyone who can read the function configuration sees them in clear text, and they can leak through deployment artifacts. For credentials, AWS recommends Secrets Manager (or at least client-side encryption with a customer managed key).

• AWith the default AWS managed key, no extra KMS permissions are needed to view environment variables. Anyone who can read the function configuration sees the value decrypted, and values defined in IaC or CI/CD pipelines can show up in templates and output. AWS recommends Secrets Manager for credentials like this.
• BLambda always encrypts environment variables at rest with an AWS KMS key and uses an AWS managed key by default. A customer managed key is optional and adds control over the key; it isn't required for encryption at rest.
• CLambda doesn't log environment variable values automatically. Values reach CloudWatch Logs only if the function code prints them.
• DNeither users nor the execution role need KMS permissions to use the default encryption key. The execution role needs kms:Decrypt only when encryption helpers are used for client-side encryption.

Answer: A) The statement applies to objects in every S3 bucket the account can access, not just a specific bucket or prefix

• AA wildcard Resource means the permission isn't scoped to a specific bucket/prefix — broadening it far beyond least privilege, since it would apply to any matching S3 resource in scope, not one particular bucket.
• BIAM doesn't automatically reject a wildcard Resource — it will actually grant broadly scoped access exactly as written, which is why using it carelessly is a real security risk, not a syntax error.
• CA wildcard Resource is meaningfully evaluated by IAM and does grant broad access — it isn't simply ignored.
• DA bare wildcard doesn't scope access to "only objects I uploaded" — that kind of restriction requires a specific condition or resource pattern, not a plain wildcard.

Answer: A) Set a custom password policy on the user pool with minimum length, required character types, and the number of previous passwords to block

Cognito user pool password policies natively set minimum length and required character types. With the Essentials or Plus feature plan, they can also block reuse of up to 24 passwords in total (the current one plus 23 earlier ones).

• ACorrect. A custom user pool password policy sets the minimum length and the required character types (numbers, special characters, uppercase, lowercase). On the Essentials or Plus plan, 'Prevent use of previous passwords' blocks reuse of the current password plus up to 23 earlier ones. No custom code is needed.
• BIncorrect. Identity pools exchange identities for temporary AWS credentials. They don't store or validate user passwords. The password policy is a user pool setting.
• CIncorrect. The IAM account password policy applies only to IAM users in the AWS account. It has no effect on users in a Cognito user pool.
• DIncorrect. This means writing and maintaining custom code and storage for something the user pool password policy already supports, so it is not the least development effort.

Answer: A) Assign a distinct IAM role to each user pool group, and set the identity pool's authenticated role selection to Choose role from token

Linking an IAM role to each Cognito user pool group and setting the identity pool to choose the role from the token gives each group its own permissions. Group roles travel in the ID token's cognito:roles and cognito:preferred_role claims.

• AEach user pool group can be linked to an IAM role. Those roles are passed in the ID token's cognito:roles and cognito:preferred_role claims. When the identity pool uses Choose role from token, it issues credentials for the role that matches the user's group.
• BUser pool groups don't hold IAM policies; a group is linked to an IAM role through its ARN. If the identity pool keeps only its default authenticated role, every authenticated user receives that same role.
• COAuth scopes in access tokens authorize access to resource servers such as APIs. The identity pool doesn't use scopes to choose an IAM role for temporary credentials.
• DThe unauthenticated role applies to guest users who haven't signed in, and an identity pool has only one. It can't tell authenticated users apart by group membership.

Answer: A) Detecting whether delivered log files were modified or deleted by checking signed digest files

CloudTrail log file integrity validation delivers hourly digest files containing SHA-256 hashes, signed with RSA, so you can later prove whether log files were changed or deleted after delivery. It doesn't encrypt logs or prevent deletion.

• AOnce validation is enabled, CloudTrail hashes each log file with SHA-256 and delivers an hourly digest file signed with SHA-256 with RSA. You can then validate the files (for example, with the AWS CLI) to find out whether they were modified, deleted or left unchanged after delivery.
• BSSE-KMS encryption is a separate trail setting. Log files are already encrypted with SSE-S3 when SSE-KMS isn't enabled. Integrity validation is about tamper detection, not encryption.
• CIntegrity validation detects changes or deletions but does not prevent them. Preventing deletion requires S3 controls such as bucket policies, MFA Delete or Object Lock.
• DValidation works after delivery against the delivered log and digest files. Enabling the setting only causes digest files to be delivered; you run the validation separately.

Answer: A) With SSE-KMS, using the AWS managed key for Amazon S3 (aws/s3) in the account

When a pipeline is created with the console wizard, CodePipeline encrypts artifacts with SSE-KMS using the AWS managed aws/s3 key. You can choose a customer managed key instead, and a cross-account pipeline requires one.

• ACorrect. The wizard creates the artifact bucket, and CodePipeline uses server-side encryption with AWS KMS and the AWS managed key for Amazon S3 (alias aws/s3). The same SSE-KMS process decrypts artifacts when they are retrieved.
• BIncorrect. CodePipeline's default is SSE-KMS with the aws/s3 AWS managed key, not SSE-S3. The documented example bucket policy even denies uploads that don't request aws:kms encryption.
• CIncorrect. A customer managed key is optional (for example, for scheduled rotation or cross-account pipelines). Without one, the wizard's default still encrypts artifacts with the AWS managed key.
• DIncorrect. CodePipeline relies on Amazon S3 server-side encryption with AWS KMS. It does not encrypt artifacts client-side with keys kept in Secrets Manager.