AWS 認定 Solution architect - Professional受験後のメモ

-

まえおき

このポストはQiitaに書いたAWS 認定 Solution architect - Professional受験後のメモを移したものです。

 

受験当時

当時のスペック

  • 入社2年目で、AWS関連業務を半分、それ以外の業務を半分やっています。

  • AWSを触って１年くらいでした。

    • ただ、主にCloudFormation、CodeCommit、Lambda,DynamoDB,SNSあたりで、ArchitectというよりDeveloperに近いサービスを触っていました。
    • ELB、DirectConnectなどはどういうサービスか理解しているくらいでした。
    • Organizationsはそこそこ触っていました。

  • Solution architect - Associateを取得して、6か月前に取得しました。

  • 一応、応用情報技術者試験(AP)も持っていました。

     

勉強方法

Advanced Architecting on AWSの受講(３日間)

  • Professionalの試験内容に沿って、講義を進めてくれます。

  • 業務では触たことないサービスを触ることができ、すごく役に立ちました。

  • グループディスカッションもとてもよかったです。

  • 私が受けた回はAWS触って１年未満の方が多かったのが印象的でした。

     

模擬試験を受験

  • Associateの合格の時にもらったバウチャーを利用しました。

  • 問題の傾向は把握できましたが、やはり不安だったのでUdemyで過去問を解きました。

  • ちなみに、結果は40％で不合格でした…

     

Udemyの過去問をし解く

qwiklabs

  • サブスクリプションを決済して、ProfessionalのQuestを実習しました。

  • 旧型式(2019年2月前の試験)の内容ですが、普段触ることないサービスを触ることができたのでよかったです。

     

さあ、受験へ

受験場所

  • webカメラで受験者を監視、英語のチャットで指示を受けるというテストセンターもあるようですが、私が受けたところは普通にPCで受験するようなところでした。(部屋はカメラで監視されていましたが)

     

試験について

  • 受験したのは3月だったので、ちょうど新しい形式の問題に変わったごろでした。

  • 170分で80分解くのはやはり大変でした。

    • 認定のページでは170分と書かれてますが、PSIサイトを見ると180分と表示されてますね。どっちが正しいんだろう…

  • 30分くらい残して全問題解いて、残りの時間は問題を見直してました。

  • 緊張したせいか、途中からトイレにいきたかったです…

     

結果

  • 合格でした。

  • 後に来たレポートを見ると770点のギリギリ合格でした。

    • 合格ラインは750点です。

  • 各カテゴリの評価は全部「十分な知識を有する」でした。とういうことは、どのカテゴリもギリギリ点数だったとういうことか…

     

感想

  • 3か月前のことなので忘れてしましたが、私の時は移行(migration)周りの問題が多かった印象でした。

  • 結果を達成するために、いくつがある方法で提示された条件(コストを抑えたいとか)から最適な方法を探す問題が多かったです。

    • なので、各方法の向き不向き(SnowballとSnowmobileの違いとか)を知るのが大事だと思います。

  • Organizations周りは業務での経験があったので、自信もって解けました。やはり、業務で直接触るのは大事ですね。

    • うまく説明できないんですが、qwiklabsなどの実習では、「こういう構成システムを作りましょうー」で単純に作っていて知識を覚えるだけですが、業務の場合は「このアカウントにこういう制限をつけたい」という目的があって、手段を考えて実施するのでより深く理解できるのかなと思いました。

  • 3年後にはもうちょっと高い点数で更新したいです！

     

出たサービス(覚えている限り)

  • organizations
  • snowball
  • directconnect
  • opswork
  • workflow
  • 暗号化(S3のカスタマー暗号化とサーバサイド暗号化)
  • storage gateway
  • cloudfront(キャッシュや証明書関連)
  • cloudtrail
  • cloudwatch
  • migrationサービス(SMSとかDMSとか)
  • kinesisとSQS
  • vpc peering
  • HSM
  • S3
  • リザーブドインスタンとスポットインスタンス
  • praivate link
  • elastic cache
  • ELBあたりとか
  • Route53
  • DDos関連は出なかった…(WAFとかshieldとか)

Popular Posts

CloudWatch EventsはAmazon EventBridgeになるらしい

