模擬試験 3

Incorrect. AWS CloudTrail does not track CPU utilization metrics; it logs API calls and account activity for governance, compliance, and auditing. You cannot create a meaningful "CloudTrail alarm" for CPUUtilization because the data source is wrong. For operational metrics and thresholds, CloudWatch (not CloudTrail) is the correct service. Trap: It is tempting because it mentions AWS CloudTrail, but the scenario points to a CloudWatch metric alarm on CPUUtilization with SNS notification.

Incorrect. A cron job running aws ssm describe-instance-information does not provide CPU utilization and is not a reliable monitoring approach. It also adds operational burden, requires instance credentials/permissions, and can fail if the instance is unhealthy (exactly when you most need monitoring). CloudWatch already collects CPU metrics without custom scripts. Trap: It is tempting because it mentions Amazon SNS, but the scenario points to a CloudWatch metric alarm on CPUUtilization with SNS notification.

Incorrect. CloudTrail logs do not contain CPUUtilization metrics, so scanning them with Lambda cannot detect sustained CPU thresholds. Even if metrics were available elsewhere, polling and custom evaluation logic every 10 minutes is unnecessary and less robust than CloudWatch Alarms, which natively handle evaluation periods, missing data behavior, and alarm state transitions. Trap: It is tempting because it mentions AWS CloudTrail, but the scenario points to a CloudWatch metric alarm on CPUUtilization with SNS notification.

A Lambda authorizer controls API Gateway requests; it does not let the function read S3 objects. Trap: Authorizer sounds security-related, but this is service-to-service IAM authorization.

S3 bucket policies attach to buckets, not to Lambda functions, and the option does not use the SAM function role policy path. Trap: A bucket policy can participate in access control, but the phrasing and same-account SAM deployment need are off.

SQS is not a topic and does not grant read access to S3 object data. Trap: Event routing from S3 is separate from permission to call GetObject.

Amazon SQS is a queue where consumers compete for messages unless you build fan-out with multiple queues, which duplicates the delivery path. Trap: SQS is good for decoupling, but it is not a shared replayable stream for several independent processors.

Kinesis Data Firehose buffers and delivers records to destinations such as S3 or OpenSearch; it is not designed for EC2 applications to checkpoint and replay a shared stream. Trap: The Kinesis name is tempting, but Firehose is delivery-oriented rather than consumer-checkpoint-oriented.

EventBridge routes events to targets but does not provide shard-based streaming, sub-second consumer reads, and per-consumer checkpoints. Trap: EventBridge can fan out events, but it is not the stream replay model described here.

Waiting after a 429 is reactive and means the application already exceeded a partner limit. It also leaves the daily quota and large backlog management to custom state logic. Trap: Step Functions Wait is useful, but reacting to throttling is not as clean as shaping consumption before calls occur.

CloudWatch metric filters and alarms are observability tools, not precise runtime throttles. They cannot reliably stop the currently running Lambda invocation at the exact quota boundary. Trap: It counts calls, but alerting is not a rate-control mechanism.

Kinesis Data Firehose is for delivering streaming data to destinations such as S3, Redshift, or OpenSearch. It does not orchestrate outbound REST API calls or enforce per-minute and per-day quotas. Trap: It says batch, but Firehose is the wrong service for controlled API invocation.

Incorrect. An IAM task role provides AWS API permissions, not credentials that an external SMTP relay will accept. IAM authentication works for AWS services (or custom systems that explicitly validate AWS SigV4), but a generic SMTP server on port 587 typically requires a username/password or certificate-based auth. This option also fails the requirement for centrally managed, KMS-encrypted credentials. Trap: It may look tempting because it mentions Remove the SMTP credentials from the task definition and rely on the task IAM role to., but it misses the exact scenario constraints captured by the clues.

Incorrect. While KMS encryption is used, placing ciphertext in task definition environment variables still exposes sensitive material in configuration and requires the container/application to call kms:Decrypt and handle decryption at runtime. That introduces code/config changes and expands permissions and complexity. It also increases the risk of mishandling decrypted values and complicates rotation and auditing compared to managed secret injection. Trap: It may look tempting because it mentions Encrypt the SMTP username and password with an AWS KMS customer managed key and place the., but it misses the exact scenario constraints captured by the clues.

Incorrect. Storing secrets in S3 (even with SSE-KMS) is not the best fit for runtime secret injection and least privilege. The task would need s3:GetObject plus KMS decrypt permissions and additional logic to download and parse the file, which typically implies application or entrypoint changes. It also adds operational overhead (object management, caching, rotation) compared to Parameter Store secrets integration. Trap: It may look tempting because it mentions Place the SMTP credentials in an encrypted .txt file in an Amazon S3 bucket with default., but it misses the exact scenario constraints captured by the clues.

