Questions d'entraînement

Question 1

A global media subscription service plans to launch a stateless customer dashboard on Amazon EC2 in ap-southeast-2 across three Availability Zones, requiring 99.9% availability with Auto Scaling from 6 to 120 instances when average CPU > 60% for 5 minutes, and to implement an active-passive disaster recovery environment in ap-northeast-1 with an RTO of 10 minutes and Route 53 health checks (30-second interval, fail after 2 consecutive failures) while serving traffic only from ap-southeast-2 during normal operations. Which solution will meet these requirements?

Analyse de la question

Core Concept: This question tests multi-Region high availability and disaster recovery (DR) design for a stateless EC2 web tier using Application Load Balancers, Auto Scaling, and Amazon Route 53 DNS failover with health checks. It also implicitly tests service scoping: ALBs and Auto Scaling groups are Regional, and cannot span Regions/VPCs the way some options suggest. Why the Answer is Correct: Option C implements an active-passive DR pattern: ap-southeast-2 serves all traffic during normal operations (primary), while ap-northeast-1 is provisioned and ready (secondary) but receives traffic only upon failure. Route 53 failover routing with health checks ensures DNS answers switch to the secondary when the primary endpoint becomes unhealthy. The specified health check settings (30-second interval, fail after 2 consecutive failures) align with the requirement, and a 60-second TTL helps meet the 10-minute RTO by reducing DNS caching delay. The primary Region uses an ALB across three AZs and an Auto Scaling group with min 6/max 120 and scaling on average CPU > 60% for 5 minutes, meeting the scaling and 99.9% availability goals. Key AWS Features: - ALB is Regional and can span multiple AZs within a Region, improving resilience. - EC2 Auto Scaling across multiple AZs provides elasticity and AZ fault tolerance. - Route 53 failover routing policy supports primary/secondary records with health checks. - Health check interval and failure threshold determine detection time; TTL influences client-side DNS caching and therefore effective failover time. Common Misconceptions: A and D assume an ALB can “extend” across VPCs/Regions and that a single Auto Scaling group can launch instances across both Regions/VPCs. In reality, ALBs and ASGs are scoped to a single Region (and an ALB is associated with subnets in that Region). VPC peering also does not enable a single ALB to target instances in another Region. B sounds close but does not enforce active-passive behavior; “health checks on both records” is ambiguous and could result in active-active (e.g., weighted/multivalue) or unintended traffic distribution. Exam Tips: - Remember Regional boundaries: ALB, ASG, and subnets are Regional; Route 53 is global. - For active-passive DR with Route 53, look for “failover routing policy” with explicit primary/secondary and health checks. - RTO depends on detection time + DNS TTL + provisioning readiness; keeping the secondary stack warm and TTL low improves RTO.

Question 2

A logistics company is deploying a fleet of 2,500 autonomous warehouse robots that each push 8 KB of telemetry every second to AWS over Wi-Fi, and it needs a data platform that provides near-real-time (<=3 seconds) analytics on the inbound stream, ensures durable, ordered, highly parallel ingestion with the ability to reprocess data, and delivers processed results to a data warehouse for BI; which strategy should a solutions architect use to meet these requirements?

Question 3

An independent cybersecurity auditing firm that operates under an AWS Organizations organization named blueOrg (orgA) must programmatically access a customer’s AWS account that belongs to a separate organization named greenOrg (orgB) to run an automated compliance scanner from the firm’s management account every 4 hours that reads only EC2 Describe*, IAM Get*, and S3 List* metadata using temporary credentials and least privilege. What is the MOST secure way to enable orgA to access resources in orgB via API/CLI?

Analyse de la question

