Übungsfragen

Frage 1

A media streaming company stores its microservice code in AWS CodeCommit, and compliance requires that 100% of unit tests pass and detailed test reports be retained for 60 days and viewable by auditors; for approximately 15 commits per day to the main and develop branches, the team needs each commit to automatically build the service in a Linux build environment, run unit tests, and produce a navigable JUnit-style report without creating a custom UI, while supporting at least 8 concurrent builds and keeping the reports centrally accessible; which solution will meet these requirements?

Frage 2

A site reliability engineer using a Windows laptop must run a local PowerShell script to provision an application stack in the ap-northeast-2 Region within 10 minutes, with command-line-only access to a new AWS account that allows programmatic access but no console sign-in; what must the engineer set up on the laptop to perform the deployment?

Frage 3

A startup operates a two-node Amazon Redshift cluster across 2 Availability Zones for analytics and needs to create an AWS CloudFormation custom resource backed by an AWS Lambda function (256 MB memory, 45-second timeout) to apply additional database configuration during stack creation; the Lambda function must connect to the Redshift cluster using the cluster’s admin user credentials (username set to dw_admin) that are also provisioned at deployment—what is the MOST secure way to provide these credentials to the Lambda function while supplying them to the Redshift cluster?

Frage 4

A company runs a nationwide smart-thermostat platform where device firmware sends telemetry and commands through an existing Amazon API Gateway REST API that invokes multiple AWS Lambda functions for validation and routing. The engineering team has built updated Lambda code with new rule-processing features and needs to test exactly 5% of incoming device requests (about 12,000 requests per hour) for 48 hours without impacting the remaining traffic or changing client behavior, and they want the approach with the least ongoing operational work and minimal API changes; which solution meets these requirements with the least operational effort?

Fragenanalyse

Core concept: This question tests safe production testing/traffic shifting for AWS Lambda behind an existing Amazon API Gateway REST API, using Lambda versions and aliases (a common deployment pattern) to do controlled canary-style routing without changing clients. Why the answer is correct: Option A uses Lambda function versioning plus a weighted alias to split invocations (5% to the new version, 95% to the current version). API Gateway continues to receive the same device requests and simply invokes the alias ARN instead of the unqualified function ARN. This meets the requirement to test exactly 5% of incoming requests for 48 hours with minimal operational effort: you set the weights, monitor, then revert or promote by adjusting alias weights. No client behavior changes are required, and the API surface remains essentially unchanged (only the integration target ARN changes). Key AWS features and best practices: - Lambda versions are immutable snapshots of code/config. - Lambda aliases are stable pointers to versions and support weighted routing between two versions for gradual deployments/canaries. - API Gateway REST API Lambda integration can invoke a specific version/alias by using the qualified ARN. - Operationally, this is lightweight: no additional API stages, no new APIs, and no external deployment orchestrator required for a fixed 48-hour experiment. Common misconceptions: API Gateway stage canaries (options B/D) are often confused with backend canaries. Stage canaries primarily shift traffic between stage deployments/configuration (e.g., different integrations, mappings, authorizers) and typically require maintaining a canary deployment and potentially duplicating configuration. Creating a new REST API is explicitly more change and more operational overhead than necessary. CodeDeploy canary deployments (option C) are excellent for automated progressive rollouts, but they are designed to shift traffic over time toward 100% and manage alarms/rollback. The requirement is to hold at exactly 5% for 48 hours, which is simpler with alias weights and does not require introducing CodeDeploy. Exam tips: - For Lambda behind API Gateway, the lowest-effort traffic split is usually “Lambda version + weighted alias,” then point the integration to the alias. - Use API Gateway canary when you need to test API Gateway configuration changes (mappings, authorizers, stage variables), not just new Lambda code. - Use CodeDeploy when you want automated rollout/rollback with alarms and a progression plan, not when you need a fixed-percentage experiment for a set duration.

