EC2 Interview – AWS Interview – Cloud Interview – 8 Questions

If you're looking for a cloud expert, specifically someone who knows Amazon Web Services and EC2, you'll want to have a battery of questions to ask them to assess their knowledge.  As with any technical interview focus on concepts and big picture.  As the 37Signals folks like to say "hire for attitude, train for skill".  Absolutely!

1. Explain Elastic Block Storage?  What type of performance can you expect?  How do you back it up?  How do you improve performance?

EBS is a virtualized SAN or storage area network.  That means it is RAID storage to start with so it's redundant and fault tolerant.  If disks die in that RAID you don't lose data.  Great!  It is also virtualized, so you can provision and allocate storage, and attach it to your server with various API calls.  No calling the storage expert and asking him or her to run specialized commands from the hardware vendor.

Performance on EBS can exhibit variability.  That is it can go above the SLA performance level, then drop below it.  The SLA provides you with an average disk I/O rate you can expect.  This can frustrate some folks especially performance experts who expect reliable and consistent disk throughput on a server.  Traditional physically hosted servers behave that way.  Virtual AWS instances do not.

Backup EBS volumes by using the snapshot facility via API call or via a GUI interface like elasticfox.

Improve performance by using Linux software raid and striping across four volumes.

2. What is S3?  What is it used for?  Should encryption be used?

S3 stands for Simple Storage Service.  You can think of it like ftp storage, where you can move files to and from there, but not mount it like a filesystem.  AWS automatically puts your snapshots there, as well as AMIs there.  Encryption should be considered for sensitive data, as S3 is a proprietary technology developed by Amazon themselves, and as yet unproven vis-a-vis a security standpoint.

3. What is an AMI?  How do I build one?

AMI stands for Amazon Machine Image.  It is effectively a snapshot of the root filesystem.  Commodity hardware servers have a bios that points the the master boot record of the first block on a disk.  A disk image though can sit anywhere physically on a disk, so Linux can boot from an arbitrary location on the EBS storage network.

Build a new AMI by first spinning up and instance from a trusted AMI.  Then adding packages and components as required.  Be wary of putting sensitive data onto an AMI.  For instance your access credentials should be added to an instance after spinup.  With a database, mount an outside volume that holds your MySQL data after spinup as well.

4. Can I vertically scale an Amazon instance?  How?

Yes.  This is an incredible feature of AWS and cloud virtualization.  Spinup a new larger instance than the one you are currently running.  Pause that instance and detach the root ebs volume from this server and discard.  Then stop your live instance, detach its root volume.  Note the unique device ID and attach that root volume to your new server.   And the start it again.  Voila you have scaled vertically in-place!!

5. What is auto-scaling?  How does it work?

Autoscaling is a feature of AWS which allows you to configure and automatically provision and spinup new instances without the need for your intervention.  You do this by setting thresholds and metrics to monitor.  When those thresholds are crossed a new instance of your choosing will be spun up, configured, and rolled into the load balancer pool.  Voila you've scaled horizontally without any operator intervention!

6. What automation tools can I use to spinup servers?

The most obvious way is to roll-your-own scripts, and use the AWS API tools.  Such scripts could be written in bash, perl or other language or your choice.  Next option is to use a configuration management and provisioning tool like puppet or better it's successor Opscode Chef.  You might also look towards a tool like Scalr.  Lastly you can go with a managed solution such as Rightscale.

7. What is configuration management?  Why would I want to use it with cloud provisioning of resources?

Configuration management has been around for a long time in web operations and systems administration.  Yet the cultural popularity of it has been limited.  Most systems administrators configure machines as software was developed before version control - that is manually making changes on servers.  Each server can then and usually is slightly different.  Troubleshooting though is straightforward as you login to the box and operate on it directly.  Configuration management brings a large automation tool into the picture, managing servers like strings of a puppet.  This forces standardization, best practices, and reproducibility as all configs are versioned and managed.  It also introduces a new way of working which is the biggest hurdle to its adoption.

Enter the cloud, and configuration management becomes even more critical.  That's because virtual servers such as amazons EC2 instances are much less reliable than physical ones.  You absolutely need a mechanism to rebuild them as-is at any moment.  This pushes best practices like automation, reproducibility and disaster recovery into center stage.

8. Explain how you would simulate perimeter security using Amazon Web Services model?

Traditional perimeter security that we're already familiar with using firewalls and so forth is not supported in the Amazon EC2 world.  AWS supports security groups.  One can create a security group for a jump box with ssh access - only port 22 open.  From there a webserver group and database group are created.  The webserver group allows 80 and 443 from the world, but port 22 *only* from the jump box group.  Further the database group allows port 3306 from the webserver group and port 22 from the jump box group.  Add any machines to the webserver group and they can all hit the database.  No one from the world can, and no one can directly ssh to any of your boxes.

Want to further lock this configuration down?  Only allow ssh access from specific IP addresses on your network, or allow just your subnet.

Enterprise Architecture, Modernization, And Agile – It Can Be Done!

The Government Accountability Office (GAO) has provided recommendations to agencies such as Veterans Affairs (VA), Social Security Administration (SSA), Housing and Urban Development (HUD) and the U.S. Census Bureau (Bureau) for modernizing their legacy systems and processes. There is a common theme in the recommendations that revolves around strategic planning and risk management, which are encompassed within Enterprise Architecture.

