目次 †
この中はページ内リンクにしたい。※やり方がわかったらやる。
http://www.briefmenow.org/amazon/how-should-you-implement-this-for-each-deployment/#
備忘：Question1のコメント欄に問題と解答を載せている人がいた。
Question1 †
原文 †
Your application is currently running on Amazon EC2 instances behind a load balancer. Your management has decided to use a Blue/Green deployment strategy. How should you implement this for each deployment?
A.Set up Amazon Route 53 health checks to fail over from any Amazon EC2 instance that is currently being deployed to. †
B.Using AWS CloudFormation?, create a test stack for validating the code, and then deploy the code to each production Amazon EC2 instance. †
C.Create a new load balancer with new Amazon EC2 instances, carry out the deployment, and then switch DNS over to the new load balancer using Amazon Route 53 after testing. †
D.Launch more Amazon EC2 instances to ensure high availability, de-register each Amazon EC2 instance from the load balancer, upgrade it, and test it, and then register it again with the load balancer. †
翻訳 †
アプリケーションは現在、ロードバランサーの背後にあるAmazon EC2インスタンスで実行されています。 あなたの管理者は、Blue / Green展開戦略を採用することを決定しました。 各展開に対してこれをどのように実装する必要がありますか。
A.現在デプロイされているすべてのAmazon EC2インスタンスからフェイルオーバーするようにAmazon Route 53ヘルスチェックを設定します。 †
B. AWS CloudFormation?を使用して、コードを検証するためのテストスタックを作成してから、本番の各Amazon EC2インスタンスにコードをデプロイします。 †
C.新しいAmazon EC2インスタンスを使用して新しいロードバランサーを作成し、デプロイを実行してから、テスト後にAmazon Route 53を使用してDNSを新しいロードバランサーに切り替えます。 †
D.高可用性を確保するためにさらに多くのAmazon EC2インスタンスを起動し、各Amazon EC2インスタンスをロードバランサーから登録解除し、アップグレードしてからテストしてから、ロードバランサーに再度登録します。 †
解説 †
回答：C
blue / green デプロイは、新・旧の環境の平衡稼働が必要。
A：フェールオーバーの場合、新旧並行稼働ができない。
B：テストと並行させているが、結局本番にデプロイしているため、新旧並行稼働ができない。
C：〇
D：ロードバランサーから解除 → デプロイ → テスト → ロードバランサーの登録 これは新旧並行稼働できない。
Question2 †
原文 †
You have an application consisting of a stateless web server tier running on Amazon EC2 instances behind load balancer,and are using Amazon RDS with read replicas. Which of the following methods should you use to implement a selfhealing and cost-effective architecture? (Choose two.)
A.Set up a third-party monitoring solution on a cluster of Amazon EC2 instances in order to emit custom CloudWatch? metrics to trigger the termination of unhealthy Amazon EC2 instances. †
B.Set up scripts on each Amazon EC2 instance to frequently send ICMP pings to the load balancer in order to determine which instance is unhealthy and replace it. †
C.Set up an Auto Scaling group for the web server tier along with an Auto Scaling policy that uses the Amazon RDS DB CPU utilization CloudWatch? metric to scale the instances. †
D.Set up an Auto Scaling group for the web server tier along with an Auto Scaling policy that uses the Amazon EC2 CPU utilization CloudWatch? metric to scale the instances. †
E.Use a larger Amazon EC2 instance type for the web server tier and a larger DB instance type for the data storage layer to ensure that they don’t become unhealthy. †
F.Set up an Auto Scaling group for the database tier along with an Auto Scaling policy that uses the Amazon RDS read replica lag CloudWatch? metric to scale out the Amazon RDS read replicas. †
G.Use an Amazon RDS Multi-AZ deployment. †
翻訳 †
ロードバランサーの背後にあるAmazon EC2インスタンス上で実行されるステートレスWebサーバー層で構成されるアプリケーションがあります。
リードレプリカでAmazon RDSを使用しています。 以下の方法のうち、自己修復と費用対効果の高いアーキテクチャを実装するために使用すべきものはどれですか。 （2つ選んでください。）
A.異常なAmazon EC2インスタンスの終了をトリガーするカスタムCloudWatch?メトリックスを発行するために、Amazon EC2インスタンスのクラスターにサードパーティのモニタリングソリューションをセットアップします。 †
B.各Amazon EC2インスタンスでスクリプトを設定して、どのインスタンスが異常であるかを判断して置き換えるために、ICMP pingをロードバランサーに頻繁に送信します。 †
C. Amazon RDS DBのCPU使用率CloudWatch?メトリックスを使用してインスタンスを拡張するAuto Scalingポリシーと共に、Webサーバー層のAuto Scalingグループを設定します。 †
D. Amazon EC2のCPU使用率CloudWatch?メトリックスを使用してインスタンスをスケーリングするAuto Scalingポリシーとともに、Webサーバー層のAuto Scalingグループを設定します。 †
E.ウェブサーバー層にはより大きいAmazon EC2インスタンスタイプを使用し、データストレージ層にはより大きいDBインスタンスタイプを使用して、それらが異常にならないようにします。 †
F。Amazon RDSリードレプリカラグCloudWatch?メトリックスを使用してAmazon RDSリードレプリカをスケールアウトするAuto Scalingポリシーとともに、データベース層のAuto Scalingグループを設定します。 †
G. Amazon RDSマルチAZ配置を使用します。 †
解説 †
回答：「D」と「G」
ポイントは「自己修復」と「費用対効果」が求められている。
つまりは、障害とならないようにするか、障害発生時にすぐに復旧できるようにするか。その観点で選択しを絞り込む。
A：CloudWatch?メトリクスを発行するため、3rdParty製品を利用するとあるが、費用対効果の面で△ 実現可否はちょっとわからない
B：pingをロードバランサーに送ったところで、異常の判断はできない。LBのhealthcheckでいいのでは？
C：RDSにはAutoScaling?機能はない
D：〇 EC2をAutoScaling?させる
E：大きいインスタンスを使って落とさないようにする（×費用）。単一障害に耐えれない（×可用性）
F：リードレプリカに対してスケールアウトはできないし、RDSにAutoScaling?は設定できない
G：〇
Question3 †
原文 †
You have a code repository that uses Amazon S3 as a data store. During a recent audit of your security controls, some concerns were raised about maintaining the integrity of the data in the Amazon S3 bucket. Another concern was raised around securely deploying code from Amazon S3 to applications running on Amazon EC2 in a virtual private cloud. What are some measures that you can implement to mitigate these concerns? (Choose two.)
A.Add an Amazon S3 bucket policy with a condition statement to allow access only from Amazon EC2 instances with RFC 1918 IP addresses and enable bucket versioning. †
B.Add an Amazon S3 bucket policy with a condition statement that requires multi-factor authentication in order to delete objects and enable bucket versioning. †
C.Use a configuration management service to deploy AWS Identity and Access Management user credentials to the Amazon EC2 instances. Use these credentials to securely access the Amazon S3 bucket when deploying code. †
D.Create an Amazon Identity and Access Management role with authorization to access the Amazon S3 bucket, and launch all of your application’s Amazon EC2 instances with this role. †
E.Use AWS Data Pipeline to lifecycle the data in your Amazon S3 bucket to Amazon Glacier on a weekly basis. †
F.Use AWS Data Pipeline with multi-factor authentication to securely deploy code from the Amazon S3 bucket to your Amazon EC2 instances. †
翻訳 †
データストアとしてAmazon S3を使用するコードリポジトリがあります。最近のセキュリティ管理策の監査中
に、Amazon S3バケット内のデータの整合性を維持することに関していくつかの懸念が生じました。
仮想プライベートクラウド内のAmazon EC2上で実行されているアプリケーションにAmazon S3からコードを安全にデプロイすることについて、別の懸念が生じました。どのような
あなたは、これらの懸念を軽減するために実装することができ、いくつかの対策がありますか？（2つ選んでください。）
A. 条件文を使用してAmazon S3バケットポリシーを追加し、RFC 1918 IP アドレスを持つAmazon EC2インスタンスからのアクセスのみを許可し、バケットバージョニングを有効にします。 †
B. オブジェクトを削除してバケットのバージョン管理を有効にするために多要素認証を必要とする条件ステートメントを使用して、Amazon S3バケットポリシーを追加します。 †
C. 設定管理サービスを使用して、AWS Identity and Access Managementユーザー認証情報をAmazon EC2 インスタンスにデプロイします。コードをデプロイするときにこれらの認証情報を使用してAmazon S3バケットに安全にアクセスします。 †
D. Amazon S3バケットにアクセスする権限を持つAmazon Identity and Access Managementロールを作成し、このロールを使用してアプリケーションのすべてのAmazon EC2インスタンスを起動します。 †
E. AWS Data Pipelineを使用して、毎週Amazon S3バケットのデータをAmazon Glacierにライフサイクルさせます。 †
F. 多要素認証を使用してAWS Data Pipelineを使用して、Amazon S3バケットからAmazon EC2 インスタンスにコードを安全にデプロイします。 †
解説 †
回答：「B」と「D」（？が残っているが）
S3の安全性と、セキュリティとに関する問題。わかる部分から
F：×データバックアップの退避をしている。セキュリティとは関係ない
E：×Data plpelineはタスク定義をするもの。それに対して多要素認証をかけることはできない
D：〇 EC2にS3アクセスのIAMロール作成。正しい。
C：？管理設定サービスが何を指しているかわからないが、ユーザのクレデンシャル情報をEC2に設定する意味だと×
B：〇ファイルのバージョニングを有効にする。削除する際に多要素認証を有効にする。後者はできるの知らなかった・・・
https://dev.classmethod.jp/cloud/s3-mfa-delete/
A：？VPCからエンドポイント（または、IGW）を経由するため、プライベートIPでは判別できないのでは？
Question4 †
原文 †
Your company releases new features with high frequency while demanding high application availability. As part of the
application’s A/B testing, logs from each updated Amazon EC2 instance of the application need to be analyzed in near
real-time, to ensure that the application is working flawlessly after each deployment. If the logs show arty anomalous
behavior, then the application version of the instance is changed to a more stable one. Which of the following methods
should you use for shipping and analyzing the logs in a highly available manner?
A.Ship the logs to Amazon S3 for durability and use Amazon EMR to analyze the logs in a batch manner each hour. †
B.Ship the logs to Amazon CloudWatch? Logs and use Amazon EMR to analyze the logs in a batch manner each hour. †
C.Ship the logs to an Amazon Kinesis stream and have the consumers analyze the logs in a live manner. †
D.Ship the logs to a large Amazon EC2 instance and analyze the logs in a live manner. †
E.Store the logs locally on each instance and then have an Amazon Kinesis stream pull the logs for live analysis. †
翻訳 †
あなたの会社は高いアプリケーションの可用性を要求しながら、高頻度で新機能をリリースしています。
アプリケーションのA / Bテストの一環として、更新された各アプリケーションのAmazon EC2インスタンスからのログをほぼ
リアルタイムで分析し、各展開後にアプリケーションが問題なく動作していることを確認する必要があります。ログに異常な
振る舞いが見られる場合は、インスタンスのアプリケーションバージョンをより安定したものに変更します。次の方法のうちどれを
可用性の高い方法でログを出荷および分析するために使用しますか。
A. 耐久性を確保するためにログをAmazon S3に送付し、Amazon EMRを使用して1時間ごとにバッチ方式でログを分析します。 †
B. ログをAmazon CloudWatch? Logsに送信し、Amazon EMRを使用して1時間ごとにバッチ方式でログを分析します。 †
C. ログをAmazon Kinesisストリームに送付し、消費者にログを実際の方法で分析させる。 †
D. ログを大規模なAmazon EC2インスタンスに送付し、実際の方法でログを分析します。 †
E. ログを各インスタンスにローカルに保存してから、Amazon Kinesisストリームでライブ分析用にログを取得します。 †
解説 †
回答：C
リアルタイム性、可用性が高い・・・とあります。
リアルタイム性 → Amazon Kinesis
その条件で絞り込むと、「C」、「E」に絞り込まれる。
※「A」「B」はバッチ処理とあるため、リアルタイム性がない。「D」はインスタンスに保存して分析とあるのでKinesisの方がリアル
そのうえで、「C」、「E」を比較すると、インスタンスのローカルに保存してから。文章だけでみると、保存せずにKinesisに送るほうが早いと思うが、実際のやり方は・・・？
Question5 †
原文 †
Your company has multiple applications running on AWS. Your company wants to develop a tool that notifies on-call teams immediately via email when an alarm is triggered in your environment. You have multiple on-cal teams that work different shifts, and the tool should handle notifying the correct teams at the correct times. How should you implement this solution?
A.Create an Amazon SNS topic and an Amazon SQS queue. †
Configure the Amazon SQS queue as a subscriber to the Amazon SNS topic.
Configure CloudWatch? alarms to notify this topic when an alarm is triggered.
Create an Amazon EC2 Auto Scaling group with both minimum and desired Instances configured to 0.
Worker nodes in this group spawn when messages are added to the queue.
Workers then use Amazon Simple Email Service to send messages to your on call teams.
B.Create an Amazon SNS topic and configure your on-call team email addresses as subscribers. †
Use the AWS SDK tools to integrate your application with Amazon SNS and send messages to this new topic.
Notifications will be sent to on-call users when a CloudWatch? alarm is triggered.
C.Create an Amazon SNS topic and configure your on-call team email addresses as subscribers. †
Create a secondary Amazon SNS topic for alarms and configure your CloudWatch? alarms to notify this topic when triggered.
Create an HTTP subscriber to this topic that notifies your application via HTTP POST when an alarm is triggered.
Use the AWS SDK tools to integrate your application with Amazon SNS and send messages to the first topic so that on-call engineers
receive alerts.
D.Create an Amazon SNS topic for each on-call group, and configure each of these with the team member emails as subscribers. †
Create another Amazon SNS topic and configure your CloudWatch? alarms to notify this topic when triggered.
Create an HTTP subscriber to this topic that notifies your application via HTTP POST when an alarm is triggered.
Use the AWS SDK tools to integrate your application with Amazon SNS and send messages to the correct team topic when on shift.
翻訳 †
あなたの会社はAWS上で複数のアプリケーションを実行しています。あなたの会社
はあなたの環境で警報が発せられた時にEメールで即座にオンコールチームに通知するツールを開発したいです。あなたは
異なる交代制で働く複数の非公式チームを持っています、そしてツールは正しいチームに正しい時に通知することを扱うべきです。
このソリューションをどのように実装しますか？
A. Amazon SNSトピックとAmazon SQSキューを作成します。Amazon SNSトピックへのサブスクライバとしてAmazon SQSキューを設定します。アラームがトリガーされたときにこのトピックに通知するようにCloudWatch?アラームを設定します。最小および希望のインスタンスの両方を0に設定してAmazon EC2 Auto Scalingグループを作成します。このグループのワーカーノードは、メッセージがキューに追加されたときに生成されます。その後、従業員はAmazon Simple Email Serviceを使用して通話中のチームにメッセージを送信します。 †
B. Amazon SNSトピックを作成し、通話チームのEメールアドレスを購読者として設定します。AWS SDKツールを使用してアプリケーションをAmazon SNSと統合し、この新しいトピックにメッセージを送信します。CloudWatch?アラームがトリガーされると、通知が通話中のユーザーに送信されます。 †
C. Amazon SNSトピックを作成し、通話チームのEメールアドレスを購読者として設定します。アラーム用のセカンダリAmazon SNSトピックを作成し、トリガーされたときにこのトピックに通知するようにCloudWatch?アラームを設定します。このトピックへのHTTPサブスクライバを作成して、アラームがトリガーされたときにHTTP POSTを介してアプリケーションに通知します。AWS SDKツールを使用してアプリケーションをAmazon SNSと統合し、最初のトピックにメッセージを送信して、オンコールエンジニアがアラートを受け取るようにします。 †
D. オンコールグループごとにAmazon SNSトピックを作成し、チームメンバーのEメールを購読者としてこれらの各トピックを設定します。 別のAmazon SNSトピックを作成し、トリガーされたときにこのトピックに通知するようにCloudWatch?アラームを設定します。このトピックへのHTTPサブスクライバを作成して、アラームがトリガーされたときにHTTP POSTを介してアプリケーションに通知します。AWS SDKツールを使用して、アプリケーションをAmazon SNSと統合し、移行時に正しいチームトピックにメッセージを送信します。 †
解説 †
回答：D
A、B、C：特定のグループに配信する仕組みとなっていない。
そのため、要件を満たせそうなのはDのみ。
Question6 †
原文 †
You are responsible for your company’s large multi-tiered Windows-based web application running on Amazon EC2
instances situated behind a load balancer. While reviewing metrics, you’ve started noticing an upwards trend for slow
customer page load time. Your manager has asked you to come up with a solution to ensure that customer load time is
not affected by too many requests per second. Which technique would you use to solve this issue?
A. †
Re-deploy your infrastructure using an AWS CloudFormation? template.
Configure Elastic Load Balancing health checks to initiate a new AWS CloudFormation? stack when health checks return failed.
B. †
Re-deploy your infrastructure using an AWS CloudFormation? template.
Spin up a second AWS CloudFormation? stack.
Configure Elastic Load Balancing SpillOver? functionality to spill over any slow connections to the second AWS CloudFormation? stack.
C. †
Re-deploy your infrastructure using AWS CloudFormation?, Elastic Beanstalk, and Auto Scaling.
Set up your Auto Scaling group policies to scale based on the number of requests per second as well as the current customer load
time.
D. †
Re-deploy your application using an Auto Scaling template.
Configure the Auto Scaling template to spin up a new Elastic Beanstalk application when the customer load time surpasses your
threshold.
翻訳 †
あなたは
、ロードバランサの背後にあるAmazon EC2 インスタンス上で実行されている、あなたの会社の大規模な多層WindowsベースWebアプリケーションを担当しています。測定基準を確認しているうちに、
カスタマーページの読み込み時間が遅いという上向きの傾向に気付き始めました。顧客の読み込み時間が
1秒あたりの要求数が多すぎても影響を受けないようにするための解決策を考え出すよう、マネージャから依頼されました。この問題を解決するためにどの手法を使用しますか？
A. †
AWS CloudFormation?テンプレートを使用してインフラストラクチャを再デプロイしてください。
ヘルスチェックが失敗したときに新しいAWS CloudFormation?スタックを開始するようにElastic Load Balancingヘルスチェックを設定します。
B. †
AWS CloudFormation?テンプレートを使用してインフラストラクチャを再デプロイします。
2番目のAWS CloudFormation?スタックを起動します。
2つ目のAWS CloudFormation?スタックへの低速接続をこぼれるようにElastic Load Balancing SpillOver?機能を設定します。
C. †
AWS CloudFormation?、Elastic Beanstalk、およびAuto Scalingを使用してインフラストラクチャを再デプロイします。
Auto Scalingグループポリシーを1秒あたりの要求数と現在のカスタマーロード
時間に基づいて調整するように設定します。
D. †
Auto Scalingテンプレートを使用してアプリケーションを再配置します。
顧客読み込み時間が
しきい値を超えたときに新しいElastic Beanstalkアプリケーションを起動するようにAuto Scalingテンプレートを設定します。
解説 †
回答はC
詳しくは説明できない。世の中の回答を信じましょう
A：ELBヘルスチェックに失敗でCloudFormation?から再デプロイ ← 停止時間できる。
B：
C：
D：
諦めました
Question7 †
原文 †
During metric analysis, your team has determined that the company’s website is experiencing response times during
peak hours that are higher than anticipated. You currently rely on Auto Scaling to make sure that you are scaling your
environment during peak windows. How can you improve your Auto Scaling policy to reduce this high response 18:02:17
Choose 2 answers.
A. †
Push custom metrics to CloudWatch? to monitor your CPU and network bandwidth from your servers, which will allow your Auto Scaling
policy to have better fine-grain insight.
B. †
Increase your Auto Scaling group’s number of max servers.
C. †
Create a script that runs and monitors your servers; when it detects an anomaly in load, it posts to an Amazon SNS topic that triggers
Elastic Load Balancing to add more servers to the load balancer.
D. †
Push custom metrics to CloudWatch? for your application that include more detailed information about your web application, such as
how many requests it is handling and how many are waiting to be processed.
E. †
Update the CloudWatch? metric used for your Auto Scaling policy, and enable sub-minute granularity to allow auto scaling to trigger
faster.
翻訳 †
測定基準分析の間、あなたのチームは、会社のウェブサイトが
ピーク時間中に予想以上の応答時間を経験していると判断しました。あなたは現在
ピークスケールの間にあなたの環境を拡大縮小していることを確認するために自動拡大縮小に頼っています。この高い応答時間を短縮するために、Auto Scalingポリシーをどのように改善することができますか
2つの答えを選んでください。
A. †
カスタムメトリクスをCloudWatch?にプッシュして、サーバからのCPUとネットワークの帯域幅を監視します。これにより、Auto Scaling
ポリシーの詳細な洞察が可能になります。
B. †
Auto Scalingグループの最大サーバー数を増やします。
C. †
サーバーを実行および監視するスクリプトを作成します。負荷の異常を検出すると、Amazon SNSトピックに投稿して
Elastic Load Balancingを起動し、ロードバランサーにサーバーを追加します。
D. †
アプリケーションのカスタムメトリクスをCloudWatch?にプッシュします。これには、Webアプリケーションに関するより詳細な情報
（処理されているリクエストの数や処理されるのを待っている数など）が含まれます。
E. †
Auto Scalingポリシーに使用されているCloudWatch?メトリックスを更新し、1分単位の細分性を有効にして、Auto Scalingを
より高速にトリガーできるようにします。
解説 †
回答は「B」と「D」
問題に対して自動スケーリングが既に使用されているのは、「自動スケーリング・グループに割り当てられているインスタンス数が少ない」かもしれないので、Bが良い選択肢です。他にできることは、処理中のリクエストを監視することです。そのため、他の選択肢はDです。
Eは高速にスケールする方法ですが、根本解決とは別と思います。
Question8 †
原文 †
翻訳 †
経営陣は、アマゾンウェブサービスからの毎月の請求書の増加を報告しました、そして、彼らは
この増加したコストに非常に心配です。この増加の正確な原因を特定するように、管理者から依頼されました。見直し後
の課金レポートを、あなたは、データ転送コストの増加に気づきます。どのようにして管理者に
データ転送の使用に関するより良い洞察を提供できますか。
A. †
Amazon CloudWatch?メトリクスを5秒単位で更新してください。これ
により、請求データと組み合わせることでより詳細なメトリクスが得られ、異常を特定できます。
B. †
Amazon CloudWatch? Logsを使用してログのmap-reduceを実行し、使用率の高いデータ転送を決定します。
C. †
アプリケーションごとにカスタムメトリクスをAmazon CloudWatch?に配信します
。これにより、アプリケーションデータの転送が複数のより具体的なデータポイントに分割されます。
D. †
Amazon CloudWatch?メトリックスを使用して、毎月のElastic Load Balancingアウトバウンドデータ転送メトリックスを取得し、それらを
請求レポートに含めて、どのアプリケーションがより高い帯域幅使用を引き起こしているかを示します。
解説 †
回答：C
Question9 †
原文 †
翻訳 †
現在、Auto Scalingグループの背後にあるAmazon EC2インスタンスでインフラストラクチャを実行しています。>アプリケーションのすべてのログ
は現在、一時ストレージに書き込まれています。最近あなたの会社
はテストを通してそれを作り、そして最終的にあなたの艦隊に配備されたコードの大きなバグを経験しました。このバグにより、Auto Scalingグループが
サーバーからログを正常に取得できるようになる前にスケールアップおよびスケールダウンして、バグのトラブルシューティングに役立てることができました。
インスタンスが停止した後にログを確認できるようにするためにどの方法を使用する必要がありますか？
A. †
Auto Scalingグループの一時ポリシーを終了時にバックアップするように設定します。
B. †
終了時にすべての一時ストレージのスナップショットを作成するようにAuto Scalingポリシーを設定します。
C. †
AMIにCloudWatch? Logs Agentをインストールし、ログをストリーミングするようにCloudWatch? Logs Agentを設定します。
D. †
CloudWatch?モニタリングエージェントをAMIにインストールし、CloudWatch?モニタリングエージェント
が一時ドライブ上のすべてのログをバックアップするようにトリガーするCloudWatch?メトリックスの新しいSNSアラートを設定します。
E. †
CloudWatch?モニタリングエージェントをAMIにインストールし、自動スケーリングポリシーを更新してCloudWatch? Logの自動コピーを有効にします。
解説 †
回答：C
EC2停止時にバックアップ、スナップショットをとる機能はないです。リアルタイム処理に近いものが選択される。クラウドウォッチモニタリングエージェントはちょっと意味が分からない。
Question10 †
原文 †
翻訳 †
現在作業しているプロジェクトは、単一のAWS CloudFormation?テンプレートを使用して、
多層WebアプリケーションをサポートするAWSインフラストラクチャをデプロイします。AWS CloudFormation?リソースを
将来維持できるように、またNetworkingやSecurityなどのさまざまな部署
が本番に入る前にそのアーキテクチャを確認できるように、それらを整理することが課題でした。
既存のワークフローを使用して、各部門に対応する方法でこれをどのように行う必要がありますか。
A. †
VPCサブネット
とネットワーク用のルーティングルール、セキュリティグループ、セキュリティ用のIAM情報など、関連するリソースがテンプレート内で隣同士になるようにAWS CloudFormation?テンプレートを編成します。
B. †
AWS CloudFormation?テンプレートを、
さまざまな部署によって管理されるリソース用の個々のテンプレートを含むネスト構造に分離し、
制御するアプリケーションテンプレートのネットワークスタックとセキュリティスタックからの出力を使用します。
C. †
各部門の
用途に合わせて関連するリソースがテンプレート内で互いに隣り合うようにAWS CloudFormation?テンプレートを編成し、既存の継続的統合ツールを活用してすべての関係者から本番環境に変更を絶えずデプロイしてから
検証のテストを実行します。
D. †
カスタムアプリケーションとAWS SDKを使用して現在のAWS CloudFormation?テンプレートで定義されているリソースを複製し
、既存のコードレビューシステムを使用して他の部門が将来のデプロイ用にアプリケーションを変更する前に変更を承認できるようにします。
解説 †
回答：B
世の中の人を信じます。
Question11 †
原文 †
翻訳 †
運用チームと開発チームは、オペレーティングシステムとアプリケーションの両方のログを1か所で確認したいと考えています。
AWSサービスを使用してこれをどのように実装する必要がありますか？（2つ選んでください。）
A. †
AWS CloudFormation?を使用してCloudWatch? Logs LogGroup?を作成
し、CloudWatch? Logs Agentを使用して対象となるオペレーティングシステムとアプリケーションのログを送信します。
B. †
AWS CloudFormation?と設定管理を使用して、UDPパケットを介してCloudTrail?にイベントを送信するようにリモートロギングを設定します。
C. †
設定管理を使用し
て、利用可能な分析ツールに応じて、リモートロギングを設定してAmazon Kinesisにイベントを送信し、それらをAmazon CloudSearch? またはAmazon Redshiftに挿入します。
D. †
AWS CloudFormation?を使用して、CloudWatch? Logs LogGroup?を作成します。
Cloudwatch Logエージェントはすべてのオペレーティングシステムログを自動的に送信するので、
オフマシン送信用にアプリケーションログを設定するだけで済みます。
E. †
AWS CloudFormation?を使用して、アプリケーションログをオペレーティングシステムのログとマージし、IAMロールを使用して両方のチームが
Amazon EC2からのコンソール出力を表示できるようにします。
解説 †
回答：A、C
Cはなぜ正解かわからないが、消去法的に。
E：マージする必要なし。D：自動送信しない。B：そんなことしない。
Question12 †
原文 †
翻訳 †
Amazon Simple Queue Service（SQS）
キューからのメッセージを処理するインスタンスのAuto Sealingグループがあります。グループはキューのサイズに応じて調整されます。処理第三者のWebサービスを呼び出すことを含みます。Webサービス
は、それがあなたから受けている失敗して繰り返された呼び出しの数について不平を言っています。あなたはときことに気づいた
グループは、中スケール、彼らが処理している間、インスタンスが終了されています。
不完全なプロセス試行の回数を減らすために、どのような費用対効果の高いソリューションを使用できますか？
A. †
Webプロキシソフトウェアを実行しているインスタンスの最小数と最大数が2で、新しいAuto Scalingグループを作成します。
HTTPトラフィックをこれらのWebプロキシにルーティングするようにVPCルートテーブルを設定します。
B. †
インスタンス上で実行中のアプリケーションを変更して、タスクの処理中に終了保護を有効にし、
処理が完了したら無効にします。
C. †
Auto Scalingグループの最小サイズと最大サイズを増やし、動的に拡大縮小されないように拡大縮小ポリシーを変更します。
D. †
インスタンスで実行中のアプリケーションを変更して、タスクの処理中に自分自身をAuto Scaling Standby状態
にし、処理が完了すると自分自身をInService?に戻す。
解説 †
正解はD
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection
Question13 †
原文 †
翻訳 †
あなたのモバイルアプリケーションは、起動時に何万人ものユーザーを期待している写真共有サービスを含んでいます。あなたがなり
、ユーザの画像の保存のためにアマゾンシンプルなストレージサービス（S3）を活用し、あなたが認証する方法を決定する必要があり
、これらの画像にアクセスするためのユーザーを認証します。これらの画像の保存も管理する必要があります。次の2つの
うちどちらを使用しますか。（2つ選んでください。）
A. †
ユーザーごとにAmazon S3バケットを作成し、アプリケーションを使用して適切なコンテンツのS3 URIを生成します。
B. †
AWS Identity and Access Management（IAM）ユーザーアカウントをアプリケーションレベルのユーザーデータベースとして使用
し、アプリケーションコードから認証の負担を軽減します。
C. †
アプリケーションレベルでユーザーを認証し、AWS Security Token Service（STS）を使用してトークンベースの承認をS3
オブジェクトに付与します。
D. †
アプリケーションレベルでユーザーを認証し、SMSトークンメッセージをユーザーに送信します。
SMSメッセージトークンと同じ名前のAmazon S3バケットを作成し、ユーザーのオブジェクトをそのバケットに移動します。
E. †
単一のAmazon S3バケット内のすべてのユーザーオブジェクトのユーザーIDから構成されるキーベースの命名スキームを使用します。
解説 †
回答：C、E
SMSはマイグレーションサービスですね。
Question14 †
原文 †
翻訳 †
AWSでホストされているアプリケーションで負荷テストを行っています。Amazon RDS MySQL DB
インスタンスをテストしているときに、100％CPU使用率に達すると、アプリケーションが応答しなくなることがわかります。あなたの
アプリケーションは読み取りが重いです。アプリケーションのニーズに合わせてデータ層を拡張する方法は何ですか？（3つ選んでください。）
A. †
Amazon RDS DB読み取りレプリカを追加して、アプリケーションから直接読み取りクエリを受け取るようにします。
B. †
Amazon RDS DBインスタンスをAuto Scalingグループに追加し、CPU使用率に基づいてCloudWatch?メトリクスを設定します。
C. †
Amazon SQSキューを使用して、Amazon RDS DBインスタンスに送信されるデータを絞り込みます。
D. †
Amazon RDS DBの前でElastiCache?を使用して一般的なクエリをキャッシュします。
E. †
複数のAmazon RDS DBインスタンス間でデータセットを分割します。
F. †
Amazon RDS DBインスタンスに対してマルチAZを有効にします。
解説 †
回答：A、D、E
A：レプリカ、D：キャッシュ、E：シャード
Question15 †
原文 †
翻訳 †
バージョン管理の変更をポーリング
してから、一連のビルドテストのために新しいAmazon EC2インスタンスを起動する継続的インテグレーションアプリケーションを管理しています。
できるだけ多くのテストを可能な限り並行して実行できるようにしながら、全体的なコストを最低限に抑えるにはどうすればよいですか。
A. †
ビルドテスト、ユニットテスト、
統合テストのために新しいAmazon EC2インスタンスを起動する前に、継続的インテグレーションシステムで構文チェックを実行してください。
B. †
新しいAmazon EC2インスタンスユニットと
統合テストを開始する前に、構文を実行し、継続的統合システムでテストを構築します。
C. †
単体テスト、統合、およびビルドテストにAWS OpsWorks?を使用して、継続的インテグレーションシステムですべてのテストを実行します。
D. †
ユニットの出力、統合、およびビルドテストを調整するための新しいAWS Data Pipelineを起動する前に、継続的インテグレーションシステムで構文チェックを実行します。
解説 †
回答：B
暗記。
Question16 †
原文 †
翻訳 †
あなたはEコマースストアを管理するためにElastic Beanstalkを使用しています。このストアは、オープンソースのeコマース
プラットフォームに基づいており、Auto Scalingグループ内の複数のインスタンスにまたがって配置されています。あなたの開発チームはしばしば
Eコマースストアのための新しい「拡張機能」を作ります。これらの拡張機能には、PHPのソースコード
と、データベーススキーマに必要な更新を加えるためのSQLアップグレードスクリプトが含まれています。
SQLアップグレードスクリプトを実行すると、一部の拡張機能の展開がエラーにより失敗することに気付きました。さらに調査した結果、これは、SQL
スクリプトがすべてのAmazon EC2インスタンスで実行されているためです。SQLスクリプトのみが実行されるようにするにはどうすればよいですか
一度にいくつのAmazon EC2インスタンスが実行されているかにかかわらず、デプロイごとに1回ですか。
A. †
Elastic Beanstalk設定ファイル内で「コンテナコマンド」を使用してスクリプトを実行し、「リーダーのみ」フラグが
trueに設定されていることを確認してください。
B. †
Auto ScalingグループでAmazon EC2メタデータサービスを使用して、インスタンスがリーダーとしてマークされているかどうかをクエリします。
「true」が返された場合にのみスクリプトを実行します。
C. †
Elastic Beanstalk設定ファイル内で「Solo Command」を使用してスクリプトを実行します。
Elastic Beanstalkサービスは、コマンドが一度だけ実行されるようにします。
D. †
Auto Scalingグループ内の単一インスタンスからの書き込みアクセスのみを許可するようにAmazon RDSセキュリティグループを更新します。そのようにして、1つの
インスタンスだけがデータベース上でスクリプトを正常に実行します
解説 †
回答：A
暗記
Question17 †
原文 †
翻訳 †
現在のログ分析アプリケーションでは、Web
アプリケーションの上位10人のユーザーのレポートを生成するのに4時間以上かかります。この情報をリアルタイムで
報告し、その報告が常に最新のものであることを確認し、Webアプリケーションへの要求数の増加に対処できるシステムを実装するよう求められました。
費用対効果が高く、要件を満たすことができるオプションを選択してください。
A. †
CloudWatch? Logsにデータを公開し、負荷をオンデマンドで処理できるようにアプリケーションを自動スケーリングするように設定します。
B. †
ログデータをAmazon S3バケットに公開します。
AWS CloudFormation?を使用し
て、Amazon S3に保存されているログファイルをプルダウンするように設定されている後処理アプリケーションを拡張するためのAuto Scalingグループを作成します。
C. †
ログデータをAmazon Kinesisデータストリームに投稿し、ログデータを処理するように設定されたログ処理アプリケーションを購読します
。
D. †
Amazon EMRダスターのサイズを増やすためにAuto Scalingグループを設定します。
E. †
マルチAZのAmazon RDS MySQLクラスターを作成し、ロギングデータをMySQLに送信し、map reduceジョブを実行
してユーザー数に関する必要な情報を取得します。
解説 †
回答：C
リアルタイム性
Question18 †
原文 †
翻訳 †
前四半期の毎月の請求書を確認した後、経営陣はAmazonからの全体的な請求書の増加に気付いた。後は
、コストの増加を研究し、あなたの新しいサービスの一つがGETにバケットAPI呼び出しをたくさんやっていることを発見し
たアプリケーションバケット内のすべてのオブジェクトのメタデータキャッシュを構築するためにAmazon S3の。あなたの上司はあなた
にこれらの新しいGETバケットAPI呼び出しの量を減らすのを助けるために新しい費用効果的な方法を考え出すようにあなたに頼みました。
コストを軽減するためにどのようなプロセスを使用するべきですか？
A. †
Amazon S3バケットのライフサイクルポリシーを更新して、オブジェクトのリストを新しいバケットに自動的にプッシュし、このリストを使用
してアプリケーションのバケットに関連付けられているオブジェクトを表示します。
B. †
新しいDynamoDBテーブルを作成します。新しいDynamoDBテーブルを使用して、Amazon S3にアップロードされたすべてのオブジェクトに関するすべてのメタデータを保存します。
新しいオブジェクトがアップロードされるたびに、DynamoDBからアプリケーションの内部Amazon S3オブジェクトメタデータキャッシュを更新します。
C. †
Amazon SNSを使用して、新しいDynamoDBテーブルを自動的に更新し
て新しいオブジェクトに関するすべてのメタデータを格納する、新しいAmazon S3オブジェクトに関する通知を作成します。
アプリケーションをAmazon SNSトピックにサブスクライブして、DynamoDBテーブルから内部のAmazon S3オブジェクトメタデータキャッシュを更新します。
D. †
すべての画像をAmazon SQSにアップロードし、すべての画像をAmazon S3に移動するようにSQSライフサイクルを設定し
、アプリケーションにAmazon SNS通知を送信してアプリケーションの内部Amazon S3オブジェクトメタデータキャッシュを更新します。
E. †
すべての画像をElastiCache?ファイルキャッシュサーバーにアップロードします。ElastiCache?ファイルキャッシュ
サーバーからすべてのファイルメタデータを読み取るようにアプリケーションを更新し、長期保存のためにすべてのファイルをAmazon S3にプッシュするようにElastiCache?ポリシーを構成します。
解説 †
回答：C
世の中、BとCで迷っているようだ。
Question19 †
原文 †
翻訳 †
継続的な展開プロセスの一環として、アプリケーションは
新しいAMIを使用して本番環境に展開される前に、I / O負荷パフォーマンステストを受けます。アプリケーションは
インスタンスごとに1つのAmazon Elastic Block Store（EBS）PIOPSボリュームを使用し、一貫したI / Oパフォーマンスを必要とします。I / O負荷
パフォーマンステストで正しい結果が再現可能な方法で得られるようにするには、次のうちどれを実行する必要がありますか？
A. †
テスト用のI / Oブロックサイズがランダムに選択されていることを確認してください。
B. †
テスト前にすべてのブロックを読み取ることによって、Amazon EBSボリュームが事前に温められていることを確認します。
C. †
Amazon EBSボリュームのスナップショットがバックアップとして作成されていることを確認します。
D. †
Amazon EBSボリュームが暗号化されていることを確認します。
E. †
テストの前にボリュームのスナップショットを作成して、Amazon EBSボリュームが事前に暖められていることを確認します。
解説 †
回答：B
Question20 †
原文 †
翻訳 †
あなたの開発チームは、非常に
安全な環境のライブデバッグをするために、本番インスタンスへのアカウントレベルのアクセスを望んでいます。次のうちどれをしますか？
A. †
Amazon Elastic Compute Cloud（EC2）から提供された認証情報を
、暗号化を有効にした安全なAmazon Sample Storage Service（S3）バケットに配置します。
各開発者にAWS Identity and Access Management（IAM）ユーザーを割り当てて、認証情報ファイルをダウンロードできるようにします。
B. †
顧客鍵と構成
管理を使用したサーバー側の暗号化を使用して、内部で作成された秘密鍵を安全なS3バケットに配置し、この秘密鍵を使用してすべてのインスタンスにサービスアカウントを作成し
ます。ファイル。
C. †
各開発者自身の公開鍵をプライベートS3バケットに配置し、インスタンスプロファイルと設定管理を使用して、
すべてのインスタンスで各開発者用のユーザーアカウントを作成し、ユーザーの公開鍵を適切なアカウントに配置します。
D. †
Amazon EC2によって提供された認証情報をMFA暗号化USBドライブに配置し
、秘密鍵が会社から出ないように各開発者と物理的に共有します。
解説 †
回答：C
アカウントレベルで分離できるものはこれのみ。
参考：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-key-pairs.html
Question21 †
原文 †
翻訳 †
ネットワーク、IAMポリシー、および複数の3層アプリケーションを含む複雑なシステムがあります。あなたはまだ
新しいシステムの要件を受けているので、最終的な
設計にいくつのAWSコンポーネントが含まれるのかまだわかりません。AWS CloudFormation?を使用してこれらのAWSリソースを定義し
、インフラストラクチャを自動化およびバージョン管理できるようにします。AWS CloudFormation?を使用
して、費用対効果が高く信頼性の高い方法で、アジャイルな新しい環境を顧客に提供するにはどうすればよいですか。
A. †
システムに必要なすべてのリソースを網羅するために1つのテンプレートを手動で作成するので、
バージョン管理用のテンプレートは1つだけです。
B. †
システムの各論理部分に対して複数の個別のテンプレートを作成し、AWS CloudFormation?でネストされたスタックを作成
し、バージョン管理のためにいくつかのテンプレートを維持します。
C. †
システムの各論理部分に対して複数の個別のテンプレートを作成し
、SDKを実行しているAmazon Elastic Compute Cloud（EC2）インスタンスを使用して次から次への出力を提供して、よりきめ細かい制御を行います。
D. †
Amazon Virtual Private Cloud（VPC）を使用して手動でネットワーク層を構築します。これは頻繁には変更されないため、
AWS CloudFormation?を使用して他のすべての一時リソースを定義します。
解説 †
回答：B
Question22 †
原文 †
翻訳 †
開発チームと毎日スクラムした後、Blue / Greenスタイルの展開を使用
するとチームに利益があることに同意しました。この新しい要件を満たすためにどのテクニックを使うべきですか？
A. †
AWS Elastic Beanstalkにアプリケーションを再デプロイし、Elastic Beanstalkのデプロイメントタイプを利用します。
B. †
AWS CloudFormation?テンプレートを使用して、ロードバランサーの背後にアプリケーションを再デプロイし、
各デプロイ中に新しいAWS CloudFormation?スタックを起動し、検証中
にロードの更新後にテスト中にトラフィックの半分を新しいスタックに送信するようにロードバランサーを更新しますトラフィックの100％を新しいスタックに送信してから古いスタックを終了するためのバランサ。
C. †
Auto Scalingグループを使用するロードバランサの背後にアプリケーションを再デプロイし、新しい同一のAuto Scalingグループを作成し、
それをロードバランサに関連付けます。展開中に、古いAuto Scalingグループの希望するインスタンス数を0に設定し
、すべてのインスタンスが終了したら、古いAuto Scalingグループを削除します。
D. †
AWS OpsWorks?スタックを使用して、アプリケーションをElastic Load Balancingロードバランサーの背後に再デプロイし、
OpsWorks?スタックのバージョン管理を利用します。デプロイ中に、アプリケーションの新しいバージョンを作成し、OpsWorks?に
ロードバランサーの背後に新しいバージョンを起動するよう指示します。そして新しいバージョンが起動したら、古いOpsWorks?スタックを終了します。
解説 †
回答：A
Question23 †
原文 †
翻訳 †
Webアプリケーションの主な監視システムとしてAmazon CloudWatch?を使用します。最近のソフトウェアの
導入後、Webアプリケーションを使用しているときに、ユーザーに断続的な500の内部サーバーエラーが発生しています。
CloudWatch?アラームを作成し、これらが発生したときにオンコールエンジニアに通知します。AWS
サービスを使用してこれをどのように達成できますか？（3つ選んでください。）
A. †
WebアプリケーションをAWS Elastic Beanstalkアプリケーションとしてデプロイします。
デフォルトのElastic Beanstalk Cloudwatchメトリックスを使用して500の内部サーバーエラーをキャプチャします。
そのメトリックスにCloudWatch?アラームを設定します。
B. †
サーバーにCloudWatch? Logs AgentをインストールしてWebアプリケーションログをCloudWatch?にストリーミングする。
C. †
CloudWatch?アラームがトリガーされたときにAmazon Simple Email Serviceを使用してオンコールエンジニアに通知します。
D. †
CloudWatch? Logsグループを作成し、500個の内部サーバーエラーをキャプチャするメトリックスフィルタを定義します。
そのメトリックスにCloudWatch?アラームを設定します。
E. †
CloudWatch?アラームがトリガーされたときにAmazon Simple Notification Serviceを使用してオンコールエンジニアに通知します。
F. †
AWS Data Pipelineを使用して、サーバーからCloudWatch?にウェブアプリケーションログをストリーミングします。
解説 †
回答：B、D、E
Question24 †
原文 †
翻訳 †
Elastic Load Balancing HTTPヘルスチェックを有効にしました。AWSマネジメントコンソールを
確認すると、すべてのインスタンスがヘルスチェックに合格していますが、お客様のサイトは応答していないと報告しています。
原因は何ですか？
A. †
HTTPヘルスチェックシステムは、インスタンス間メタデータ同期の待ち時間が原因で誤って報告されています。
B. †
実施されているヘルスチェックがアプリケーション機能を十分に評価していない。
C. †
アプリケーションは、AWSマネジメントコンソールが応答するには早すぎるポジティブヘルスチェックを返しています。
D. †
DNS解決の待ち時間がAmazon EC2メタデータの取得を妨げています。
解説 †
回答：B
Question25 †
原文 †
翻訳 †
Auto ScalingグループがAmazon Elastic Compute Cloud（EC2）で実行されている場合、アプリケーション
は10分以内のウィンドウ内での負荷に応じて急速に拡大/ 縮小します。ただし、負荷がピークに達した後は
、以前に終了したAmazon EC2リソースがまだアクティブとして表示されているという構成管理システムでの問題が発生し始めます。
構成
管理システム内のAmazon EC2リソースのクリーンアップを処理するための信頼性が高く効率的な方法は何でしょうか。（2つ選んでください。）
A. †
Amazon EC2インスタンス上で毎日のcronジョブによって実行され、EC2 Auto Scaling
グループのAPI Describe呼び出しを実行し、終了したインスタンスを構成管理システムから削除するスクリプトを作成します。
B. †
Auto Scalingアクション用にAmazon Simple Queue Service（SQS）キューを
構成します。このスクリプトには、新しいメッセージを待機し、構成管理システムから終了したインスタンスを削除するスクリプトがあります。
C. †
既存の構成管理システムを使用してインスタンスの起動とブートストラップを制御
し、自動化における可動部分の数を減らす。
D. †
Amazon EC2インスタンスのシャットダウン中に実行される小さなスクリプトを作成して、構成管理
システムからリソースの登録を解除します。
E. †
Amazon Simple Workflow Service（SWF）を使用して、
以前に起動されたインスタンスのホワイトリストを含むAmazon DynamoDBデータベースを維持し、Amazon SWFワーカーが構成管理システムから情報を削除できるようにします。
解説 †
回答：A、D
Question26 †
原文 †
翻訳 †
Amazon EC2インスタンスでアプリケーションを実行していて、AWS
サービスAPI に安全にアクセスするためにIAMロールを使用しています。
AWS SDK で使用するAPIキーを取得するように、そのインスタンスで実行されているアプリケーションをどのように設定できますか？
A. †
コンソールでインスタンスにEC2 IAMロールを割り当てるときは、[Chosen SDK]ドロップダウンリストで、使用しているSDKを選択する
と、インスタンスは起動時にAPIキーを使用して正しいSDKを設定します。
B. †
アプリケーションコード内で、IAMサービスAPIにGETリクエストを発行してユーザーの認証情報を取得します。
C. †
AWS SDKおよびAmazon EC2ロールを使用する場合、SDK
はAmazon EC2 MetaData?サービスからの取得を処理するため、APIキーを明示的に取得する必要はありません。
D. †
アプリケーションコード内で、環境変数からAPIキーを取得するようにAWS SDKを設定します
。AmazonEC2ロールを割り当てると、起動時にキーが環境変数に格納されるためです。
解説 †
回答：C
Question27 †
原文 †
翻訳 †
AWS OpsWorks?を使用してスケーラブルな分散システムをデプロイするという課題がありました。分散システムは
要求に応じて拡張する必要があります。配布されるとき、各ノード
はレイヤー内の他のインスタンスのホスト名を含む設定ファイルを保持しなければなりません。このアプリケーションの拡張を
動的に管理するようにAWS OpsWorks?をどのように設定する必要がありますか？
A. †
この設定ファイルを更新するためのChef Recipeを作成し、カスタムクックブックを使用するようにAWS OpsWorks?スタックを
設定し、このレシピを特定のレイヤーのConfigure LifeCycle? Eventに割り当てます。
B. †
AWS OpsWorks?サービスAPIに新しいインスタンスをポーリングするスクリプトを記述して、この設定ファイルを更新します。
オペレーティングシステムの起動時にこのスクリプトを実行するようにベースAMIを設定します。
C. †
この設定ファイルを更新するChef Recipeを作成し、カスタムクックブックを使用するようにAWS OpsWorks?スタックを設定し、
インスタンスが起動したときに実行するようにこのレシピを割り当てます。
D. †
分散ホスト設定にAWS提供のレシピを使用するようにAWS OpsWorks?レイヤを
設定し、レシピ設定でインスタンスのホスト名とファイルパスのパラメータを設定します。
解説 †
回答：A
Question28 †
原文 †
翻訳 †
ロードバランサーの背後には、Auto Scalingグループ内に多数のWebサーバーがあります。1時間ごとに、
ログをフィルタリングして処理して一意の訪問者に関するデータを収集してから、
レポートを実行するためにそのデータを永続的なデータストアに格納します。Auto ScalingグループのWebサーバーは常にスケーリング
ポリシーに基づいて起動および終了していますが、ユーザー
またはAuto Scalingによって開始または終了されたときにこれらのサーバーからログデータを失うことは避けたいです。どのような2つのアプローチがこれらの要件を満たすでしょうか？（2つ選んでください。）
A. †
ブートストラッププロセス中にすべてのWebサーバーにAmazon Cloudwatch Logsエージェントをインストールします。
CloudWatch?ロググループを作成し、ストリーミングウェブ
サーバーログからユニークビジターを追跡するカスタムメトリックスを作成するためにメトリックスフィルターを定義します。
1時間ごとに実行されるAmazon EC2インスタンスでスケジュールされたタスクを作成し、Cloudwatchカスタム
メトリックスに基づいて新しいレポートを生成します。
B. †
Webサーバー上で、ログをローテーションしてAmazon Glacierに送信するスクリプトを実行するスケジュールタスクを作成します。
Amazon EC2インスタンスが
停止または終了したときに、オペレーティングシステムのシャットダウン手順によってログの送信がトリガーされるようにします。
Amazon Glacierでデータを処理し、1時間ごとにレポートを実行するには、Amazon Data Pipelineを使用します。
C. †
Webサーバー上で、ログをローテーションしてAmazon S3バケットに送信するスクリプトを実行するスケジュールタスクを作成します。
Amazon EC2インスタンスが
停止または終了したときに、オペレーティングシステムのシャットダウン手順によってログの送信がトリガーされるようにします。
AWS Data Pipelineを使用して、レポートを1
時間ごとに処理して実行するために、ログデータをAmazon S3バケットからAmazon Redshiftに移動します。
D. †
ブートストラッププロセス中にすべてのウェブサーバーにAWS Data Pipelineログエージェントをインストールします。
AWS Data Pipelineでロググループオブジェクトを作成し、処理されたログデータをWebサーバーから
Amazon Redshiftに直接移動し、1時間ごとにレポートを実行するためのメトリックスフィルタを定義します。
解説 †
回答：A、C
Question29 †
原文 †
翻訳 †
解説 †
Question30 †
原文 †
翻訳 †
解説 †
Question31 †
原文 †
翻訳 †
解説 †
Question32 †
原文 †
翻訳 †
解説 †
Question33 †
原文 †
翻訳 †
解説 †
Question34 †
原文 †
翻訳 †
解説 †
Question35 †
原文 †
翻訳 †
解説 †
Question36 †
原文 †
翻訳 †
解説 †
Question37 †
原文 †
翻訳 †
解説 †
Question38 †
原文 †
翻訳 †
解説 †
Question39 †
原文 †
翻訳 †
解説 †
Question40 †
原文 †
翻訳 †
解説 †
Question41 †
原文 †
翻訳 †
解説 †
Question42 †
原文 †
翻訳 †
解説 †
Question43 †
原文 †
翻訳 †
解説 †
Question44 †
原文 †
翻訳 †
解説 †
Question45 †
原文 †
翻訳 †
解説 †
Question46 †
原文 †
翻訳 †
解説 †
Question47 †
原文 †
翻訳 †
解説 †
Question48 †
原文 †
翻訳 †
解説 †
Question49 †
原文 †
翻訳 †
解説 †
Question50 †
原文 †
翻訳 †
解説 †
Question51 †
Question52 †
Question53 †
Question54 †
Question55 †
Question56 †
Question57 †
Question58 †
Question59 †
Question60 †
Question61 †
Question62 †
Question63 †
Question64 †
Question65 †
Question66 †
Question67 †
Question68 †
Question69 †
Question70 †
Question71 †
Question72 †
Question73 †
Question74 †
Question75 †
Question76 †
Question77 †
Question78 †
Question79 †
Question80 †
Question81 †
Question82 †
Question83 †
Question84 †
Question85 †
Question86 †
Question87 †
Question88 †
Question89 †
Question90 †
Question91 †
Question92 †
Question93 †
Question94 †
Question95 †
Question96 †
Question97 †
Question98 †
Question99 †
Question100 †
最新の20件
2019-01-08
2018-12-20
今日の3件
- counter: 176
- today: 1
- yesterday: 0
- online: 1
