使用 AWS 服务进行开发 I
针对所有选项,回顾评估问题及解释,以充分掌握应对 AWS 认证开发人员 - 助理 (DVA-C02) 考试中“使用 AWS 服务进行开发”领域问题所需的知识。
Answer: B
Why:
The r5 instances are memory-optimized and suitable for high-throughput, low-latency applications, such as in-memory databases and real-time analytics.
Why not:
Option A: The c7g instances are compute-optimized, best for CPU-bound tasks but not memory-heavy ones.
Option C: The t4g instances are general-purpose and burstable, unsuitable for sustained high-performance memory operations.
Option D: The m6i instances are balanced, but not tailored for memory-optimized workloads.
Answer: B
Why:
The r5 instances are memory-optimized and suitable for high-throughput, low-latency applications, such as in-memory databases and real-time analytics.
Why not:
Option A: The c7g instances are compute-optimized, best for CPU-bound tasks but not memory-heavy ones.
Option C: The t4g instances are general-purpose and burstable, unsuitable for sustained high-performance memory operations.
Option D: The m6i instances are balanced, but not tailored for memory-optimized workloads.
Answers: B, C
Why:
Option B: Reserved instances (RIs) involve a 1-3 year commitment for significant discounts (up to 72%) and are best for consistent, steady-state workloads. While RIs are typically for predictable usage, for workloads that are consistent but also have a batch component, a blend of RIs for baseline capacity and spot for burstable/interruptible tasks is highly cost-effective. Given the phrasing “can tolerate interruptions,” spot is explicitly ideal. RIs also provide significant cost savings.
Option C: Spot instances allow you to bid on unused EC2 capacity, offering discounts of up to 90% compared to on-demand prices. They are ideal for fault-tolerant, stateless applications and batch jobs that can tolerate interruptions, as AWS can reclaim spot instances with a two-minute notification.
Why not:
Option A: On-demand instances offer pay-as-you-go pricing with no long-term commitments, but they do not provide cost savings for interruptible workloads.
Option D: Dedicated hosts are physical servers for your exclusive use, primarily for licensing or compliance, not cost optimization for interruptible workloads.
Option E: Capacity reservations guarantee availability in a specific Availability Zone (AZ) for an instance type, but are primarily used to ensure compute capacity during peak hours, rather than for cost savings on interruptible workloads.
Answers: B, C
Why:
Option B: Reserved instances (RIs) involve a 1-3 year commitment for significant discounts (up to 72%) and are best for consistent, steady-state workloads. While RIs are typically for predictable usage, for workloads that are consistent but also have a batch component, a blend of RIs for baseline capacity and spot for burstable/interruptible tasks is highly cost-effective. Given the phrasing “can tolerate interruptions,” spot is explicitly ideal. RIs also provide significant cost savings.
Option C: Spot instances allow you to bid on unused EC2 capacity, offering discounts of up to 90% compared to on-demand prices. They are ideal for fault-tolerant, stateless applications and batch jobs that can tolerate interruptions, as AWS can reclaim spot instances with a two-minute notification.
Why not:
Option A: On-demand instances offer pay-as-you-go pricing with no long-term commitments, but they do not provide cost savings for interruptible workloads.
Option D: Dedicated hosts are physical servers for your exclusive use, primarily for licensing or compliance, not cost optimization for interruptible workloads.
Option E: Capacity reservations guarantee availability in a specific Availability Zone (AZ) for an instance type, but are primarily used to ensure compute capacity during peak hours, rather than for cost savings on interruptible workloads.
Answer: C
Why:
Amazon EBS provides persistent block storage volumes that can be attached to EC2 instances. These volumes are highly available and offer various performance characteristics suitable for databases, allowing data to persist independently of the instance lifecycle.
Why not:
Option A: Instance store provides temporary block-level storage for EC2 instances. Data on instance store disks is lost when the instance is stopped or terminated.
Option B: Amazon S3 is object storage, not block storage, and is typically used for static content, backups, or data lakes, not directly for a database’s primary storage.
Option D: EFS provides scalable file storage for EC2 instances that can be accessed by multiple instances concurrently, but EBS is the direct block storage solution for databases.
Answer: C
Why:
Amazon EBS provides persistent block storage volumes that can be attached to EC2 instances. These volumes are highly available and offer various performance characteristics suitable for databases, allowing data to persist independently of the instance lifecycle.
Why not:
Option A: Instance store provides temporary block-level storage for EC2 instances. Data on instance store disks is lost when the instance is stopped or terminated.
Option B: Amazon S3 is object storage, not block storage, and is typically used for static content, backups, or data lakes, not directly for a database’s primary storage.
Option D: EFS provides scalable file storage for EC2 instances that can be accessed by multiple instances concurrently, but EBS is the direct block storage solution for databases.
Answers: A, D
Why:
Option A: Prebaked AMIs drastically reduce the initialization time by including all necessary dependencies, libraries, and configurations. This allows EC2 instances to start in a ready-to-serve state rather than spending time running setup or installation scripts.
Option D: Instance hibernation saves the contents of the instance’s memory (RAM) and application state to the root EBS volume. When restarted, the instance resumes execution from its prior state, reducing startup latency compared to a full reboot or cold start.
Why not:
Option B: While dedicated hosts provide visibility into underlying hardware and can benefit from licensing or compliance requirements, they do not materially improve EC2 instance boot time. Launch latency is primarily determined by OS initialization and application setup, rather than hypervisor overhead. Additionally, dedicated hosts reduce elasticity, which contradicts the need for a dynamic, scalable fleet.
Option C: User data scripts are useful for dynamic configuration, but extend launch time when they install or configure software during instance boot. Prebaked AMIs are faster because this work is done in advance.
Option E: Persisting data to EBS ensures data durability across stops and terminations but doesn’t shorten the boot sequence. The instance must still fully start and mount volumes before the application becomes ready.
Answers: A, D
Why:
Option A: Prebaked AMIs drastically reduce the initialization time by including all necessary dependencies, libraries, and configurations. This allows EC2 instances to start in a ready-to-serve state rather than spending time running setup or installation scripts.
Option D: Instance hibernation saves the contents of the instance’s memory (RAM) and application state to the root EBS volume. When restarted, the instance resumes execution from its prior state, reducing startup latency compared to a full reboot or cold start.
Why not:
Option B: While dedicated hosts provide visibility into underlying hardware and can benefit from licensing or compliance requirements, they do not materially improve EC2 instance boot time. Launch latency is primarily determined by OS initialization and application setup, rather than hypervisor overhead. Additionally, dedicated hosts reduce elasticity, which contradicts the need for a dynamic, scalable fleet.
Option C: User data scripts are useful for dynamic configuration, but extend launch time when they install or configure software during instance boot. Prebaked AMIs are faster because this work is done in advance.
Option E: Persisting data to EBS ensures data durability across stops and terminations but doesn’t shorten the boot sequence. The instance must still fully start and mount volumes before the application becomes ready.
Answer: C
Why:
For asynchronous invocation sources, such as Event (which API Gateway can use to invoke Lambda asynchronously), Lambda automatically retries the function twice upon failure. If both attempts fail, Lambda automatically sends the event payload (the order data) to the configured dead-letter queue (DLQ). This perfectly meets the requirement to preserve the payload without custom code.
Why not:
Option A: This bypasses the Lambda function, which is supposed to process the order, making the architecture fundamentally incorrect for this requirement.
Option B: This requires custom code to handle the error and explicitly call SQS or S3, which violates the “LEAST custom code” requirement. The built-in DLQ mechanism is preferred.
Option D: The RequestResponse (synchronous) invocation type is typically used when the caller (like API Gateway) needs an immediate response. When a synchronous invocation fails, Lambda does not automatically retry or send the payload to the DLQ; the caller must handle the error and the retry logic.
Answer: C
Why:
For asynchronous invocation sources, such as Event (which API Gateway can use to invoke Lambda asynchronously), Lambda automatically retries the function twice upon failure. If both attempts fail, Lambda automatically sends the event payload (the order data) to the configured dead-letter queue (DLQ). This perfectly meets the requirement to preserve the payload without custom code.
Why not:
Option A: This bypasses the Lambda function, which is supposed to process the order, making the architecture fundamentally incorrect for this requirement.
Option B: This requires custom code to handle the error and explicitly call SQS or S3, which violates the “LEAST custom code” requirement. The built-in DLQ mechanism is preferred.
Option D: The RequestResponse (synchronous) invocation type is typically used when the caller (like API Gateway) needs an immediate response. When a synchronous invocation fails, Lambda does not automatically retry or send the payload to the DLQ; the caller must handle the error and the retry logic.