Core Concept: This question tests secure cross-account access across separate AWS Organizations using AWS STS AssumeRole, least-privilege IAM roles, and the confused deputy protection mechanism (ExternalId). It also implicitly tests best practices: avoid long-term credentials, use temporary credentials, and tightly scope trust and permissions. Why the Answer is Correct: Option D is the most secure pattern for a third-party auditor accessing a customer account programmatically. The customer creates an IAM role in orgB (customer account) with only the required read-only permissions (EC2 Describe*, IAM Get*, S3 List*). The role’s trust policy allows assumption by the auditor’s AWS account in orgA, but only when the auditor supplies a unique ExternalId. The auditor then calls sts:AssumeRole from its management account every 4 hours to obtain short-lived credentials. This satisfies temporary credentials, least privilege, and strong protection against unauthorized role assumption. Key AWS Features: 1) IAM Role + Trust Policy: The trust policy specifies the principal (auditor account) and conditions (sts:ExternalId). Optionally, the customer can further restrict with aws:PrincipalArn to a specific role in the auditor account. 2) AWS STS Temporary Credentials: AssumeRole returns time-bound credentials, reducing blast radius and eliminating key rotation burdens. 3) Confused Deputy Mitigation: ExternalId is the AWS-recommended control when a third party accesses customer accounts, preventing the auditor from being tricked into using its permissions to access other customers’ roles. 4) Least Privilege Permissions Policy: Limit actions to ec2:Describe*, iam:Get*, s3:List* and scope resources where possible (not all actions support resource-level constraints). Common Misconceptions: Option C (role without ExternalId) is better than users/keys, but it omits a key third-party security control and is not the “MOST secure” for an independent firm scenario. Options A and B rely on long-term credentials, which violates best practices and increases risk of leakage and misuse. Exam Tips: When you see “third-party access,” “temporary credentials,” and “least privilege,” think: customer creates IAM role, auditor assumes via STS. If it’s a vendor/independent auditor, add ExternalId in the trust policy. Avoid sharing access keys. This aligns with AWS IAM guidance and Well-Architected Security Pillar principles (identity foundation, least privilege, and credential management).

Question 4

A national retail chain ingests 4 TB per day of point-of-sale (POS) event logs from 2,500 stores; the logs are compacted hourly into Parquet files and stored in the Hadoop Distributed File System (HDFS) on a long-running Amazon EMR cluster, and business analysts run interactive SQL using Apache Trino (Presto) on the same EMR cluster; each query scans hundreds of gigabytes, completes in under 12 minutes, and queries are executed only between 6:00 PM and 11:00 PM local time on weekdays with up to 6 concurrent users, and the company is concerned about the high cost of the always-on cluster but still needs the most cost-effective way to continue running SQL queries with minimal operational overhead. Which solution will meet these requirements?

Question 5

(Sélectionnez 2)

A solutions architect is designing an application for 1,200 retail store managers to submit weekly customer feedback forms from their mobile devices, with approximately 80% of the 6,000 peak submissions per minute occurring between 5:00 PM and 9:00 PM on Sundays, and the data must be stored in a format that allows business analysts to run region-level monthly dashboards while the infrastructure remains highly available and scales elastically for both ingestion and analytics with minimal operational overhead; which combination of steps meets these requirements? (Choose two.)

Analyse de la question

Core Concept: This question tests designing a highly available, elastically scaling, low-ops ingestion layer for spiky mobile submissions and a scalable analytics layer for monthly, region-level dashboards. The key patterns are serverless ingestion (API Gateway + Lambda) and data lake analytics (S3 + Athena + QuickSight). Why the Answer is Correct: Option C provides a fully managed, multi-AZ, automatically scaling front end and API tier. Hosting the static front end on Amazon S3 behind CloudFront offloads web serving and improves global performance. Using Amazon API Gateway with AWS Lambda proxy integration removes server management and scales rapidly to handle the Sunday evening surge (up to 6,000 submissions/min) without pre-provisioning. This meets “highly available,” “scales elastically,” and “minimal operational overhead.” Option E stores submissions in Amazon S3, which is highly durable and cost-effective for long-term retention. Business analysts can query data directly with Amazon Athena (serverless SQL over S3) and build monthly region-level dashboards in Amazon QuickSight. This combination scales for analytics without managing clusters, aligns with a data lake approach, and supports partitioning by date/region to optimize monthly dashboard queries. Key AWS Features: API Gateway throttling/usage plans, Lambda concurrency scaling, CloudFront caching and TLS, S3 lifecycle policies, S3 partitioned prefixes (e.g., region=.../year=.../month=...), Athena Glue Data Catalog schemas, and QuickSight SPICE for dashboard performance. These are Well-Architected (Operational Excellence, Reliability, Performance Efficiency, Cost Optimization) aligned choices. Common Misconceptions: EC2/ECS with scheduled scaling (A/B) can handle predictable peaks, but they still require capacity planning, patching, and operational management, and may not respond as seamlessly to variability within the 5–9 PM window. Redshift (D) is powerful for warehousing but introduces cluster management/cost and is not “minimal ops” for intermittent ingestion/analytics unless carefully designed. Exam Tips: When you see “spiky traffic,” “high availability,” and “minimal operational overhead,” strongly consider serverless (S3/CloudFront, API Gateway, Lambda). For “dashboards from stored data” with low ops, prefer S3 + Athena + QuickSight over managing a data warehouse unless complex joins/low-latency BI at scale explicitly require Redshift.