Frage 5

A ride-sharing company is building an internal console that aggregates trip and payment data from 25 partner services into one dashboard. The team has automated an OAuth onboarding workflow that retrieves API client credentials (client_id and client_secret) from each partner. During stack updates, an AWS CloudFormation custom resource invokes an AWS Lambda function that fetches or refreshes those credentials. The developer needs a solution to persist the retrieved credentials with minimal operational overhead while keeping them secure at rest and in transit. Which solution will meet these requirements in the most secure way?

Fragenanalyse

Core Concept: This question tests secure secret storage for dynamically retrieved credentials during CloudFormation updates. The key services are AWS Systems Manager Parameter Store (SecureString) and AWS Secrets Manager, plus CloudFormation custom resources and how to avoid leaking secrets in templates, events, or logs. Why the Answer is Correct: Option B is best because the custom resource Lambda already fetches/refreshes the OAuth client_id/client_secret, and it can immediately persist them using ssm:PutParameter with Type=SecureString. SecureString encrypts the value at rest using AWS KMS and uses TLS in transit via the AWS SDK. This approach avoids embedding secrets into the CloudFormation template or stack state, minimizing operational overhead while keeping secrets protected. Key AWS Features: - Parameter Store SecureString: encrypted at rest with KMS (AWS-managed key by default or a customer managed key via KeyId), and decrypted only for authorized principals. - IAM least privilege: restrict Lambda to ssm:PutParameter (and optionally ssm:GetParameter) on specific parameter ARNs and kms:Encrypt/Decrypt for the chosen key. - Versioning/overwrite: PutParameter supports Overwrite=true to rotate/refresh values cleanly. - Avoiding CloudFormation exposure: CloudFormation can record resource properties and custom resource responses in stack events; keeping the secret write inside Lambda reduces the chance of accidental disclosure. Common Misconceptions: Many assume “NoEcho” makes any secret safe in CloudFormation. NoEcho only masks values in certain outputs/console views; it does not provide encryption at rest for the stored value unless the backing service does (and it doesn’t apply to SDK calls). Another misconception is that Secrets Manager is always the “most secure”; it is excellent, but CloudFormation cannot safely “set” a secret value from a custom resource return without risking exposure, and GenerateSecretString is for generating secrets, not ingesting externally retrieved credentials. Exam Tips: - If credentials are fetched dynamically (custom resource/Lambda), store them directly from code into a secret store (Parameter Store SecureString or Secrets Manager via PutSecretValue), rather than passing them through CloudFormation properties. - NoEcho is about masking display, not encryption. - Choose SecureString when you want low operational overhead and KMS-backed encryption; choose Secrets Manager when you need built-in rotation workflows, cross-account replication, and richer secret lifecycle features.

Möchtest du alle Fragen unterwegs üben?

Lade Cloud Pass kostenlos herunter – mit Übungstests, Fortschrittsverfolgung und mehr.

Frage 6

(2 auswählen)

A fintech startup runs a payment-processing AWS Lambda function triggered by Amazon EventBridge; during a 30-minute flash sale in us-west-2, Amazon CloudWatch shows the Throttles metric spiking to 900 per minute while the account-level concurrent executions quota is 1,000 and another critical Lambda has 800 reserved concurrency, so the team wants the MOST operationally efficient actions to reduce throttling for the payment function without re-architecting the workload (Choose two).

Frage 7

A media company ingests video playback telemetry into an Amazon Kinesis Data Streams stream from its web player, and an AWS Lambda function that is triggered by the stream logs and processes each playback event as structured JSON. An operational review shows that some events have playbackDurationSeconds set to 0. A developer must build a dashboard that shows how many unique viewerIds are impacted each day (grouped in 1-day periods); what should the developer do to implement the dashboard?

Frage 8

