Security and Compliance practice questions

Answer: A) From the management account, designate the security tooling account as the delegated GuardDuty administrator account

The delegated administrator feature lets the management account hand organization-wide GuardDuty management to a member account. This follows least privilege by keeping the management account out of routine security work.

• ACorrect. The management account can make any member account the delegated GuardDuty administrator. That account can then enable and manage GuardDuty for the organization's member accounts, so the management account is not needed for day-to-day GuardDuty work.
• BIncorrect. SCPs only set the maximum permissions available to principals in member accounts. They do not grant permissions, and they cannot make an account the GuardDuty administrator for the organization.
• CIncorrect. Engineers would still be doing their GuardDuty work inside the management account through the assumed role. That defeats the goal of reducing routine use of the management account.
• DIncorrect. This turns GuardDuty on, but each account stays standalone with no central administrator account to manage it. The deployment is also run from the management account.

Answer: A) A boundary is set on an individual IAM user or role; an SCP is attached to the organization root, an OU, or an account and limits all IAM principals in affected member accounts

A permissions boundary caps the maximum permissions of one IAM user or role. An SCP caps the permissions of every IAM principal in the member accounts it affects, including the root user, but not the management account. Neither grants permissions, and when both apply, both must allow the action.

• ACorrect. A permissions boundary is a managed policy set on a specific IAM user or role to cap that entity's maximum permissions. An SCP is attached at the organization root, OU, or account level and limits the IAM users and roles in affected member accounts, including the member account's root user. SCPs do not affect the management account.
• BIncorrect. Neither policy type grants permissions. A permissions boundary limits the user's permissions but does not provide any permissions itself, so an identity-based policy is still needed to grant access.
• CIncorrect. Permissions boundaries are supported only for IAM users and roles, not groups. SCPs have no effect on users or roles in the management account; they affect only member accounts.
• DIncorrect. When both are present, the boundary, the SCP, and the identity-based policy must all allow the action. The effective permissions are the intersection of all three, and an explicit deny in any of them overrides an allow.

Answer: A) All actions on all resources for any principal, with IAM and resource-based policies still applying

If no custom policy is attached, AWS applies a default endpoint policy that allows every principal to perform every action on every resource through the endpoint. Services that don't support endpoint policies also allow full access. IAM and resource-based policies still apply in both cases.

• ACorrect. If no policy is attached, AWS attaches the default policy (Effect Allow, Principal *, Action *, Resource *), which grants full access through the endpoint. An endpoint policy does not override or replace identity-based or resource-based policies, so those still decide what each caller can do.
• BIncorrect. The endpoint is not left in a deny-all state. AWS attaches the default full-access policy when no custom policy is supplied.
• CIncorrect. The default policy uses Principal "*" and is not limited to the endpoint owner's account. To restrict access by account, you must write a custom policy, for example with the aws:PrincipalAccount condition key.
• DIncorrect. The default policy uses Action "*", so it does not limit callers to read-only actions. A read-only limit would need a custom endpoint policy.

Answer: A) Change the parameter to the advanced tier and share it with Account B in an AWS RAM resource share; Account B references it by its full ARN

To share a Parameter Store parameter across accounts, it must be in the advanced tier, and AWS RAM is the recommended sharing method. Consumers get read-only access and must reference the parameter by its full ARN.

• ACorrect. Parameter Store can share only advanced-tier parameters, and AWS RAM is the recommended way to share them. Consumers get read-only access and must give the full parameter ARN to retrieve a parameter from another account. Launch templates are a supported integration for shared parameters.
• BIncorrect. Sharing requires the parameter to be in the advanced tier. A standard-tier parameter can't be shared until it is changed to advanced.
• CIncorrect. Shared parameters don't appear under the consumer's own parameters. The consumer must use the full parameter ARN; the name alone resolves only to a parameter in the consumer's own account.
• DIncorrect. Any form of cross-account sharing, including PutResourcePolicy, applies only to advanced-tier parameters. AWS also recommends AWS RAM over PutResourcePolicy, because a policy-created share must be promoted before it behaves like a standard resource share.

Answer: A) AWS Firewall Manager, with security policies managed from an administrator account

AWS Firewall Manager is the service for centrally defining WAF, Shield Advanced, and security group policies and applying them automatically across an AWS Organization, including new accounts and resources. SCPs limit permissions, and Security Hub and GuardDuty report findings; none of them deploy these protections.

