Practice Test #1

AWS Cost and Usage Reports (CUR) provide detailed billing and usage line items and can be delivered to S3 (often queried with Athena). While CUR can be exported and analyzed, it is not an IAM security/compliance report and does not include per-user MFA status, password change dates, or access key active/inactive state. It also typically requires setup/delivery configuration, which conflicts with the “directly from the console” constraint.

Detailed Billing Reports are billing-focused artifacts (historically associated with detailed cost breakdowns) and are not intended for identity or credential compliance. They do not contain IAM user attributes like MFA enabled, user creation date, password last changed, or access key status. Even if downloadable, they address financial reporting rather than security posture, so they cannot meet the compliance officer’s requested IAM credential details.

AWS Cost Explorer reports help visualize and analyze costs over time and can export cost data. However, Cost Explorer is strictly about spend and usage allocation, not IAM credential hygiene. It cannot report MFA status, password change dates, or access key activation state for IAM users or the root user. Therefore, it does not satisfy the security review reporting requirements.

Rehost (lift-and-shift) moves the application with minimal or no code changes, typically to Amazon EC2 (and possibly a load balancer and managed database). It is chosen for speed and risk reduction, not for redesign. It would keep the Java monolith largely intact and would not achieve decomposition into 12 microservices, independent deployments, or domain-driven boundaries.

Replatform (lift-tinker-and-shift) involves limited changes to gain some cloud benefits (e.g., moving from self-managed middleware to managed services, or adjusting runtime configurations). While you might containerize the monolith or move databases to RDS, replatforming does not imply a major architectural rewrite into multiple microservices with separate deployment lifecycles and CI/CD per service.

Repurchase means replacing the application with a different product, often SaaS (e.g., moving from a custom order system to a commercial platform). This can reduce operational burden but changes business processes and typically does not align with a goal of creating 12 custom microservices in containers. The question states an explicit target architecture rather than adopting a packaged solution.

Avoiding overprovisioning relates to elasticity and right-sizing capacity when demand is uncertain. This is valuable for workloads with variable traffic, but it is primarily a capacity planning/cost optimization benefit. The question’s main challenge is building three different pipeline prototypes quickly with minimal operational burden, not sizing compute resources. You can avoid overprovisioning and still lack the service breadth needed to iterate rapidly.

Expanding into additional geographic Regions is a global infrastructure advantage used for latency reduction, disaster recovery, and regulatory needs. It does not directly help a 6-person team prototype three versions of a real-time processing pipeline in 10 days. Regional expansion can add complexity (data residency, replication, multi-Region failover) rather than accelerate experimentation for an early-stage prototype.

Paying only when resources are consumed is the pay-as-you-go pricing model. It helps avoid upfront commitments and reduces financial risk during prototyping, but it is primarily a billing/pricing benefit rather than the most direct enabler of architectural/process agility. The question focuses on rapidly experimenting with multiple pipeline versions; that is better addressed by the breadth of managed services and rapid provisioning.

Read replicas are primarily intended to offload read traffic and improve read scalability, not to serve as the main high-availability mechanism for AZ outages. In Amazon RDS for PostgreSQL, read replicas typically use asynchronous replication, which means there can be replication lag and potential data loss if the primary fails. Promotion of a read replica is a different operational model from Multi-AZ failover and does not match the standard automatic synchronous standby design described in the question. Read replicas are useful for reporting, analytics, and some disaster recovery scenarios, but not for this exact HA requirement. Therefore, they do not best satisfy the need for synchronous replication and automatic failover across AZs.

Blue/green deployment is a deployment and upgrade feature that creates a separate staging environment so changes can be tested before cutover. Its purpose is to reduce risk during engine upgrades, schema changes, and other planned modifications, not to provide continuous high availability during an AZ outage. Although it can help minimize downtime during planned transitions, it is not the same as maintaining a synchronously replicated standby for automatic failover. The question specifically asks for an always-on standby in another AZ managed by AWS, which is the Multi-AZ pattern. Therefore, blue/green deployment is not the correct feature here.

Reserved Instances are a pricing option that lets customers reduce costs by committing to a usage term, typically one or three years. They do not create a standby database, change replication behavior, or enable automatic failover. Purchasing Reserved Instances has no effect on recovery objectives such as RTO or RPO during an Availability Zone outage. This option addresses billing optimization rather than architecture or resilience. Therefore, it is unrelated to the technical requirement in the question.

AWS Artifact provides on-demand access to AWS compliance reports (e.g., SOC, ISO) and allows acceptance of certain agreements. It helps with audits and compliance evidence, but it does not directly harden the portal’s security posture or produce rapid, actionable technical findings within minutes. It’s valuable for governance, not immediate risk reduction for authentication/authorization.

Granting the broadest permissions to all IAM roles violates the principle of least privilege and directly conflicts with the requirement to avoid wildcard permissions. Overly permissive IAM policies increase blast radius and are a common root cause of security incidents. In exam scenarios, broad permissions are almost never a “security improvement” unless tightly scoped break-glass access is described.

“Running application code with AWS Cloud” is not a specific AWS service or a well-defined security action. If the intent were AWS CloudShell, AWS Lambda, or AWS Cloud9, those still would not be the most direct controls for strengthening portal security under the stated constraints. The question asks for immediate security improvements and rapid checks, which this option does not provide.