練習問題

問題 1

A media company must migrate its payment processing database from an on-premises Microsoft SQL Server instance running on Windows Server 2019 to AWS, and a security policy mandates that the database credentials must be rotated every 90 days. Which solution will meet these requirements with the least operational overhead?

問題 2

A fitness education platform runs its web tier on Amazon EC2 behind an Application Load Balancer with an Auto Scaling group and stores all static assets on Amazon EFS (General Purpose), but after launching a 1080p training video library (average file size 200 MB) traffic spiked 12x to about 20,000 concurrent users at peak and users now see 5–10 second buffering and occasional HTTP 504 errors, so which is the most cost-efficient and scalable deployment change to resolve these issues without replatforming the compute layer?

問題 3

A gaming analytics company is deploying a matchmaking REST API behind Amazon API Gateway that invokes several AWS Lambda functions written in Java 17; these functions perform heavy static initialization outside the handler (loading third-party libraries, building a Spring context, and creating unique IDs/cryptographic seeds), and cold starts currently take 800–1200 ms during load tests. The service-level objective requires that 95% of cold initializations complete in under 200 ms, traffic bursts from 0 to 60 concurrent requests within seconds, and the team wants the most cost-effective way to minimize startup latency without paying for always-on capacity; which solution should the team choose?

問題分析

Core Concept: This question tests AWS Lambda cold-start mitigation for Java runtimes using Lambda SnapStart versus Provisioned Concurrency, and how to handle initialization code that must remain unique per execution environment (e.g., cryptographic seeds/unique IDs). It also implicitly tests versioning/aliases requirements and cost tradeoffs for bursty traffic behind API Gateway. Why the Answer is Correct: Lambda SnapStart (for Java) reduces cold starts by taking a snapshot of the initialized execution environment after the init phase and restoring it on-demand. This is ideal for heavy static initialization such as loading libraries and building a Spring context. However, anything that must be unique at runtime (random seeds, unique IDs, certain crypto material, timestamps) must not be “frozen” into the snapshot, or you risk duplicated values across restored environments. The correct approach is to use a pre-snapshot hook to prepare the runtime for snapshotting and move uniqueness-sensitive initialization into the handler (or post-restore logic) so it is generated per environment/invocation as appropriate. SnapStart requires publishing a version and enabling SnapStart on that version (not $LATEST). This meets the <200 ms cold init SLO without paying for always-on capacity. Key AWS Features: - Lambda SnapStart: snapshots initialized Java execution environments to dramatically reduce cold starts. - Published versions: SnapStart is enabled on versions; API Gateway should invoke an alias/version for stability. - Runtime hooks (pre-snapshot/post-restore): ensure correctness when snapshotting (e.g., re-seeding RNG, refreshing ephemeral state). - Best practice: keep heavy deterministic init outside handler; keep per-invocation/per-environment uniqueness inside handler or post-restore. Common Misconceptions: Provisioned Concurrency can also reduce cold starts, but it charges for pre-warmed capacity and is less cost-effective when traffic is frequently at zero with sudden bursts. Another trap is enabling SnapStart on $LATEST (not supported) or snapshotting unique IDs/seeds, which can cause duplicate identifiers or weakened randomness. Exam Tips: - For Java cold starts with heavy frameworks, think SnapStart first when you want on-demand cost behavior. - Remember: SnapStart works on published versions, not $LATEST. - If the question mentions unique IDs/crypto seeds or “must be unique,” expect a hook/handler change to avoid snapshotting that state. - Choose Provisioned Concurrency when you need guaranteed warm capacity and can justify the ongoing cost; choose SnapStart when you want lower cold starts without always-on spend.

問題 4

A design studio is enabling 1,200 employees to work remotely and needs a scalable, cost-effective AWS Client VPN solution so that up to 300 concurrent users can securely access internal workloads deployed in six VPCs across four AWS accounts, where a shared networking (hub) account hosts a hub VPC already peered to five spoke VPCs with non-overlapping CIDR blocks, the corporate network currently reaches the hub VPC via a single AWS Site-to-Site VPN, and the solution must minimize monthly spend while allowing remote users to reach applications in all VPCs.

問題分析

