Security and Compliance practice questions

Answer: A) Store the credential in AWS Secrets Manager and turn on automatic rotation with a 30-day schedule

Secrets Manager natively rotates database credentials on a schedule, updating both the secret and the database. Parameter Store policies only expire parameters or send notifications, and KMS and ACM rotate keys and certificates, not passwords.

• ACorrect. Secrets Manager rotation updates the credentials in both the secret and the database, either through managed rotation or a rotation Lambda function. Applications that retrieve the secret by name get the current value without code changes.
• BIncorrect. Parameter Store does not provide credential rotation. Parameter policies can set an expiration or send a notification when a parameter has not been changed, but they do not change the password in the database. AWS recommends Secrets Manager when rotation is needed.
• CIncorrect. KMS automatic key rotation replaces the cryptographic material of the KMS key itself. It does not change the database password or update the database user's credentials.
• DIncorrect. AWS Certificate Manager manages and renews SSL/TLS certificates. It does not store or rotate database passwords.

Answer: A) Add a condition that requires the sts:ExternalId value to match the unique identifier the vendor generated and assigned to this company.

For third-party cross-account roles, AWS recommends a trust policy condition on sts:ExternalId with a unique value generated by the vendor. This stops other vendor customers from turning the vendor into a confused deputy.

• ACorrect. The external ID exists to prevent the confused deputy problem. The vendor generates a unique value for each customer and always includes that customer's value when it assumes a role. If another customer submits this role's ARN, the vendor sends that customer's external ID, the condition doesn't match, and the AssumeRole call fails.
• BIncorrect. aws:SourceAccount is meant for cross-service confused deputy protection, when an AWS service principal accesses a resource. Even if it applied here, every request the vendor makes on behalf of any customer comes from the same vendor account, so it couldn't tell this company's requests apart from another customer's.
• CIncorrect. Requiring MFA proves that the vendor's principal authenticated strongly. It doesn't show which customer the vendor is acting for, so a request made for another customer could still pass. It would also break the vendor's automated, unattended role assumption.
• DIncorrect. A shorter session limits how long credentials stay valid. It does nothing to stop the vendor from assuming the role for the wrong customer in the first place, so unauthorized access is still possible during each session.

Answer: A) Attach one policy to all roles with a condition requiring aws:ResourceTag/Department to equal ${aws:PrincipalTag/Department}

ABAC uses tag condition keys, such as aws:ResourceTag matched against ${aws:PrincipalTag/key}, so that one policy grants access when principal and resource tags match. This lets permissions scale to new departments and resources without editing any policy, unlike RBAC policies that list specific resources.

• ACorrect. This is attribute-based access control (ABAC). A single policy allows access when the principal's tag matches the resource's tag. To add a department, you create and tag a role, and the policy stays unchanged. New resources are covered as soon as they are tagged.
• BIncorrect. This is the traditional RBAC model. Each time a department adds a resource, its policy must be updated with the new ARN, and each new department needs its own new policy.
• CIncorrect. Permissions boundaries limit the maximum permissions a principal can have. Listing ARNs in them still requires editing a policy whenever resources or departments change.
• DIncorrect. This only ensures that a Department tag exists on the resource. It does not compare the resource's tag with the principal's tag, so a principal could still manage another department's resources.

Answer: A) Security groups apply at the instance level and are stateful; network ACLs apply at the subnet level and are stateless

Security groups apply at the instance level and are stateful, so return traffic is allowed automatically. Network ACLs apply at the subnet level and are stateless, so return traffic must be allowed explicitly.

• ACorrect. A security group applies to the instances associated with it, and return traffic for allowed connections is permitted automatically. A network ACL applies to every instance in its associated subnets, and return traffic has to be allowed explicitly.
• BIncorrect. The levels are right but the statefulness is reversed. Security groups are stateful, and network ACLs are stateless.
• CIncorrect. The statefulness is right but the levels are reversed. Security groups apply at the instance level, and network ACLs apply at the subnet level.
• DIncorrect. Security groups apply at the instance level. Network ACLs are stateless, so their return traffic must be allowed explicitly.

Answer: A) Attach a policy with a Deny statement that uses NotAction to exempt the MFA self-management actions, with a BoolIfExists condition of aws:MultiFactorAuthPresent set to false

To make IAM users use MFA, add an explicit Deny (Deny + NotAction) that applies when aws:MultiFactorAuthPresent is false or missing (BoolIfExists), and exempt only the MFA self-management actions. Password policies and root user MFA do not enforce MFA for IAM users.

• ACorrect. This is the pattern AWS documents. The Deny + NotAction statement denies every action except the listed MFA-setup actions, and only when the user did not authenticate with MFA. BoolIfExists also treats a missing key, such as with long-term access keys, as non-MFA. Because an explicit Deny overrides the Allows in the users' other policies, this blocks non-MFA sessions.
• BIncorrect. A custom password policy only sets minimum length, character types, expiration, reuse prevention, and whether users can change their own passwords. It has no option to require MFA.
• CIncorrect. A conditional Allow does not take away permissions that the users' other policies already grant without conditions. Only an explicit Deny can block non-MFA sessions that other policies would otherwise allow.
• DIncorrect. Root user MFA protects only the root user's credentials. IAM users are separate identities, and each has its own MFA configuration.