Envie de vous entraîner partout ?

Téléchargez Cloud Pass gratuitement — inclut des tests d'entraînement, le suivi de progression et plus encore.

Question 6

(Sélectionnez 3)

An enterprise with 18 AWS accounts in AWS Organizations runs two third‑party inline inspection appliances as manually configured, highly available Amazon EC2 instances in a centralized security VPC within a shared networking account connected to member VPCs through an AWS Transit Gateway; each appliance uses a static private IP as the next hop for 0.0.0.0/0 from member VPCs, a misconfigured automation run recently terminated both instances, and while rebuilding the team created a bootstrap script to configure appliances at first boot, and now the company wants to modernize to minimize cost, scale horizontally from 2 to at least 10 appliances to handle up to 12 Gbps aggregate traffic across two Availability Zones with failover under 60 seconds while continuing to use the same vendor code (vendor confirmed full AWS compatibility)—which combination of steps should a solutions architect recommend to meet these requirements most cost‑effectively? (Choose three)

Analyse de la question

Core concept: This question is about modernizing centralized, cross-account inline traffic inspection on AWS by replacing brittle static next-hop EC2 appliances with a scalable, resilient architecture built around Gateway Load Balancer (GWLB), Gateway Load Balancer endpoints (GWLBe), and Auto Scaling. GWLB is purpose-built for transparent insertion of third-party virtual appliances and integrates with AWS PrivateLink for private, cross-account service consumption. Why correct: A is correct because GWLB is the correct load balancer for inline inspection appliances, and exposing it through an endpoint service allows member VPCs in other accounts to consume the inspection service privately. C is correct because an Auto Scaling group with a launch template and bootstrap user data provides repeatable appliance deployment, automated replacement, and horizontal scaling across two Availability Zones. E is correct because each member VPC must create local GWLBe resources and update route tables so traffic is steered to the inspection service without relying on static appliance IPs. Key features: GWLB uses GENEVE encapsulation to send traffic to appliance fleets while preserving flow context needed by security appliances. GWLBe resources are deployed in the consumer VPCs and act as route targets for transparent service insertion. Auto Scaling with launch templates and user data reduces operational risk and cost by replacing manual appliance management with elastic, health-based scaling. Common misconceptions: A Network Load Balancer with PrivateLink is not the right pattern for transparent inline inspection because it is designed for L4 service exposure, not route-based service insertion. Another common mistake is thinking endpoints should be created in the centralized security VPC; in reality, the consuming member VPCs create the GWLB endpoints. Also, GWLB target groups for EC2 appliances in an Auto Scaling group normally use instance targets rather than IP targets. Exam tips: When a question mentions third-party firewalls, inline inspection, centralized security VPCs, multi-account access, and route-table steering, think GWLB plus GWLBe plus PrivateLink endpoint service. If the scenario also mentions manual EC2 appliances and a need for rapid recovery or horizontal scale, add Auto Scaling with launch templates and bootstrap automation. Be careful to distinguish GWLB from NLB and to place endpoints in the consumer VPCs, not the provider VPC.

Question 7

A media-tech company operates a global learning portal whose web and mobile clients retrieve static UI assets (CSS, JS, thumbnails) from an Amazon S3 bucket in ap-south-1 (about 55 TB, up to 12,000 requests/second) by direct HTTPS object URLs; the company has already created a second S3 bucket in eu-west-1 and requires multi-Region resiliency with near-zero RPO for new objects, automatic read failover, no application code changes, and the least possible operational overhead; which solution will meet these requirements?

Question 8