Core Concept: This question tests whether AWS Client VPN can be centralized for multi-account, multi-VPC remote access and what network construct is required for scalable routing. The key point is that VPC peering is non-transitive, so traffic from a Client VPN endpoint associated with a hub VPC cannot simply traverse peering connections to reach spoke VPCs. To provide remote users access to workloads across multiple VPCs and accounts from a single Client VPN endpoint, you need a transit routing service such as AWS Transit Gateway. Why the Answer is Correct: A single Client VPN endpoint in the shared networking account combined with AWS Transit Gateway is the correct design because Transit Gateway supports centralized, transitive routing across multiple VPCs and accounts. The Client VPN endpoint associates with subnets in the hub VPC, that VPC attaches to the Transit Gateway, and each spoke VPC in the other accounts also attaches to the Transit Gateway. With proper route propagation and authorization rules, remote users can access applications in all six VPCs from one VPN endpoint. Although Transit Gateway adds cost, it is the only option presented that satisfies the connectivity requirement with a single scalable endpoint. Key AWS Features / Configurations: - AWS Client VPN endpoint associated with subnets in the shared networking account. - AWS Transit Gateway attachments for the hub VPC and each spoke VPC across accounts. - Transit Gateway route tables configured so the Client VPN client CIDR and all VPC CIDRs are mutually reachable. - Client VPN authorization rules for the required destination CIDRs. - Security groups and network ACLs updated to allow traffic from the Client VPN client CIDR. Common Misconceptions: - Assuming VPC peering allows a centralized Client VPN endpoint to reach peered VPCs. It does not, because peering does not support transitive routing. - Thinking the existing Site-to-Site VPN can be reused as a path for remote users to reach all AWS VPCs. That would not solve the core routing limitation and is not how Client VPN is designed for this use case. - Assuming the cheapest-looking option is automatically correct. If it cannot meet the routing requirement, it is not a valid solution. Exam Tips: When you see centralized remote access to many VPCs across accounts, immediately check whether the existing network is based on peering or Transit Gateway. For hub-and-spoke remote access with one VPN endpoint, Transit Gateway is usually the required service because it supports transitive routing. On the exam, eliminate answers that rely on VPC peering for transit between VPN clients and other VPCs.

問題 5

A company uses AWS Organizations across 12 AWS accounts in two OUs. The Commerce account (ID 111122223333) runs an order processing application that stores confidential data in an Amazon DynamoDB table named Orders in us-east-1 (about 60 GB, 50,000 items). The analytics team in the Insights account (ID 444455556666) needs read-only access for Query and GetItem operations to only the order_id, total_amount, and order_date attributes; they must not be able to view or write the email, card_token, or address attributes. The solution must work cross-account, enforce least privilege, and must not require data duplication. What should a solutions architect do?

問題分析

Core Concept: This question tests cross-account access design in AWS Organizations with least privilege, specifically using IAM role assumption and DynamoDB fine-grained access control. It also tests understanding of what can (and cannot) be restricted at the IAM layer for DynamoDB items/attributes. Why the Answer is Correct: Option B is the correct architectural pattern for cross-account access without data duplication: create an IAM role in the resource-owning account (Commerce) that the consumer account (Insights) can assume. This keeps control with the data owner and supports least privilege by limiting actions to dynamodb:Query and dynamodb:GetItem on the specific Orders table. The trust policy on the role allows sts:AssumeRole only from the Insights account (and ideally a specific principal/role in that account). Key AWS Features: 1) Cross-account IAM role assumption: A role in Commerce with a trust policy for Insights is the standard, auditable approach. 2) Least privilege on DynamoDB actions/resources: Scope permissions to the table ARN (and optionally indexes) and only required read APIs. 3) Important limitation: IAM “fine-grained access control” for DynamoDB can restrict access by leading keys (dynamodb:LeadingKeys) and can restrict actions, but IAM does not reliably enforce per-attribute redaction for Query/GetItem results. To truly prevent viewing email/card_token/address while still querying the same items, you typically need application-layer controls (e.g., a proxy/API that projects attributes) or a separate table/view. However, among the provided options, B is the only one that correctly implements cross-account access control in the owning account without duplication and aligns with AWS best practices. Common Misconceptions: - Confusing SCPs with permission grants: SCPs only set maximum permissions; they do not grant access. - Assuming DynamoDB supports table-attached resource policies like S3: DynamoDB does not support general resource-based policies on tables for IAM authorization in the way S3 does. - Using permissions boundaries to “enforce” least privilege across accounts: boundaries limit what a role can do but do not solve cross-account trust/authorization by themselves. Exam Tips: For cross-account access to a data store in one account, the default exam answer is usually “create a role in the data-owning account and allow the other account to assume it,” then apply least-privilege permissions on that role. Remember: SCPs restrict, they don’t grant; and not all services support resource-based policies. When a question asks for attribute-level secrecy, be cautious—DynamoDB IAM controls are strongest for item-level/key-based restrictions, not true column-level masking.