Answer: A) Create a multi-Region primary key in us-east-1 and a replica key in eu-west-1

Multi-Region keys are separate KMS keys in different Regions that share a key ID and key material, so they can decrypt each other's ciphertext locally. Aliases, AWS managed keys and key policies do not change the fact that a single-Region key is tied to one Region.

• ACorrect. Related multi-Region keys share the same key ID and key material, so ciphertext encrypted by the primary key can be decrypted by the replica in another Region. This works without re-encrypting the data or making a cross-Region call to AWS KMS.
• BIncorrect. An alias is just a friendly name for a key in one Region. Two single-Region keys with the same alias still have different key material, so neither can decrypt the other's ciphertext.
• CIncorrect. AWS managed keys are always single-Region keys. Each Region has a separate key with different key material, so data encrypted in us-east-1 cannot be decrypted in eu-west-1.
• DIncorrect. A key policy controls who can use a key, not where the key exists. Decryption would still need a cross-Region call to AWS KMS in us-east-1, which fails during that Region's outage.

Answer: A) Set up AWS Control Tower, use Account Factory to create accounts, and turn on controls for the OUs

AWS Control Tower sets up a best-practice landing zone and provides Account Factory. It applies controls through SCPs/RCPs (preventive), AWS Config rules (detective), and CloudFormation hooks (proactive), and shows compliance on a dashboard.

• ACorrect. Control Tower orchestrates AWS Organizations, IAM Identity Center, and Service Catalog to build a landing zone based on best practices. Account Factory creates standardized accounts. Controls are applied to OUs: preventive controls use SCPs and RCPs, and detective controls use AWS Config rules. The Control Tower dashboard shows noncompliant resources.
• BIncorrect. Organizations provides OUs and SCPs, but it doesn't build a landing zone, the log archive and audit accounts, an account template, detective Config rules, or a compliance dashboard. All of that would have to be built and maintained by hand.
• CIncorrect. Conformance packs only check resource compliance after the fact (detective). They don't create accounts, set up the landing zone's account structure, or enforce preventive SCP-based controls.
• DIncorrect. Service Catalog lets users deploy approved products. On its own it doesn't create the multi-account landing zone or apply SCP and Config rule controls to OUs. Control Tower's Account Factory is built on Service Catalog, but Control Tower handles that orchestration for you.

Answer: A) An AWS Config conformance pack defined in a YAML template

AWS Config conformance packs bundle Config rules and remediation actions in a YAML template. You can deploy the pack as one entity to an account and Region or across an organization.

• ACorrect. A conformance pack is a collection of AWS Config rules and remediation actions. You write it as a YAML template and deploy it as a single entity to an account and Region, or across an organization.
• BIncorrect. An aggregator collects configuration and compliance data from multiple accounts and Regions into one view. It does not package or deploy rules or remediation actions.
• CIncorrect. Automation runbooks can serve as remediation actions, but they do not define or deploy Config rules. Using one per rule would still mean managing each rule separately.
• DIncorrect. SCPs set the maximum permissions available to accounts. They do not evaluate resource compliance or deploy Config rules and remediations.

Answer: A) A customer managed key created in AWS KMS and specified for both the S3 buckets and the RDS instances

Customer managed keys are the only KMS key type that gives the customer full control over the key policy, rotation, enabling and disabling, and deletion. AWS managed keys, AWS owned keys and SSE-S3 keys are all managed by AWS.

• ACorrect. Customer managed keys are KMS keys that you create, own and manage. You control their key policies, IAM policies and grants, enable or disable them, rotate them, and schedule them for deletion. S3 and RDS both let you specify a customer managed key.
• BIncorrect. AWS managed keys are in your account and you can view them, but you cannot change their key policies, change their rotation schedule (AWS rotates them every year), or schedule them for deletion.
• CIncorrect. AWS owned keys are kept in an AWS service account, and that service manages them. You cannot view or change their policies, audit their use, or delete them.
• DIncorrect. With SSE-S3, Amazon S3 manages the keys for you, so you cannot write a key policy or control rotation or deletion. It also applies only to S3 and cannot be used for RDS.

Answer: A) Create a permission set that uses the ReadOnlyAccess AWS managed policy; B) Assign the Auditors group to the 12 production accounts with that permission set

In IAM Identity Center, a permission set defines access, and assigning a group to accounts with that permission set provisions the roles in each account.

• ACorrect. A permission set defines the permissions users get in an account. Identity Center turns it into an IAM role in each account it's assigned to.
• BCorrect. An account assignment links a group, a permission set and accounts. Identity Center provisions the role in each account, and group members see the accounts in the access portal.
• CIncorrect. This is the per-account manual work the company wants to avoid, and it creates long-term credentials.
• DIncorrect. SCPs only limit the maximum permissions in accounts. They never grant access to anyone.
• EIncorrect. Resource policies would have to be added to every resource type and wouldn't give access through the AWS access portal.