Central-account RDS permissions do not authorize access to RDS resources in other accounts. Trap: It mentions both a role and DescribeDBInstances, but puts the resource permissions in the wrong account.

A role in the central account cannot carry RDS permissions into development accounts that own the DB instances. Trap: The sts:AssumeRole phrase looks right, but the role location and permission boundary are wrong.

Creating target roles is right, but adding rds:DescribeDBInstances directly to the central Lambda role does not let it use those roles. Trap: It has the trust relationship but omits the source-side sts:AssumeRole permission.

AssumeRoleWithWebIdentity is used when the caller presents a web identity token from an OIDC provider (for example, Amazon Cognito, Google, or EKS IRSA). It does not match this scenario because the developer is not using an OIDC token; they are explicitly assuming a cross-account IAM role ARN and providing MFA device ARN and a 6-digit token code. For classic IAM role assumption with MFA, AssumeRole is the correct API. Trap: It is tempting because it mentions AssumeRoleWithWebIdentity, but the scenario points to STS AssumeRole with MFA parameters for a named cross-account role.

GetFederationToken is used to obtain temporary credentials for a federated user, typically to access AWS resources without assuming a specific role in another account. It is not the standard mechanism for cross-account role assumption to a named role ARN in a partner account. Additionally, cross-account access patterns for a partner role like arn:aws:iam::444455556666:role/SQSWriter are designed around sts:AssumeRole, not GetFederationToken. Trap: It is tempting because it mentions GetFederationToken, but the scenario points to STS AssumeRole with MFA parameters for a named cross-account role.

AssumeRoleWithSAML is used when authentication is performed via a SAML 2.0 identity provider and the caller presents a SAML assertion to obtain role credentials. The question does not mention SAML, an IdP, or a SAML assertion-only MFA with a virtual device and a token code. Therefore, this option is a mismatch for the required inputs and the described access pattern. Trap: It is tempting because it mentions AssumeRoleWithSAML, but the scenario points to STS AssumeRole with MFA parameters for a named cross-account role.

CreateCapacityProvider is for customer-managed providers such as EC2 Auto Scaling group providers, not AWS-owned FARGATE providers. Trap: The strategy shape looks reasonable, but the API would try to create providers that already exist as AWS-owned capacity providers.

It puts base=1 on FARGATE_SPOT, which makes Spot the guaranteed first task instead of on-demand Fargate. Trap: It uses the right association API, but reverses the capacity priority required by the prompt.

It incorrectly uses CreateCapacityProvider and also makes FARGATE_SPOT primary. Trap: Switching strategy sounds like migration work, but both provider creation and priority conflict with the requirements.

ELB health checks are irrelevant because this is an event-driven serverless workflow (no load balancer target health to check). Publishing logs as custom metrics via PutMetricData is not a log search solution and adds significant custom work and cost. Athena can query logs in S3, but this option does not provide a clear, minimal-overhead path to centralize EventBridge/Step Functions/Lambda logs into S3 in the first place. Trap: It can sound plausible because it mentions Configure Elastic Load Balancing health checks to monitor the application's availability. Use the Amazon., but it misses native log correlation with the least operational overhead.

Route 53 health checks monitor endpoints, which does not help isolate failures inside EventBridge/Step Functions/Lambda. CloudTrail captures control-plane API calls (e.g., StartExecution) but not the detailed application/runtime logs needed to pinpoint intermittent 5xx errors in Lambda code or state transitions. Querying CloudTrail with Athena can help audit who called what, but it is not the right tool for correlating execution failures across components. Trap: It can sound plausible because it mentions Set up Amazon Route 53 health checks to monitor endpoints. Enable AWS CloudTrail for all AWS services used., but it misses native log correlation with the least operational overhead.

Streaming logs through Kinesis Data Firehose to S3 and indexing in Amazon OpenSearch Service can enable powerful search, but it introduces substantial setup and ongoing operations: delivery streams, buffering, index management, scaling, retention, and cost tuning. This violates the “least operational overhead” requirement. It is appropriate for long-term centralized logging/search at large scale, not for quick troubleshooting with minimal maintenance. Trap: It can sound plausible because it mentions Configure all involved AWS services to stream real-time log events to an Amazon Kinesis Data Firehose., but it misses native log correlation with the least operational overhead.