• ACorrect. Firewall Manager centrally manages AWS WAF, Shield Advanced, VPC security groups, network ACLs, Network Firewall, and Route 53 Resolver DNS Firewall across accounts. You set up protections once, and it applies them automatically to new accounts and resources.
• BIncorrect. SCPs set the maximum permissions available to IAM users and roles in member accounts. They can restrict actions, but they don't create or attach WAF web ACLs, Shield Advanced protections, or security group rules.
• CIncorrect. Security Hub collects security findings and runs compliance checks across accounts. It reports on your security posture but doesn't deploy WAF rules, Shield Advanced protections, or security group rules to resources.
• DIncorrect. GuardDuty is a threat detection service that analyzes data sources and produces findings. It doesn't define or apply firewall, WAF, or DDoS protections to resources.

Answer: A) Add an inbound rule for TCP 7000 whose source is the cluster's own security group ID

A security group rule that names its own group as the source lets all current members talk to each other over private IPs. Membership changes are picked up automatically, so no IP list needs maintaining.

• ACorrect. When a security group is the source of a rule, the rule applies to all instances associated with that group, using their private IP addresses. Because the group references itself, instances are covered when they join and stop being covered when they leave, with no IP upkeep.
• BIncorrect. A customer-managed prefix list holds CIDR entries that someone must keep current, so the list would need updating every time Auto Scaling changes the cluster. It also counts against the rule quota at the prefix list's maximum size.
• CIncorrect. This avoids maintenance, but it lets every resource in the VPC reach port 7000. That breaks the requirement that only cluster members can connect.
• DIncorrect. Network ACLs apply to whole subnets, are stateless, and cannot reference security groups. Any resource in the subnet could connect, and return traffic would need its own rules.

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) From the organization's management account, designate the security tooling account as the delegated GuardDuty administrator and configure organization auto-enable

GuardDuty's AWS Organizations integration lets the management account designate a delegated administrator. That account centrally manages findings and protection settings for member accounts and can auto-enable GuardDuty in new ones. AWS recommends this over the legacy invitation method.

• ACorrect. Through the AWS Organizations integration, the management account can designate any account as the delegated GuardDuty administrator. That account can enable and manage GuardDuty for member accounts, review all of their findings, and set auto-enable preferences so new member accounts are covered. AWS recommends this method over invitations.
• BIncorrect. Enabling GuardDuty in the management account does not monitor member accounts. Member accounts must be associated with a GuardDuty administrator account. AWS also advises against making the management account the GuardDuty administrator because it conflicts with least privilege.
• CIncorrect. A Config aggregator collects AWS Config configuration and compliance data. It does not centralize or manage GuardDuty findings, and it cannot enable GuardDuty in new accounts.
• DIncorrect. Analysts would still review findings one account at a time, and every new account would need manual setup. That is the opposite of central management with low overhead.

Answer: A) A custom data identifier with a regex for the format and optional keywords such as "staff number"

To detect an organization-specific pattern, create a Macie custom data identifier based on a regex, optionally refined with keywords. Allow lists exclude matching text from results, and managed identifiers cover only common data types.

• ACorrect. A custom data identifier defines detection criteria using a regular expression, with optional keywords, ignore words and a proximity rule. This adds to the managed identifiers so that discovery jobs report proprietary data such as employee IDs.
• BIncorrect. Allow lists do the opposite: Macie ignores text that matches an allow list and doesn't report it, even if it matches an identifier.
• CIncorrect. Managed data identifiers detect common sensitive data types such as credentials, financial data and national IDs. None of them recognizes one company's proprietary ID format.
• DIncorrect. Severity settings only change how existing findings are rated. They can't make Macie detect a pattern it doesn't recognize.

Answer: A) A Security Hub CSPM custom insight with the grouping attribute and filters defined

Security Hub CSPM custom insights save a grouping attribute and filters as a reusable view of findings. Automation rules, custom actions and EventBridge rules act on findings instead of displaying them.

• ACorrect. A custom insight has a grouping attribute and optional filters and tracks a curated subset of findings. The team can return to it at any time, and it doesn't modify the findings.
• BIncorrect. Automation rules update or suppress findings that match their criteria, for example by changing the severity or workflow status. They don't provide a saved, grouped view for review.
• CIncorrect. A custom action sends selected findings to Amazon EventBridge to trigger a response. It doesn't save a reusable filtered view.
• DIncorrect. An EventBridge rule routes finding events to targets such as Lambda or SNS for automation. It doesn't give a grouped view of findings in the console.