外出先でもすべての問題を解きたいですか？

Cloud Passを無料でダウンロード — 模擬試験、学習進捗の追跡などを提供します。

問題 6

A digital media conglomerate uses AWS Organizations with all features enabled and has three OUs (Studio, Gaming, Analytics), each with a shared services account used by central vendor managers; leadership requires that about 120 developers across 12 product accounts can purchase only preapproved third-party software via AWS Marketplace Private Marketplace, and that Private Marketplace administration be restricted strictly to a role named vendor-admin-role assumed only by vendor managers in the shared services accounts, while all other IAM users, groups, roles, account administrators, and root users across the organization are denied Private Marketplace administrative permissions; what is the MOST efficient architecture to centrally enforce these controls and also prevent creation of spoofed admin roles?

問題分析

Core Concept: This question is about using AWS Organizations SCPs for centralized preventive guardrails, combined with a tightly scoped IAM role design for AWS Marketplace Private Marketplace administration. The requirement explicitly says all other principals, including account administrators and root users, must be denied administrative permissions, which points to SCPs rather than account-local IAM controls. Why the Answer is Correct: Option C is the most efficient design because it keeps the privileged vendor-admin-role only in the shared services accounts and uses root-level SCPs to enforce organization-wide denial of Private Marketplace administrative actions for everyone except that trusted role in those accounts. SCPs apply to all member accounts and limit the maximum permissions available, so even highly privileged IAM principals in product accounts cannot bypass them. A second SCP can deny creation of any IAM role named vendor-admin-role outside the trusted shared services accounts, preventing role-name spoofing that could otherwise satisfy a role-name-based exception. Key AWS Features: 1) SCPs: SCPs are the correct control when the requirement is to centrally deny actions across accounts, including for administrators. They define the permission ceiling for member accounts in the organization. 2) Principal-based exception: The deny SCP can use a condition such as aws:PrincipalArn to exempt only the specific vendor-admin-role ARNs in the shared services accounts. This preserves least privilege while allowing the vendor managers to administer Private Marketplace. 3) Anti-spoofing guardrail: A separate SCP can deny iam:CreateRole when the requested role name is vendor-admin-role in untrusted accounts or OUs. This prevents product accounts from creating a same-named role to exploit the exception logic. Common Misconceptions: A common mistake is assuming IAM policies or permission boundaries can centrally block all users across an organization. They cannot override root-level organizational guardrails and are scoped to individual accounts or attached principals. Another misconception is that duplicating the admin role into every account is simpler, when it actually increases blast radius and weakens central governance. Exam Tips: When a question says to deny permissions for everyone except a specific trusted role across many accounts, think SCPs first. When the exception is based on a role identity, also consider how to prevent look-alike role creation in other accounts. Prefer centralized controls at the organization root when the requirement spans all OUs and accounts.

問題 7

A university genomics department runs an on-premises NAS that exports NFSv3 shares and wants to back up 8 TB of lab data to Amazon S3 each week using a solution that preserves NFS access, automatically archives objects after 5 days, and allows up to 72 hours of retrieval time during disaster recovery; which approach is the most cost-effective?

問題 8

(2つ選択)

