Active study with AWS using S3

Flashcards and scripts

Previously we created our flashcards on higher level concepts. That’s all well and good, and a lot of the time to pass the exam we’ll need a breadth of knowledge more than a depth of knowledge.

However, to really get to grips with things, we’re gonna have to roll up our sleeves and get into the code. And the more involved you are with something personally, the better you’ll understand and remember it. I can’t upload my AWS Knowledge to your brain, although I’ll do my best to get you there quicker.

What we’re going to do is to take our lower-level learnings, and make flashcard from them too. This way we’ll have a mix of breadth and depth in our knowledge. And because we’re using a digital flashcard system, you can top-up your reminders whenever you get spare time.

I used to use my commutes to work for this exact purpose – it made the journey fly by and it didn’t matter that I couldn’t get a seat, as long as one hand had something to hold onto, the other hand could use Cram on a smartphone. Pretty effective use of time, right?

So let’s get started with that…

Understand the CLI

So if you’re doing a Developer Associate Course, I’m sure most of you are familiar with the general advantages of using the command line over a UI (or in the case of AWS, the console). If not, it’s around being able to script operations, and chain them together. Taking a human out of the equation as much as possible is desirable and it is less error prone (once written and tested) and frees them up to do other work.

We’ll get to grips with the CLI to start with – you won’t need flashcards for this bit.

Once you’ve got your CLI set up and read just the overview of config options, we can try and script a few things up, to build our deeper understanding of the CLI.

As you try things out, think of little quirks of AWS that surprised you, or what followed naturally from your assumptions – this is flashcard material that will build our foundations for the following weeks.

By having a set of scripts, we can save them off to github, to bitbucket etc and review them in later weeks. But we’re always looking to ‘build practice sets’ from concepts that we read about. Let’s see how that works next…

Learn how to check your assumptions

Let’s take the sections on configuring the AWS CLI. The section about creating a named profile seems interesting to me – perhaps a work and home set of credentials would work well.

So I can play around with all sorts of ideas here. I can see what worked and what didn’t. Let’s say I want to try to and create a new set of credentials for my account, associate with a profile “jimmy_new”, based on what I read from creating a named profile.

I try a few things out and when I’m finished, bash history is my friend: I’ve copied parts off to a text file and annotated with what I’ve learned.

history
  
  502  aws configure --profile jimmy_new #aborted, forgot to create keys in the AWS console first
  503  cat ~/.aws/credentials #double check what this looks like
  504  aws configure --profile jimmy_new #Try again
  509  aws s3 ls --profile =jimmy_new #doesn't use an equals when you list!!
  510  aws s3 ls --profile jimmy_new #that worked as expected, got a bucket back under my account

So what’s the point of this? Efficiency. You have to do the work anyway to learn about the CLI. Might as well leverage what you’ve done and make ‘truthful notes’ about your assumptions based on a running log of events.

You can take as much or as little as you need from your experimentation. You could:

• Write an annotated set of notes, as above, and upload to dropbox/github etc
• Convert commands into scripts – building yourself tooling and consolidating your learning that way.
• Taking what you learned and adding to your flashcard sets when you deem something important enough.

In the case of the last example, my experimentation yielded some questions and creating and updating profiles with the CLI. Then that got me thinking about the hierarchy of where values come from, and a third flashcard was created.

Understand the CLI – and create flashcards

Now you have some techniques to explore the CLI itself, and test your assumptions I’d recommend you familiarise yourself with the following, although you should feel free to explore more on your own:

These concepts of the CLI are important for troubleshooting day to day, and also for breaking down exam questions, so they’re worth spending time on. Also, questions on hierarchy and precedence have come up with other technologies, so it’s worth knowing it’s “a thing” within AWS.

Next we’ll take this even further and use testing frameworks to learn about the SDK.