模擬試験 6

Incorrect. SQS can buffer timing records, but the team would still need to build, deploy, scale, and monitor a consumer to evaluate the 2000 ms rule. That adds operational overhead when CloudWatch alarms can evaluate the metric natively. Trap: Queue-based processing looks flexible, but it creates a custom detector for a native metric-alarm use case.

Incorrect. An average over a minute can stay below 2000 ms even when one authorization breaches the requirement. It also uses SES for notification instead of the usual CloudWatch alarm action through SNS. Trap: It uses CloudWatch, but the average statistic does not satisfy the any-single-authorization requirement.

Incorrect. Kinesis stores event records but CloudWatch alarms do not inspect arbitrary stream payload values directly. A stream consumer would still be required, which is more operational work than publishing the metric directly. Trap: A stream sounds real time, but it is unnecessary for simple threshold alerting.

Incorrect. sam init is a project scaffolding command that generates a starter SAM application structure and sample templates. It does not deploy resources, update Lambda code, or perform incremental synchronization to an existing stack. While SAM is the right framework, the command required for rapid incremental updates is sam sync (or sam deploy for full deployments), not sam init. Trap: It may look tempting because it mentions Use the AWS Serverless Application Model (AWS SAM) to build the application and use the., but it misses the exact scenario constraints captured by the clues.

Incorrect. cdk synth only synthesizes (generates) a CloudFormation template from CDK code; it does not deploy anything to AWS. Even though CDK ultimately uses CloudFormation, synth is a local build step and cannot push incremental Lambda code changes to a dev stack. The deployment command in CDK would be cdk deploy (not provided as an option). Trap: It may look tempting because it mentions Use the AWS Cloud Development Kit (AWS CDK) to build the application and use the cdk synth., but it misses the exact scenario constraints captured by the clues.

Incorrect. cdk bootstrap provisions prerequisite resources (the CDK toolkit stack, such as an S3 bucket and roles) needed for CDK deployments in an account/region. It is a one-time or infrequent environment setup step, not an incremental deployment mechanism. It will not sync updated Lambda code or apply template tweaks to an existing application stack. Trap: It may look tempting because it mentions Use the AWS Cloud Development Kit (AWS CDK) to build the application and use the cdk., but it misses the exact scenario constraints captured by the clues.

A Lambda authorizer decides whether a request is authorized; it does not route the method integration to a Lambda alias. Trap: It mentions stage variables, but points them at authorizers instead of the backend integration ARN.

Gateway responses customize API Gateway error responses and cannot make stages invoke different Lambda aliases. Trap: The word response sounds stage-related, but it is unrelated to backend selection.

API Gateway does not use Lambda-style environment variables to select integrations per stage. Trap: Environment variables are a Lambda construct; API Gateway uses stage variables.

CloudWatch Logs Insights is not the standard continuous, sub-minute alerting mechanism for every matching incoming log event. Trap: It can search logs, so it feels related, but the exam pattern for alerts is metric filter, metric, alarm.

CloudWatch Logs subscription filters send log events to Lambda, Kinesis Data Streams, or Firehose, not directly to an SNS topic as an SNS subscription filter. Trap: The words subscription and filter are real AWS concepts, but they are being combined incorrectly here.

A CloudWatch alarm cannot contain a raw log filter pattern; it must evaluate a metric. Trap: It mentions the alarm and SNS action, but skips the required metric filter step.

A scheduled Lambda job cannot pause for an operator on its first unattended run, and this option does not define encrypted durable storage for future invocations. Trap: Manual prompting can sound secure, but it breaks serverless scheduled automation.

Embedding the key in code or the deployment package exposes it through source control, build artifacts, and logs, and makes rotation harder. Trap: It would make the value available, but it is a secret-management anti-pattern.

HTTPS and VPC placement address network paths, not whether the API key is encrypted at rest while stored by the function. Trap: Encryption in transit is not the same requirement as encryption at rest.

Moving the workload to ECS/Fargate can avoid Lambda concurrency limits, but it is a re-architecture (new deployment model, scaling policies, networking, observability, and potentially different failure modes). The question explicitly asks to reduce throttling without re-architecting and to choose the most operationally efficient actions. Therefore, this is not an appropriate answer for an exam scenario focused on quick Lambda operational controls. Trap: It may sound plausible because it mentions Rebuild the function as a containerized microservice on Amazon ECS with AWS Fargate, but it does not satisfy the scenario's lambda concurrency throttling requirement.

