Here’s my write-up of the official CSA example questions. Be aware that the provided answers are a personal interpretation and could have errors in them, Amazon do not provide the official correct answers.

Going through them is just a way to get a feel of the question format and shows the thought process of picking the right answers.

1) Amazon Glacier is designed for: (Choose 2 answers)

A. active database storage.
B. infrequently accessed data.
C. data archives.
D. frequently accessed data.
E. cached session data.

Correct answers are B and C. Glacier’s whole purpose is for data archival since it has lower cost storage compared to S3 or EBS, almost by the definition of an archive it’s only useful for infrequently accessed data, it provides retrieval times of several hours. This info immediately invalidates answers A, D and E.

2) Your web application front end consists of multiple EC2 instances behind an Elastic Load Balancer. You configured ELB to perform health checks on these EC2 instances. If an instance fails to pass health checks, which statement will be true?

A. The instance is replaced automatically by the ELB.
B. The instance gets terminated automatically by the ELB.
C. The ELB stops sending traffic to the instance that failed its health check.
D. The instance gets quarantined by the ELB for root cause analysis

Correct answer is C. This question basically tests if you understand the different responsibilities of the different components that provide Auto Scaling. The ELB itself is not responsible for anything else but determining to which instance it should or should not route traffic to. Answers A and B are incorrect since the ELB doesn’t take actions on EC2 instances, as explained it’s only responsible for health checks and routing. Answer D is basically a bogus answer since Quarantining is unheard of in this context.

What is Elastic Load Balancing
How Auto Scaling Works

3) You are building a system to distribute confidential training videos to employees. Using CloudFront, what method could be used to serve content that is stored in S3, but not publically accessible from S3 directly?

A. Create an Origin Access Identity (OAI) for CloudFront and grant access to the objects in your S3 bucket to that OAI.
B. Add the CloudFront account security group “amazon-cf/amazon-cf-sg” to the appropriate S3 bucket policy.
C. Create an Identity and Access Management (IAM) User for CloudFront and grant access to the objects in your S3 bucket to that IAM User.
D. Create a S3 bucket policy that lists the CloudFront distribution ID as the Principal and the target bucket as the Amazon Resource Name (ARN).

Correct answer is A. OAI is a special identity you can create for CloudFront distributions, you can assign the same OAI to multiple distributions. This OAI can then be used in your S3 bucket policies to restrict access to CloudFront only. Answer B is nonsense. Answer C is almost correct but an OAI is not an IAM user, answer D is also almost correct but you just can’t use a CloudFront distribution id as the Principal.

Using an OAI

4) Which of the following will occur when an EC2 instance in a VPC (Virtual Private Cloud) with an associated Elastic IP is stopped and started? (Choose 2 answers)

A. The Elastic IP will be dissociated from the instance
B. All data on instance-store devices will be lost
C. All data on EBS (Elastic Block Store) devices will be lost
D. The ENI (Elastic Network Interface) is detached
E. The underlying host for the instance is changed

Correct answers are B and E. Answer B is completely correct, instance storage or ephemeral store is lost on shutdown. Answer E is actually the only other answer that makes any sense but is still a bit weird since you don’t actually know for sure what goes on within EC2 but is the best answer by elimination. Answer A is simply untrue, Elastic IP’s will not be dissociated unless you explicitly do so. Answer C is exactly the opposite of the purpose of EBS backed storage. Answer D is simply untrue, ENI’s do not become detached on EC2 stop.

EC2 Instance Lifecycle

5) In the basic monitoring package for EC2, Amazon CloudWatch provides the following metrics:

A. web server visible metrics such as number failed transaction requests
B. operating system visible metrics such as memory utilization
C. database visible metrics such as number of connections
D. hypervisor visible metrics such as CPU utilization

Correct answer is D. This is actually a simple but brilliant question when you think about it, Answer D is correct since Amazon is only aware of the Hypervisor. Answers A, B and C imply that they are aware of things that run WITHIN the Hypervisor which is untrue. This question catches a lot of people off-guard since we see Memory Utilization for example as such an obvious metric we would assume it’s in any basic monitoring package.

6) Which is an operational process performed by AWS for data security?

A. AES-256 encryption of data stored on any shared storage device
B. Decommissioning of storage devices using industry-standard practices
C. Background virus scans of EBS volumes and EBS snapshots
D. Replication of data across multiple AWS Regions
E. Secure wiping of EBS data when an EBS volume is unmounted

Correct answer is B. This questions implicitly tests your knowledge of the Shared Responsibility Model that AWS uses for Security. Answer B falls within their responsibility so they take care of it, Answers A, C and D are the customer’s responsibility. Answer E is untrue since EBS data isn’t deleted after an unmount.

7) To protect S3 data from both accidental deletion and accidental overwriting, you should:

A. enable S3 versioning on the bucket
B. access S3 data using only signed URLs
C. disable S3 delete using an IAM bucket policy
D. enable S3 Reduced Redundancy Storage
E. enable Multi-Factor Authentication (MFA) protected access