-
イメージ
まえおき 　最近久々にCloudWatch Events(以下、Events)の画面を開いたら、以下のようなメッセージが出ていた。 グーグル翻訳先生に翻訳をお願いすると CloudWatch Events is now Amazon EventBridge Amazon EventBridge (formerly CloudWatch Events) provides all functionality from CloudWatch Events and also launched new features such as Custom event buses, 3rd party event sources and Schema registry to better support our customers in the space of event-driven architecture and applications. CloudWatch EventsがAmazon EventBridgeになりました Amazon EventBridge（以前のCloudWatch Events）は、CloudWatch Eventsのすべての機能を提供し、カスタムイベントバス、サードパーティイベントソース、スキーマレジストリなどの新機能も起動して、イベント駆動型のアーキテクチャとアプリケーションの領域でお客様をより適切にサポートします。 らしい。Amazon EventBridge(以下、EventBridge)がEventsの代わりになるということだった。いつから出たんだろう…。最近、画面のUIが変わりましたのメッセージが常にほぼどのサービスでも同じ感じで出ていたから全然気つかなかった…。今までは、EventBridgeというEventsと似ているサービスがあるということは知っていたけど、Eventsの機能で十分だったので特に気にしてなかった。調べてみると、ちょうど1年前に発表されたサービスだった。( Amazon EventBridge – SaaS アプリケーション用のイベント駆動型での AWS の統合 )   Cloudwatch EventsとAmazon EventBridgeの違い 　全く同じサービスであるというと若...
続きを読む

PythonのDict型をDynamoDB形式のJsonに変換する

-
pythonでDynamoDB関連操作をするとき、難しい点の一つは一つは以下のようなDynamoDBの独特なJSON形式だと思います。 { "id": { "N": 12345 }, "name": { "S": "TanakaTaro" } } Python用のAWS SDKであるBoto3にはDynamoDB形式のJsonをPythonのDictに変換できる TypeSerializer と TypeDeserializer があります。 https://boto3.amazonaws.com/v1/documentation/api/latest/_modules/boto3/dynamodb/types.html TypeSerializer PythonのDictをDynamoDB形式のJsonに変換します。個人的には変換結果で最初の{"M": ...}はなくしてほしいですが… TypeDeserializer DynamoDB形式のJsonをPythonのDictに変換します。こちらも一気に変換はできず、各Keyごとに変換が必要です。 まとめ＆蛇足 TypeSerializerとTypeDeserializerはDynamoDBのデータをpythonで処理したいときや処理後にまたDynamoDBにアップロードしたいときに有効に利用できそうです。 ただ、そのまま利用するよりは、利用しやすくカスタム関数やクラスを作成したほうがよさそうです。 JavaScriptのSDKにもConverterというものがあるようです https://aws.amazon.com/jp/blogs/developer/announcing-the-amazon-dynamodb-document-client-in-the-aws-sdk-for-javascript/
続きを読む

CloudFormationテンプレート内のStep functionsのState machine定義をS3に置けるようになった

-
イメージ
まえおき 今週あったチーム先輩(Aさん)との会話 私　：CloudFormationテンプレートにStepfunctionsを書こうとするとyamlにベタ書きしかできないんですよ。 　　　これが私がCDKを押す理由の一つなんですよ。 Aさん：LambdaみたいにS３バケットに定義ファイルを置いてそのパスをyamlに書けばいいじゃん。 私　：あれ?私が調べたときはそれができなかったので、今あるテンプレートはすべてベタ書きにしているんですが…。 Aさん：うん?これでできないんだけ？(CloudFormationのドキュメントURLを共有) 私　：できるじゃん!? 　送られてきた CloudFormationドキュメント を見ると、 DefinitionS3Location というプロパティがあった。おかしいな…調べたときは本当になかったんだようなーと思いずつ更新履歴を見ると、2020年5月20日更新。私が調べたのは1月ごろだったから、その時はなかったということだ。うーん、What's Newはほぼ毎日見るけど、使っているサービスのドキュメント更新履歴も頻繁にチェックしないといけないのかな…。とりあえず、試してみることにした。   DefinitionS3Locationを試してみる Step Functionsのテンプレートを準備 　State Machineの定義はAWSドキュメントの Getting Started with Step Functions にあるコードから最後のstateを少し変えた簡単な以下のコードを利用する。 DefinitionSubstitutions も使ってみたかったので。 DefinitionSubstitutions はテンプレート内で同時に作成されるリソースをState Machine内で利用する場合に使う。例えば、Lambdaを作成して、それをState machineに入れるとか。(LambdaのARNが必要になる)   　jsonファイルで保存し、S3のバケットに保存する。 　これでStep Functions側の準備は終わり。   CloudFormationテンプレートを準備 　 CloudFormationの StepFunctions::StateMachi...
続きを読む