EventBridge’s maximum event age and retry policy affect how long EventBridge will keep retrying delivery to Lambda when invocations fail or are throttled. Increasing the window can reduce the chance of event loss during prolonged throttling, but it does not reduce throttling itself; it can extend the backlog and delay processing. It’s a durability/latency tradeoff, not a capacity fix. Trap: It may sound plausible because it mentions Increase the maximum event age/retry window for the EventBridge trigger from 24 hours to 6 days, but it does not satisfy the scenario's lambda concurrency throttling requirement.

IAM permissions such as lambda:GetFunctionConcurrency only allow an identity to read concurrency settings via the Lambda API. They do not change runtime scaling behavior, do not increase available concurrency, and do not reduce throttling. The function’s execution role is also not the right place for permissions used by operators or CI/CD systems to query account/function settings. Trap: It may sound plausible because it mentions Attach the lambda:GetFunctionConcurrency permission to the function’s execution role, but it does not satisfy the scenario's lambda concurrency throttling requirement.

KMS can protect encrypted data and rotate KMS key material, but KMS key rotation does not rotate the third-party client_id and client_secret themselves. The developer would still need to build a separate credential rotation workflow. Trap: It confuses encryption key rotation with application secret rotation.

AWS STS issues temporary AWS credentials for calling AWS services. STS credentials do not authenticate to an external payment gateway and do not rotate that gateway client secret. Trap: Temporary credentials sound secure, but they are for AWS identity, not third-party API secrets.

Systems Manager Parameter Store SecureString can store encrypted configuration, but it is not the purpose-built service for automatic secret rotation workflows. Meeting the 90-day rotation requirement for a third-party credential would require more custom automation. Trap: SecureString is encrypted and IAM-controlled, but the rotation requirement points to Secrets Manager.

Storing secrets in S3 (even encrypted with a CMK) is not a best-practice secrets solution. You must build secure retrieval, parsing, and rotation semantics yourself. “S3 Object Lambda to rotate” is not a rotation mechanism; it transforms objects on retrieval and does not manage secret lifecycle, versioning, or coordinated updates with external systems. This increases development/ops effort and risk compared to Secrets Manager. Trap: It can sound plausible because it mentions Store the secrets in a text file in Amazon S3 encrypted with a customer managed KMS key, read the file at., but it misses managed encrypted storage plus automatic 30-day rotation.

Systems Manager Parameter Store SecureString provides encryption at rest (including with KMS), and user data can fetch parameters at boot. However, rotation is not a native managed capability; you must implement scheduled Lambda rotation, update external systems (DB password/API key), handle versioning, and ensure safe cutover/rollback. Using the default KMS key also does not meet a CMK requirement if one is implied by policy. Trap: It can sound plausible because it mentions Save the secrets as SecureString parameters in AWS Systems Manager Parameter Store using the default AWS KMS., but it misses managed encrypted storage plus automatic 30-day rotation.

Base64 encoding is not encryption and does not satisfy “encrypted at rest.” Embedding secrets in configuration files (or AMIs) is insecure, hard to rotate across an Auto Scaling fleet, and increases blast radius if an instance or artifact is compromised. A custom monthly script for rotation is high development and operational effort and is error-prone compared to managed secret rotation services. Trap: It can sound plausible because it mentions Embed the secrets as base64-encoded values in the application’s configuration file, read them at startup,., but it misses managed encrypted storage plus automatic 30-day rotation.

Not necessarily. Ref returns a value for a resource or parameter in the same template (e.g., for AWS::EC2::VPCEndpoint, Ref returns the endpoint ID). However, cross-stack sharing is not achieved by Ref alone; you must import an exported value. The application stack could correctly use ImportValue and not directly use Ref at all, so this is not a required cause of failure. Trap: It may look tempting because it uses The application template does not use the Ref, but the decisive requirement is Outputs Export in the producer and Fn::ImportValue in the consumer.

Incorrect. The Mappings section is for static key/value lookups (e.g., region-to-AMI mappings) and cannot dynamically contain a VPC endpoint ID created by another stack at runtime. Including the endpoint ID in Mappings would require hardcoding it, which defeats the purpose and is brittle. Cross-stack resource sharing should use Outputs/Export and ImportValue instead. Trap: It may look tempting because it uses The Mappings section of the application template does, but the decisive requirement is Outputs Export in the producer and Fn::ImportValue in the consumer.

Incorrect. CloudFormation does not support exporting values from the Mappings section. Only Outputs can be exported for cross-stack references. Mappings are evaluated within a single template and are not addressable by other stacks. Therefore, the absence of an export in Mappings is not a meaningful concept and would not be the root cause. Trap: It may look tempting because it uses The network-core stack's template does not export the, but the decisive requirement is Outputs Export in the producer and Fn::ImportValue in the consumer.