A real-time ticketing web app runs on an Auto Scaling group of 6 Amazon EC2 instances behind an Application Load Balancer, keeps user cart and login state in memory per client (up to 64 KB per session) with 1,500 writes/s and 1,500 reads/s, must survive sudden instance termination or scale-in events without losing any session data, recover within 1 second, and remain highly available across multiple AZs—what should the developer do to ensure sessions are not lost if an EC2 instance fails?

Frage 9

An online ticketing platform is launching a new serverless notification service with 8 AWS Lambda functions, one Amazon API Gateway HTTP API, and one Amazon DynamoDB table that must be deployed to dev and prod via automation with less than 100 lines of deployment code, support a 10% canary for 5 minutes with automatic rollback, and provide the least operational overhead for building and deploying both the functions and their infrastructure—what method best meets these requirements?

Frage 10

A sports analytics startup runs a latency‑sensitive leaderboard microservice on Amazon ECS using the Amazon EC2 launch type across two Availability Zones and needs to migrate the workload to Amazon ECS on AWS Fargate with near‑zero disruption; during a blue/green cutover, the developer must configure the cluster’s capacity providers so that on‑demand Fargate tasks launch by default (ensuring at least 1 task runs on on‑demand) and FARGATE_SPOT is used only for overflow, while avoiding any API calls that attempt to create AWS‑owned capacity providers; which solution achieves the migration with the least downtime?

Fragenanalyse

Core Concept: This question tests Amazon ECS capacity providers and capacity provider strategies when migrating an ECS service from EC2 launch type to AWS Fargate with minimal disruption. It also tests the distinction between AWS-owned capacity providers (FARGATE, FARGATE_SPOT) and customer-managed capacity providers (typically backed by Auto Scaling groups for EC2). Why the Answer is Correct: To run tasks on Fargate, the cluster must be associated with the AWS-owned FARGATE and (optionally) FARGATE_SPOT capacity providers. The correct way to associate these with an existing cluster is to use PutClusterCapacityProviders, which sets both the list of capacity providers available to the cluster and the cluster’s default capacity provider strategy. Then, to ensure on-demand Fargate is the default and at least one task always runs on on-demand, you set a strategy where FARGATE has base=1. Any additional tasks are distributed by weight; giving FARGATE a weight >= FARGATE_SPOT ensures on-demand is preferred, while still allowing FARGATE_SPOT to be used for overflow. This supports a blue/green cutover with near-zero downtime because you can deploy the new Fargate-based service/task set while the old one remains healthy, then shift traffic. Key AWS Features: - PutClusterCapacityProviders: associates AWS-owned capacity providers to the cluster and sets default strategy. - Capacity provider strategy fields: - base: minimum number of tasks placed on that provider before weights apply. - weight: relative distribution for remaining tasks. - AWS-owned providers: FARGATE and FARGATE_SPOT are not created by customers; they are referenced/associated. - Blue/green on ECS is commonly implemented with CodeDeploy (ECS deployment controller) and an ALB, but the question’s focus is ensuring capacity placement behavior during cutover. Common Misconceptions: A frequent trap is thinking you must “create” Fargate capacity providers via CreateCapacityProvider. That API is for custom capacity providers (e.g., EC2 Auto Scaling-backed), not AWS-owned FARGATE/FARGATE_SPOT. Another trap is setting FARGATE_SPOT with base=1, which violates the requirement that at least one task runs on on-demand. Exam Tips: - Remember: AWS-owned capacity providers (FARGATE/FARGATE_SPOT) are associated, not created. - For “at least N tasks on X,” use base=N. - For “use Spot only for overflow,” make on-demand the provider with base and/or higher weight, and keep Spot as secondary with lower weight.

Practice Test #1

Dreifach KI-verifizierte Antworten & Erklärungen

Übungsfragen

Erfolgsgeschichten(8)

Weitere Übungstests

Practice Test #2

Practice Test #3

Practice Test #4

Practice Test #5

Practice Test #6

Jetzt mit dem Üben beginnen