Practice Test #10

Not the best choice for least overhead. aws:PrincipalOrgPaths can restrict access based on OU membership, but it introduces additional complexity and potential maintenance if accounts move between OUs or if the OU structure changes. The requirement is simply “within the Organization,” so using Organization ID is simpler and more stable than OU path-based controls.

High operational overhead. CloudTrail-driven automation to detect org membership changes and then rewrite bucket policies is complex, brittle, and unnecessary. It adds moving parts (rules, functions, permissions, error handling) and creates risk of policy drift or delayed enforcement. Native IAM condition keys already provide real-time evaluation without custom automation.

Not aligned with the requirement and increases admin work. Tagging each user (or role) and enforcing aws:PrincipalTag requires consistent tag governance across 25 accounts and ongoing lifecycle management as identities change. It also doesn’t inherently ensure the principal is in the Organization—only that it has a tag—so it’s not the most reliable or minimal-maintenance control for Organization membership.

CloudFormation templates and Systems Manager Automation help standardize provisioning, but they do not prevent users from launching resources through the console/CLI/SDK unless additional restrictive IAM/SCP controls are in place. Enforcing “must use templates” across multiple accounts typically requires ongoing IAM policy engineering, permission boundaries, and exception handling, increasing operational overhead. This is more of a standardization approach than a centralized preventive guardrail.

EventBridge rules with Lambda termination is a detective/reactive control. Expensive instances may run long enough to incur significant cost, and automated termination can disrupt legitimate testing workflows. It also adds operational complexity (rule coverage, edge cases, retries, permissions, multi-region considerations) and can be circumvented if resources are created in ways not captured by events or if termination fails. Preventive controls are preferred here.

Service Catalog can provide pre-approved products and improve governance, but by itself it does not guarantee users cannot provision resources outside the catalog unless you also tightly restrict IAM permissions (often with SCPs anyway). Rolling out portfolios, managing product versions, constraints, and cross-account sharing adds administrative overhead. It is excellent for standardization and self-service, but SCPs are the simplest way to outright prevent costly resource creation.

DynamoDB global tables are a multi-active design, not a single master database architecture. Cross-Region replication is eventually consistent, and conflicts are resolved with last-writer-wins semantics, which is dangerous for financial balances and trade execution records. The requirement explicitly calls for a single master database that maintains global consistency, which global tables do not provide. Although DynamoDB can offer low local latency, it does not satisfy the consistency and single-writer intent of the question.

Amazon RDS for MySQL with cross-Region read replicas also provides a single writer and regional readers, but it is generally less capable than Aurora for this type of globally distributed, latency-sensitive workload. Aurora offers better replication performance, scalability, and managed features than standard RDS MySQL. Since both B and C are similar in architecture, the exam expects the more optimized AWS-native relational choice. Therefore C is not the best answer even though it is closer than the DynamoDB option.

Aurora Serverless is not the right answer because the proposed design relies on custom Lambda-based synchronization across Regions rather than using a native single-master replication model. That introduces unnecessary complexity, operational risk, and potential consistency problems for financial transactions. The option also does not clearly preserve one authoritative writer for all trade records and balances. For exam purposes, custom cross-Region synchronization is almost never preferred over a built-in managed database replication feature.

Using the ro mount option can prevent writes from the OS perspective, but it is not IAM-based and is not a robust security control. A user with sufficient privileges on the instance (or a compromised root process) could remount the file system as read-write. It also requires per-instance configuration and drift management, which reduces operational efficiency and does not meet the stated IAM-based requirement.

An identity-based policy with an explicit Deny on elasticfilesystem:ClientWrite would also block writes for those roles, but it is less operationally efficient and more error-prone at scale than a single EFS resource policy. You must ensure every relevant role has the Deny and that no alternate roles are used. The question emphasizes operational efficiency and centralized integrity controls, which favors a resource-based policy.

EFS access points and POSIX permissions are useful for enforcing directory-level access and consistent UID/GID mapping, but they are not primarily IAM-based controls. POSIX permissions can be misconfigured, and applications might still access the file system through other paths (different access points or direct mounts) if allowed. This option is better as defense-in-depth, not as the primary IAM-based guarantee to prevent all writes.

Incorrect. Amazon GuardDuty is a threat detection service that analyzes logs (e.g., VPC Flow Logs, DNS logs, CloudTrail events) to identify suspicious activity and potential compromise. It does not provide organization-wide compliance standards dashboards for frameworks like PCI DSS or NIST. While GuardDuty supports delegated administration and multi-account management, it is not the primary service for enabling and tracking compliance controls across accounts.

