Practice Test #10

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.