A media conglomerate operates 12 AWS accounts across three OUs in a single AWS Organizations organization and provisions all infrastructure exclusively with AWS CloudFormation. The compliance office must implement a chargeback model and has mandated that every new resource be tagged with the key cost-center using only one of the allowed values CC-101, CC-202, CC-303, or CC-404; however, when filtering the AWS Cost and Usage Report in AWS Cost Explorer by cost-center, the team found many missing or noncompliant values in stacks created over the past 30 days. With the least operational effort, how should the company enforce both the presence of the cost-center tag on new CloudFormation-created resources and restrict the tag’s value to the approved set across all OUs?

Question 9

(Sélectionnez 3)

A global insurance company plans to accelerate workload migrations to AWS after finalizing network and security guardrails and has already provisioned a dedicated 10 Gbps AWS Direct Connect that terminates in a shared network-landing account. Within 12 months, the organization expects approximately 300 AWS accounts and about 900 VPCs across three Regions. The corporate MPLS WAN must have seamless reachability to all AWS resources, and every VPC must communicate with other VPCs through a central hub. For compliance, all outbound internet traffic from AWS workloads must egress via next-generation firewalls in the on-premises data center; direct internet egress from AWS is not permitted. Which combination of steps will meet these requirements at scale with minimal operational overhead? (Choose three.)

Question 10

A global media company operates a 14-account AWS Organizations environment governed by AWS Control Tower and connects VPCs across accounts with AWS Transit Gateway; in the us-east-1 Region, the analytics account (Account ID: 222222222222) hosts a microservice that uses AWS Lambda and an Amazon Aurora MySQL DB cluster, while the data governance team works from a separate security account (Account ID: 111111111111) using a single Amazon EC2 instance in a private subnet to administer databases across the organization. The analytics team stores the Aurora credentials as secrets in AWS Secrets Manager in the analytics account, and the secrets are encrypted with the default AWS managed key for Secrets Manager (alias aws/secretsmanager) in us-east-1; currently, the analytics team manually shares credentials with the data governance team for troubleshooting. A solutions architect must provide the security account administrators on the EC2 instance on-demand access to the Aurora credentials without manual sharing and must not re-encrypt existing secrets or change the encryption key; which solution meets these requirements?

Analyse de la question

Core Concept: This question tests cross-account access to AWS Secrets Manager secrets in an AWS Organizations/Control Tower environment, and the interaction between Secrets Manager and AWS KMS when secrets are encrypted with the AWS managed key (alias aws/secretsmanager). It also tests the correct use of IAM role assumption for on-demand administrative access. Why the Answer is Correct: Option B is correct because the only supported way to grant another account access to a secret encrypted with the default AWS managed KMS key is to use a cross-account IAM role in the secret-owning account (analytics) and allow principals in the other account (security) to assume it. AWS managed keys cannot be modified with key policies to add cross-account principals, and you cannot “share” Secrets Manager secrets cross-account via AWS RAM. With B, the EC2 instance uses its attached role (Sec-DBA) to call sts:AssumeRole into the analytics account role (Analytics-SecretAccess). That assumed role then calls secretsmanager:GetSecretValue (and optionally DescribeSecret) in the same account as the secret, so KMS decrypt occurs under the analytics account context and works with the AWS managed key without re-encrypting or changing keys. Key AWS Features: - IAM role chaining across accounts using STS AssumeRole. - Least privilege: Analytics-SecretAccess scoped to specific secret ARNs and required actions. - Secrets Manager resource policy can further restrict which principals (the analytics role) can access the secret. - Operational best practice: use session tagging/MFA/CloudTrail to audit who assumed the role and when. Common Misconceptions: A is tempting because AWS RAM shares resources, but Secrets Manager secrets are not RAM-shareable resources. C is tempting because it mentions KMS permissions, but AWS managed KMS keys do not allow editing key policies; cross-account decrypt grants are not possible that way. D misuses SCPs: SCPs only set guardrails (maximum permissions) and do not grant access; they cannot enable cross-account secret retrieval. Exam Tips: When you see “default AWS managed KMS key” and “must not change/re-encrypt,” think: you cannot adjust the key policy, so you must access the secret from within the owning account’s security boundary (assume a role in that account). Also remember: SCPs restrict, RAM shares only supported resource types, and cross-account access typically requires both an IAM trust policy (role assumption) and permissions on the target service.

Practice Test #1

Réponses et explications vérifiées par triple IA

Questions d'entraînement

Témoignages de réussite(9)

Autres tests d'entraînement

Practice Test #2

Practice Test #3

Practice Test #4

Practice Test #5

Commencer à s'entraîner