Incorrect. AWS CloudTrail organization trails centralize API activity logging across accounts, which is valuable for auditing and forensics. However, CloudTrail does not have a feature to “enable CloudTrail security standards for NIST and PCI DSS” nor does it provide a compliance controls dashboard. CloudTrail data can feed other services (e.g., Security Hub via findings sources, SIEMs), but it is not itself a compliance posture management solution.

Incorrect. Amazon Inspector is focused on automated vulnerability management (e.g., CVEs, package vulnerabilities, network reachability) for supported compute and container resources across accounts. Although it can be centrally managed with Organizations, it does not provide broad compliance standards enablement and control-by-control posture reporting like Security Hub. Inspector findings can be sent to Security Hub, but Inspector alone will not meet the stated compliance monitoring requirement.

Security groups can only allow/deny based on protocol/port and source IP/CIDR (or other SGs), not by country. Trying to allow only “US IP ranges” would require continuously maintaining large, changing CIDR lists and still would not reliably map to geography. This approach is operationally heavy, error-prone, and not a true geo-based control suitable for compliance.

An ALB security group cannot filter by geographic location. Like all security groups, it supports only IP/CIDR sources, ports, and protocols. There is no native “country” condition in security group rules. Therefore, this option is not technically feasible and would not meet the stated requirement.

Network ACLs operate at Layer 3/4 and can only allow/deny based on IP/CIDR and ports/protocols, not geography. Like security groups, they would require maintaining large IP lists and still would not provide reliable country-based enforcement. NACLs are also stateless, increasing complexity, and they lack the application-layer visibility and logging features that WAF provides.

Incorrect. Creating an IAM user and sharing access keys introduces long-term credentials that can be copied, reused, and are harder to control. Even if you later deactivate keys, you’ve increased exposure during the audit window and violated best practices for third-party access. AWS recommends roles with temporary STS credentials instead of sharing programmatic access keys with external entities.

Incorrect. IAM groups cannot include principals (users/roles) from another AWS account; cross-account “membership” is not supported. Cross-account access is achieved through role assumption (STS) and resource-based policies, not by adding external users to local groups. Time-based controls are typically implemented via role session duration, conditions, or automation—not cross-account group membership.

Incorrect. IAM identity providers are for federation using SAML 2.0 or OIDC, not for trusting an “external AWS account” by providing root credentials. Sharing or using root credentials is explicitly against AWS security best practices. The correct pattern for another AWS account is an IAM role with a trust policy and STS AssumeRole, optionally with ExternalId.

This option keeps the application tier serverless, which is attractive, but Aurora is a relational database service that introduces more database administration considerations than DynamoDB. Aurora Auto Scaling typically refers to scaling read capacity or adjusting database capacity, but it is not the same operational model as DynamoDB on-demand for highly bursty request patterns. The question does not state a need for relational queries or SQL transactions, so Aurora adds complexity without a clear requirement. For an exam question emphasizing minimal operations and unpredictable spikes, DynamoDB is the more aligned choice.

This option uses DynamoDB, which is a good database choice for variable traffic, but the compute layer relies on EC2 instances and Auto Scaling groups. EC2 Auto Scaling still requires infrastructure management such as AMI maintenance, patching, scaling policy tuning, and instance lifecycle handling. It also may not react as quickly as a serverless stack because new instances need time to launch and become healthy behind the load balancer. That makes it less aligned with the requirement for zero infrastructure management overhead and rapid scaling for sudden spikes.

This option is the least aligned because it combines EC2-based infrastructure management with a relational database layer that is not clearly required by the scenario. Although ALB, Auto Scaling, and Aurora can be designed for high availability, they require more operational effort than a serverless architecture. EC2 scaling is generally slower than Lambda-based scaling because instances must boot and register before serving traffic. Aurora may be appropriate for relational workloads, but the question emphasizes elasticity and minimal management rather than relational database features.

Using open-source Python libraries for OCR and PII detection shifts responsibility to the company for accuracy, scaling, patching, and ongoing maintenance. OCR quality on scanned PDFs and varied document layouts can be inconsistent, and building robust PII detection rules/models is non-trivial. This option has higher operational overhead and higher compliance risk because the company must validate and continuously improve detection performance.

Textract is a strong choice for extracting text from PDFs/PNGs, but using SageMaker to identify PII adds significant operational overhead. The team would need to select an algorithm, prepare labeled training data, train/tune models, deploy and scale endpoints, and monitor drift and performance. This contradicts the “least operational overhead” requirement when a managed PII detector (Comprehend) exists.

Rekognition can extract text from images, but it is not the best fit for document-centric OCR, especially for multi-page PDFs and structured financial forms. Textract is purpose-built for document processing and generally provides better results and features (forms/tables). While Comprehend is appropriate for PII detection, the OCR choice increases complexity and may reduce accuracy, making this less optimal than Textract + Comprehend.