Enterprise Architecture takes a holistic approach to planning with input from the business and understanding the technical direction needed to fulfill the business needs. Aligning the technical resources and environments to achieve the business goals helps to streamline processes, leading to more efficient business and IT operations, higher quality and reducing risks. Centralizing the decision making at the portfolio level and across the enterprise will help to align those resources to the strategic vision, which includes the business and technical needs. A centralized view also allows an organization to identify and consolidate duplicative projects, thereby reducing costs. Enterprise Architecture sets the standards by which decisions are made and products are developed.

Strategic Planning

Incorporating Agile practices within Enterprise Architecture allows organizations to remain flexible to changing needs and technology. As organizations grow, processes and solutions become more complex. Having a common architecture that is re-usable across teams reduces the complexity by ensuring that teams are using the existing infrastructure. This also lets teams focus on delivering more business value in a shorter timeframe rather than spending those resources on setting up new infrastructure.

While project teams deliver their work in short 2-4 week iterations and release products to end users on a more frequent cadence, shortening the development and long-term budget roadmaps to two years or less ensures projects are reviewed and evaluated more frequently to verify they are still timely, cost-effective and valuable. This also allows for the business and technology roadmaps to be concurrently reviewed and updated.

Enterprise Architects are a key resource to implementing Enterprise Architecture within an organization. The architects work with business stakeholders to understand the business needs and work with IT stakeholders to help guide the technical roadmap. They also help drive the organizational policy that sets the standards for decision making. Organizations may choose to implement an Enterprise Architecture team through which new requests are funneled. This is beneficial where the systems are complex and widespread across the organization. Using their understanding of the overall IT landscape and business needs, Enterprise Architects also guide project teams’ development efforts and work with them to understand their challenges. From working directly with project teams, they are also able to bring new and innovative ideas to be implemented or reused across the organization.

Risk Mitigation

Managing risk is a critical process in all projects. Implementing a standard risk-management practice across the organization ensures that risk is addressed as it arises. This includes setting clear roles and responsibilities, identifying and measuring risks, and managing the risks. Enterprise Architecture should set the guidelines by how risk is measured, managed and reported throughout the organization.

One example of risk at the team level that needs to be managed is technical debt. In a recent hearing, the GAO testified that a system release included unresolved defects that impacted performance and user experience. [1]Open defects and complex code bases that may require future refactoring lead to technical debt, which increases risk and reduces productivity. Addressing technical debt is a function within Enterprise Architecture and project teams must balance delivering value and addressing technical debt. The consequences of failing to address technical debt are not always clear, and as the debt piles up, it will be costlier to the business as productivity toward maintaining large complex code bases is reduced. Not addressing the technical debt also puts the project at risk of not aligning to the target Enterprise Architecture as it may have been reported to OMB or organizational stakeholders. This requires negotiating with the business to slow down delivering new value to ensure that high quality is being achieved. Incorporating Enterprise Architecture and Architects at the project level is one step toward ensuring the technical and business needs are properly prioritized.

Incorporating Enterprise Architecture in Agile Projects

Enterprise Architects work directly with business and project teams to understand the business and IT needs. They help drive the architectural design but also foster innovation from the project teams. In more complex systems, the Enterprise Architects collaborate with the business and project teams to provide a holistic view across initiatives. At a minimum, the Enterprise Architect should be considered a key stakeholder on projects. They provide input and guidance during planning sessions, prioritize architectural requirements, and participate in demos. Enterprise Architecture also validates the best technical fit for the proposed solution and identifies technical dependencies across projects.

As technical requirements are identified, teams react and evolve their design to meet the project needs. However, they may not have insight into how changes may impact other environments and projects, and Enterprise Architecture provides guidance for design across the organization. Providing the high-level architecture ensures that systems are effective but also lets teams react to emerging requirements and foster creativity.

Architecture needs to be addressed and accounted for. It needs to be maintained and build ahead of products features being developed. Project teams need to devote resources to building out the needed architecture while maintaining the balance in delivering business value. The architectural requirements can be broken down into smaller requirements that can be implemented incrementally. Developing the architecture incrementally also supports simple design and prevents building a complex structure or environment that may never be needed. This also includes the practice of refactoring and ensuring that code bases remain simple, manageable and on target.

Implementing Enterprise Architecture will reduce delays, costs and risks to projects, but there is a risk of creating a bottleneck through governance reviews and processes. To support faster delivery, the Enterprise Architecture should be flexible and incorporated within project teams. Enterprise Architecture also provides a holistic view to strategic planning and resources that can be aligned to meet the strategic initiatives of the organization. Deploying Enterprise Architects to work directly with project teams will ensure the architecture is understood and a balance is struck between business and IT requirements.

It is also possible to incorporate Enterprise Architecture and Agile practices. Developing the Enterprise Architecture incrementally and providing the high-level processes and requirements while leaving the emergent design and details to the project teams allows for flexibility and responses to change as is often found in Agile projects.

[1]VETERANS AFFAIRS INFORMATION TECHNOLOGY Management Attention Needed to Improve Critical System Modernizations, Consolidate Data Centers, and Retire Legacy Systems, Committee on Veterans' Affairs, House of Representatives Cong., 25 (2017) (testimony of David A. Powner, Director Information Technology Management Issues U.S. Government Accountability Office). Print.