In This Article:
- 1. What is the key difference between on-prem networking vs cloud networking?
- 2. What AWS Services are foundational to setting up a virtual network?
- 3. As a cloud architect, you are architecting connectivity between a customer’s AWS and on-prem environment. How can you evaluate your network architecture against AWS best practices?
- 4. From an architect’s point of view, what is the importance of edge networking?
- 5. What is the essence of AWS’s shared responsibility model?
- 6. Does the AWS Shared Responsibility Model take care of patching EC2 instances that are launched using Amazon-managed AMIs?
- 7. What is tagging in AWS?
- 8. What managed services can you use to track usage and costs in AWS?
- 9. What are the different types of rules available in AWS WAF?
- 10. Can you protect a CloudFront distribution with AWS WAF? Explain how.
- 11. What are the challenges in implementing cross-region resiliency?
- 12. Explain a challenge you faced in your last job as an architect and the steps you took to overcome the challenge.
- 13. What is Infrastructure as Code (IAC) and how can it be used to improve system reliability?
- 14. Explain how you can set up a DevOps pipeline using only native Amazon services.
- 15. Explain a potential architecture for an event-driven, low code ETL pipeline on AWS
- 16. How can you orchestrate a Glue job that is part of a larger ETL workflow?
- 17. What are the access patterns that cloud architects must consider to access data that resides in a data lake?
- 18. What are the advanges of event-driven architectures?
- 19. What are the common challenges associated with architecting a cloud-native transaction processing system?
- 20. What is the purpose of AWS S3 bucket policies, and how do they differ from IAM policies?
1. What is the key difference between on-prem networking vs cloud networking?
On-prem networking involves physically configuring the network including laying of the cabling, installing hardware routers and switches, network interface cards, etc. However, in the cloud, networking is a software powered, virtual exercise that consists of selecting and configuring relevant cloud services to setup a virutal network.
2. What AWS Services are foundational to setting up a virtual network?
AWS Services that are foundational to setting up a virtual network in the cloud are VPC, AWS Transit Gaeway, AWS Private Link and Amazon Route 53.
Amazon VPC allows users to define a virtual private network within AWS that can be used to launch AWS resources in.
Amazon Transit Gateway allows for connecting multiple VPCs across different regions and accounts.
AWS Private Link provides a secure and private channel for communication between workloads hosted on AWS and on-premises applications.
Lastly, Amazon Route 53 provides a cost-effective and reliable “DNS in the cloud” that helps direct traffic from outside the virtual networks to their intended destinations.
3. As a cloud architect, you are architecting connectivity between a customer’s AWS and on-prem environment. How can you evaluate your network architecture against AWS best practices?
To evaluate the network architecture for site-to-site connectivity, such as on-prem and AWS, we can leverage the Well-Architected Framework with a focus on Hybrid Networking Lens.
4. From an architect’s point of view, what is the importance of edge networking?
Edge networking helps transmit user-facing data securely and with minimal latency globally.
AWS Edge networking services such as CloudFront, Route 53 and AWS Global Accelerator can deliver data with a single-digit millisecond network latency.
AWS also offers edge networking security services such as AWS Shield and AWS WAF that help improve customers’ security posture and protect against malicious attacks at the network or the application layer.
5. What is the essence of AWS’s shared responsibility model?
In essence, the shared responsibility model states that AWS is responsible for the security _of_ the cloud, whereas the customer is responsible for the security of their workloads _in_ the cloud.
In other words, according to the Shared Responsibility Model, AWS is responsible for the security of the underlying infrastructure, such as physical security, network protection and data center operations, whereas the customer is responsible for managing the security of their applications, data, virtual instances and operating systems.
6. Does the AWS Shared Responsibility Model take care of patching EC2 instances that are launched using Amazon-managed AMIs?
AWS Shared Responsibility Model states that the customer is responsible for patching their own EC2 instances.
Amazon-managed AMIs are kept up to date with operating system updates, but it is the customer’s responsibility to apply security patches and maintain their instance configurations.
AWS does provide services such as Systems Manager for streamlining patching and configuration management. Customers can automate the patching process using these services.
7. What is tagging in AWS?
AWS lets us assign metadata to any AWS resource. This metadata is referred to as a “tag” and each tag is a simple key-value pair. Multiple tags can be assigned to a given resource. Tagging allows customers search for and filter AWS resources (based on tags). Tagging can be used to implement cloud management, cost optimization, and governance strategies at scale.
For example, enterprise customers can use tags to track the cost allocation of resources against internal departments, budgets or initiatives.
Related Reading: AWS Tagging Best Practices
8. What managed services can you use to track usage and costs in AWS?
The following AWS Services can be used to track usage and costs in AWS:
AWS Cost Explorer, AWS Budgets, AWS Billing and Management Console and AWS Trusted Advisor.
AWS Cost Explorer enables customers to visualize, understand, and manage their AWS spend.
AWS Budgets helps customers specify and track budgets against actual usage.
AWS Billing and Management Console provides billing information which is especially useful in larger enterprises as it can monitor costs across multiple accounts.
AWS Trusted Advisor provides best practices and suggests cost-saving opportunities. It can proactively monitor underutilization, helping customers identify unused resources that are costing them money.
AWS Trusted Advisor is a service that provides automated best practice recommendations to help customers reduce cost, increase performance and secure their AWS.
9. What are the different types of rules available in AWS WAF?
AWS WAF offers several types of rules to help organizations protect against web-based attacks. The most common types of rules in AWS WAF include:
- IP match conditions: These rules allow organizations to block traffic based on IP address or CIDR range.
- String match conditions: These rules allow organizations to block traffic based on specific strings or patterns found in the request.
- Size constraints: These rules allow organizations to block traffic based on the size of the request.
- SQL injection and cross-site scripting (XSS) match conditions: These rules allow organizations to block traffic that contains SQL injection or XSS attack payloads.
- Regular expression (regex) match conditions: These rules allow organizations to block traffic based on custom patterns using regular expressions.
- Geo-match conditions: These rules allow organizations to block traffic based on the geographic location of the request.
10. Can you protect a CloudFront distribution with AWS WAF? Explain how.
Yes, AWS WAF can be used to protect AWS CloudFront distributions against common attacks.
Integrating AWS WAF with Amazon CloudFront involves the following steps –
- Create the WebACL
- Associate WebACL with a rule group
- Associate WebACL and rule group with the CloudFront distribution using the CloudFront API or CLI
11. What are the challenges in implementing cross-region resiliency?
The primary challenge in implementing cross-region resiliency is ensuring data consistency across regions. In enterprise systems with non-trivial data, managing near real-time data consistency is complicated by issues such as network latency, data consistency, data ingress and egress costs and last but not least, operational complexity.
Some of the other challenges in implementing cross-region resiliency are having sophisticated IaC and DevOps pipelines that can deploy across regions, handling failover scenarios, cross-region monitoring & observability, and managing security and compliance across multiple regions.
One of the most important responsibilities of cloud architects is to manage tradeoffs in a pragmatic manner. Cloud architects must carefully assess the level of resiliency required, consider the cost and operational complexities of the resilient architecture they are proposing and ensure the architecture they are proposing can effectively meet the SLAs and operational requirements of the organization.
12. Explain a challenge you faced in your last job as an architect and the steps you took to overcome the challenge.
What the interviewer is looking for: This is an excellent question. The interviewer wants to get a better understanding of your problem-solving skills and true experience as an architect.
How you should answer: This is a great question to showcase not just your technical skills but also your ability to think strategically and come up with creative solutions. When answering this question, try to provide a concrete example from your experience. It is best to always be prepared with a few examples to answer this question. Be ready to explain the situation and the challenge in detail, then describe how you overcame it by breaking down the problem into manageable parts and walking through your approach step-by-step. Make sure to end on a positive note and highlight the success of your solution. This will help demonstrate to the interviewer that you are an effective problem solver and capable architect.
13. What is Infrastructure as Code (IAC) and how can it be used to improve system reliability?
Infrastructure as Code (IaC) is a practice that enables organizations to manage and provision their IT infrastructure through code. It is a new paradigm that allows organizations to quickly provision and manage cloud resources such as networks, virtual servers, storage, databases, etc. in a repeatable and consistent manner. By relying on IaC, organizations can easily keep track of changes and update their infrastructure in real-time with minimal effort. Additionally, teams can also use IaC to quickly create “copies” of their environment for backup or testing.
IaC helps improve reliability by allowing organizations to spin up new environments quickly, version control and test IaC code just like any other code.
Two popular tools for IaC on AWS are Terraform and AWS CDK. You can read the comparison between the two here. AWS Cloud Development Kit (AWS CDK) uses familiar programming languages, making it easier for developers to define their infrastructure. To excel at using this tool in real-world scenarios or answering questions related to CDK, refer to our comprehensive guide on AWS CDK interview questions.
Related Reading: CDK vs CloudFormation: A Pragmatic Comparison of AWS Infrastructure as Code Solutions
14. Explain how you can set up a DevOps pipeline using only native Amazon services.
Amazon provides Code* suite of AWS services to setup and manage DevOps pipelines. By using these services, you can take advantage of the scalability and cost-efficiency of AWS as well as native integration with other AWS services.
The following native Amazon services can be used to setup a DevOps pipeline:
- AWS CodeCommit – This is a git-repo service that can be used to provision, well git repositories
- AWS CodeBuild – This is a AWS managed build service that can be used to compile, test, and package source code. CodeBuild integrates natively with AWS CodeCommit but can also be used with other git repo provides such as GitHub or BitBucket.
- AWS CodeDeploy – This is a deployment service that can be used to deploy packages and applications to EC2 instances or other AWS resources such as ECS or Lambda.
- AWS CodePipeline – CodePipeline provides an orchestration layer that integrates all the above services together so you can set up a continuous build and deployment pipeline. It provides an intuitive UI to configure workflows and easily modify the sequence of steps in your pipeline.
Using the above services helps accelerate the creation of DevOps pipelines for cloud workloads.
Related Reading: We have an entire article that covers 40+ AWS DevOps Interview Questions and Answers.
15. Explain a potential architecture for an event-driven, low code ETL pipeline on AWS
We can leverage AWS Glue to set up low-code ETL pipelines on AWS. Glue start triggers can be configured to trigger Glue jobs or workflows on events from Event Bridge or events directly from other AWS services such as S3.
16. How can you orchestrate a Glue job that is part of a larger ETL workflow?
You can orchestrate a Glue job that is part of a larger ETL workflow using either Glue Workflows or AWS StepFunctions. Complex cloud native ETL workflows can also leverage nested StepFunctions capability that allows a StepFunction workflow to invoke another StepFunction workflow.
Related reading: AWS Glue interview questions (and answers)
17. What are the access patterns that cloud architects must consider to access data that resides in a data lake?
Cloud architects must choose one or more of the following access patterns to access data in a data lake:
- Interactive Queries
- Change Data Capture (CDC) Subscriptions
- Data Streaming
- Batch Processing
- Synchronous API access
- Asynchronous API Access
When choosing from the above access patterns, architects must take into consideration the requirements around access modality (synchronous, asynchronous), data freshness, security and performance.
This article on data lake access patterns covers each of the above patterns in detail.
18. What are the advantages of event-driven architectures?
Event-driven architecture (EDA) is a software design paradigm where components communicate through events, which are messages that represent changes in the state of the system. In an EDA, components (producers) generate events, and other components (consumers) react to those events. This approach offers several advantages over traditional request-response architectures:
- Improved Organizational Agility: Components in an EDA are only aware of the events they produce or consume, not the implementation details of other components. This loose coupling makes it easier to develop, test, and deploy individual components independently without affecting the overall system. This speeds up development cycles and increases the overall velocity of feature delivery. Additionally, event-based contracts between producers and consumers can be used as a form of integration testing by verifying that events have been processed correctly.
- Improved Scalability: EDA allows for horizontal scaling by adding more instances of producers and consumers to handle increased load. Asynchronous event processing can also help distribute the workload across multiple consumers, improving overall system performance.
- Improved Resilience: In EDA, components can continue to function even if some parts of the system are down or experiencing delays. Since events can be stored in a durable message broker (e.g., Apache Kafka), the system can recover from failures by replaying unprocessed events. In EDA, components process events independently, reducing the risk of cascading failures. If one component fails, it does not directly impact other components as long as the event broker remains operational.
- Adaptability: EDA supports a flexible architecture that can easily adapt to changing requirements. New components can be added to the system to process events in different ways, while existing components can be updated without disrupting the flow of events.
- Auditability and Traceability: Events in EDA provide an audit trail of the changes in the state of the system. By storing and analyzing events, you can gain insights into the history and current state of the system, identify trends or anomalies, and improve traceability for debugging and troubleshooting purposes. This is in contrast to API-driven synchronous system requests, where it is difficult to trace the state changes to domain objects.
- Parallelism: EDA supports the parallel processing of events by multiple consumers, allowing you to take advantage of multi-core processors or distributed computing resources to increase throughput and reduce processing time. Event driven systems can scale to support millions of events per second.
Related Reading: Kafka Interview Questions
19. Let’s say you are asked to architect a transaction processing system. What are some of the challenges that you’ll encounter when architecting such a system in a cloud native manner?
While it is true that cloud-native approaches offer several advantages, they also introduce complexities that must be considered when implementing transaction processing systems. Some of those challenges are:
- Coordination complexity: In a cloud-native architecture with loosely coupled components, such as microservices or serverless functions, coordinating transactions that span multiple components can be challenging since each component operates independently, and there is no built-in mechanism to ensure transactional consistency across components. Solutions like the Saga pattern, two-phase commit, or compensating transactions can be used to manage distributed transactions, but they do add complexity to the overall system.
- Data consistency: Good cloud native architecture leverages purpose driven, independent data stores for each component. This distributed nature of the data makes it more difficult to ensure data consistency across the data stores and leads to the consideration and adoption of less-than-ideal patterns or trade-offs such as eventual consistency.
- Network reliability and latency: In cloud-native architectures, as multiple services and components communicate over a network to fulfill a transaction, managing risk related to network reliability and latency becomes a key consideration. Network failures or high latency can impact transaction processing, making it essential to implement proper error handling, retries, and timeouts. As architects, we must also consider the placement of services and data stores relative to each other to minimize latency and improve overall performance.
Related Reading: Microservices Interview Questions and Answers
20. What is the purpose of AWS S3 bucket policies, and how do they differ from IAM policies?
Bucket policies are used to define permissions for accessing objects within an Amazon S3 bucket. They differ from IAM policies, which are attached to IAM users, groups, or roles to manage their permissions across AWS services. While bucket policies are applied directly to the bucket, IAM policies are used to control access for individual users or entities within an AWS account.
Aspect | Bucket Policies | IAM Policies |
---|---|---|
Purpose | Define access permissions for an Amazon S3 bucket and its objects | Define access permissions for AWS resources, including Amazon S3, across various AWS services |
Scope | Attached to a specific Amazon S3 bucket, and permissions apply to all objects within the bucket | Attached to IAM users, groups, or roles, and permissions can apply to resources across multiple AWS services |
Format | Written in JSON format, specifying allowed or denied actions, resources (bucket and objects), and the principal | Written in JSON format, specifying allowed or denied actions, resources, and conditions |
Use Cases | Useful for granting cross-account access, controlling access to specific objects, or managing public access | Useful for managing permissions for users within an AWS account, granting access to multiple AWS services, or applying fine-grained access control based on specific conditions |
Related Reading: Amazon S3 Interview Questions