Correct answer is A. Enabling versioning will allow you to recover from both accidental deletion and accidental overwriting.

S3 Versioning

I’ve been pretty busy these last months catching up on Amazon Web Services, since I’m not really fond of just aimlessly trying out random stuff I determined I needed a tangible goal.

Luckily I stumbled on a post on /r/aws offering a discount to this Udemy course. It’s entirely devoted to passing the AWS Certified Solutions Architect - Associate certification, since it’s quite a mouthful I’ll refer to this as CSA from now on.

The video lectures of this course consist of slides to cover off theory and hands-on practice labs for the real thing. You’ll need an AWS account with a valid credit card to do these labs, if you pay close attention to the AWS free tier rules it shouldn’t cost you a penny.

I first completed the entire course without doing any of the labs since for some reason my credit card for my new account didn’t get validated for weeks, a problem that was eventually swiftly resolved after I contacted AWS support. I did a second pass this time doing all the labs, read the recommended whitepapers, scheduled the exam and passed pretty comfortably.

Since apparently the CSA exam shares a lot of the material with the AWS Certified Developer maybe I’ll try to do that one as well in the near future.

By the way, I recently did a write-up to cover the official CSA example questions to share with some colleagues, I’ll share them in a separate post.


Microservices are all the rage for a while now but as usual it takes some time before books get published about a brand new buzzword, this proved to even more true with something as ill-defined as Microservices.

I just finished Sam Newman’s book called Building Microservices on the subject and I must say he did a heck of a job on giving somewhat of a definition and cover all relevant aspects.

Beware that the title could be somewhat misleading though, there are no code examples in this book nor are there any low-level implementation details. I would still very much consider it a technical book though, it references a lot of frameworks, cloud services and overall best practices.

Personally I found it to be very relevant and although I’m not a software architect I do aspire to be one and this is exactly the kind of book that can help me on my journey.

To indicate its relevancy here are just some of the referenced technologies of which I personally had the pleasure to be working with professionally this past year:

  • Amazon Web Services
  • Heroku
  • Node.js
  • Vagrant
  • RabbitMQ
  • JSON web tokens

Real-world familiarity with these technologies before reading this book is convenient and helps in understanding what the author is talking about but the most value lies in the concepts he introduces, some of them were fairly new to me so I’ll elaborate on two of them that looked particularly interesting to me:

Backends for frontends

On a recent project we somewhat struggled with a particular problem, roughly this project consisted of two components:

  • Single-page application (front-end)
  • Aggregation API (back-end)

The front-end talks to the back-end (duh) and the back-end in this case aggregates responses from various services all over the company. Although it was just one team building the entire application the team was kind of split between front- and back-end developers which makes sense given the technology discrepancy (JavaScript vs Java).

This aggregation API was also envisioned to serve as the endpoint of any future clients that might need to interact with this specific domain, and that decision was what eventually caused quite some frustration during development. We couldn’t just aggregate data in the most convenient way for the front-end, we had to keep in mind future clients and had to build a general domain specific API.

The “backends for frontends” (BFFs) pattern would’ve solved this problem, this pattern is all about building a back-end specifically for one particular front-end. No other clients should talk to this BFF, this would’ve been a lot more efficient and sounds even better if you let the front-end developers build their own back-end (Node.js anyone?).


Designing for failure is another important topic in this book and this concept was something that stuck with me while reading the book. For a thorough explanation of the concept check out Martin Fowler’s blog post but the idea boils down to building a circuit breaker that wraps any remote service call. If the remote call hits a pre-configured request error threshold the application will stop sending requests to the remote service. This way you can make sure valuable resources aren’t blocking on remote calls that have a high probability of failing.

A typical Java application container provides a great example of how this could prevent a catastrophe. Imagine a service deployed on such a container that talks to a dozen other remote services. The application container uses a thread per request it’s serving, if one remote service is simply not responding the thread will be blocked, preventing it from serving other requests. Under medium or high traffic this could cause the thread pool to become depleted pretty darn fast. Setting timeouts to any remote calls, which should be absolutely mandatory, helps a lot but under high traffic you would still waste a lot of capacity waiting for a response that just won’t come. To make matters worse, perhaps this particular service isn’t even all that important for the users of your application so it would be a shame if it was responsible of bringing down the entire thing.

Circuit-breakers will avoid these things so your application would still be functioning, perhaps with degraded functionality but functioning nonetheless. You could also consider making the circuit breaker even more intelligent by programming it to start sending some traffic back to the remote service after a while. Like testing the waters before resuming normal operations.


I really enjoyed this book, the author does well by providing a lot of real-life stories to back everything up. But as mentioned before, if you’re looking for implementation details you’re better off picking up other books that deal with the specific technologies. If however you’re looking for a thorough high-level view of what Microservices are all about look no further!