A retail enterprise operates 9 AWS accounts under a shared billing model; a compliance review found that 37 out of 120 Amazon RDS DB instances (MySQL and PostgreSQL) have unencrypted storage, and a solutions architect must migrate these DB instances to use a customer managed AWS KMS key with no more than 10 minutes of downtime per instance while also ensuring that any newly created unencrypted RDS instances in any account are automatically detected within 15 minutes and that centralized, multi-account governance emphasizes security and compliance. Which combination of steps should the solutions architect take to meet these requirements? (Choose two.)

問題 9

A logistics startup runs a serverless order-tracking backend where a public Amazon API Gateway HTTP API invokes multiple AWS Lambda functions for different routes, and the company’s FinOps team needs an automated biweekly (every 14 days at 00:30 UTC) CSV report that lists, for each API Lambda function, the recommended configured memory, the estimated monthly cost based on the recommendation, and the price difference compared to current settings, with each report covering the prior 14-day window and being saved to an Amazon S3 bucket (for example, s3://finops-reports/serverless/biweekly/), and the company wants the solution that requires the least development time; which approach should they use?

問題 10

A multinational fintech firm is replatforming 80% of its payment and analytics workloads to AWS by the end of Q4, but all cardholder-processing services for 12 jurisdictions must remain in country or in the firm’s Frankfurt colocation to satisfy data residency and maintain sub-5 ms round-trip latency to on-prem HSMs, while 140 rural retail kiosks have only 5–10 Mbps backhaul with daily 30–60 minute outages, and the firm requires that developers use the same AWS APIs, IAM, and CI/CD tools to build once and deploy unchanged across on-premises, an AWS Region, or a hybrid topology; which solution provides a consistent hybrid experience under these constraints?

問題分析

Core Concept: This question tests which AWS hybrid and edge services best satisfy three simultaneous constraints: strict in-country/on-prem data residency with very low latency to local HSMs, intermittent low-bandwidth edge operation at kiosks, and a consistent AWS development and operations model. The key distinction is that AWS Outposts provides a true on-prem AWS experience with the same APIs, IAM, and tooling, while Snowball Edge is an edge compute device designed for remote or disconnected environments. Why correct: Option C is the best overall solution because AWS Outposts racks can be installed in the Frankfurt colocation or other in-country facilities so regulated cardholder-processing workloads remain local and can communicate with on-prem HSMs over local network paths with very low latency. Outposts extends AWS infrastructure and services on premises and uses the same AWS APIs, IAM, CloudFormation, and operational tooling, which directly supports the requirement to build once and deploy with a consistent model across on-premises and AWS Regions. For the rural kiosks, Snowball Edge Compute Optimized is the best listed service because it can run local compute such as EC2 instances and container-based workloads even when WAN connectivity is poor or temporarily unavailable. Key features: - AWS Outposts racks provide AWS-managed infrastructure on premises with native AWS APIs, IAM integration, and familiar deployment tooling. - Outposts is designed for low-latency access to on-prem systems and for workloads that must remain in a specific physical location. - Snowball Edge Compute Optimized provides ruggedized local compute for edge sites with limited or intermittent connectivity. - Snowball Edge can support local processing at kiosks, but any data movement or reconciliation back to AWS must be designed by the application or transfer workflow rather than assumed as transparent built-in synchronization. Common misconceptions: A common mistake is to choose Direct Connect, Local Zones, or Wavelength simply because they reduce latency. Those services do not place the workload inside the customer’s facility in the same way Outposts does, and they do not solve disconnected edge operation at rural kiosks. Another misconception is to treat Snowball Edge as equivalent to Outposts for consistent AWS APIs and control-plane behavior; Snowball Edge supports edge compute, but it is not the primary service for full on-prem AWS consistency. Exam tips: When a question emphasizes same AWS APIs, IAM, and deployment tooling on premises, Outposts is usually the strongest signal. When a question emphasizes remote sites with poor connectivity or temporary disconnections, Snowball Edge is often the edge-device answer if Outposts is impractical. In mixed-constraint questions, select the option that best maps each requirement to the most appropriate AWS service, even if one component is not identical in operational model to the primary platform.

Practice Test #3

3重AI検証済み解答＆解説

練習問題

合格体験記(9)

他の模擬試験

Practice Test #1

Practice Test #2

Practice Test #4

Practice Test #5

今すぐ学習を始める